429586 - ASSERTION: Must have view manager: '!isSafeToFlush || mViewManager' with pasting and domattrmodified removing iframe

Status: RESOLVED WORKSFORME

(Core :: DOM: Editor, defect)

Description

[Martijn Wargers (dead)]

Attachment: zipped up testcase

See zipped up testcase, to reproduce the crash.
- Open parentframe.htm
- Make sure you have something to paste in your clipboard, then do some selecting of the text in the iframe

Usually, you'll get a crash.

http://crash-stats.mozilla.com/report/index/fb5beaf5-0cd8-11dd-a010-001321b13766
0  	xul.dll  	nsEditor::EndUpdateViewBatch  	 mozilla/editor/libeditor/base/nsEditor.cpp:4373
1 	xul.dll 	nsHTMLEditor::EndUpdateViewBatch 	mozilla/editor/libeditor/html/nsHTMLEditor.cpp:5808
2 	xul.dll 	nsEditor::EndPlaceHolderTransaction 	mozilla/editor/libeditor/base/nsEditor.cpp:943
3 	xul.dll 	nsAutoPlaceHolderBatch::~nsAutoPlaceHolderBatch 	mozilla/editor/libeditor/base/nsEditorUtils.h:66
4 	xul.dll 	nsHTMLEditor::InsertFromTransferable 	mozilla/editor/libeditor/html/nsHTMLDataTransfer.cpp:1326
5 	xul.dll 	xul.dll@0x7dbc8f

Comment 1

[Martijn Wargers (dead)]

Attachment: testcase2

This one crashes directly, after 200 ms.

Comment 2

[Martijn Wargers (dead)]

This actually seems fixed now in current trunk build. It was fixed between 2008-04-23 and 2008-04-24. So I guess somehow fixed by bug 386782.

Not sure if I should close this bug. Maybe it was accidentally fixed by the patch in bug 386782 and the follow-up patch in that bug could perhaps reregress this?

Comment 3

[Chris Pearce [:cpearce (Not reading bugmail)]]

The follow-up patch doesn't reregress, though I get the following assertions/warnings when loading testcase2:

++DOMWINDOW == 18 (0405EF64) [serial = 40] [Outer = 0405ED60]
++WEBSHELL 0812B040 == 8
++DOMWINDOW == 19 (0405E9DC) [serial = 41] [Outer = 00000000]
++DOMWINDOW == 20 (0405FA74) [serial = 42] [Outer = 0405E9B0]
###!!! ASSERTION: no frame, see bug #188946: 'frame', file c:/work/src/browser/mozilla/editor/libeditor/base/nsEditor.cpp, line 4123
GetPrimaryFrameFor() called while nsFrameManager is being destroyed!
GetPrimaryFrameFor() called while nsFrameManager is being destroyed!
GetPrimaryFrameFor() called while nsFrameManager is being destroyed!
GetPrimaryFrameFor() called while nsFrameManager is being destroyed!
GetPrimaryFrameFor() called while nsFrameManager is being destroyed!
GetPrimaryFrameFor() called while nsFrameManager is being destroyed!
GetPrimaryFrameFor() called while nsFrameManager is being destroyed!
GetPrimaryFrameFor() called while nsFrameManager is being destroyed!
GetPrimaryFrameFor() called while nsFrameManager is being destroyed!
GetPrimaryFrameFor() called while nsFrameManager is being destroyed!
GetPrimaryFrameFor() called while nsFrameManager is being destroyed!
###!!! ASSERTION: Must have view manager: '!isSafeToFlush || mViewManager', file c:/work/src/browser/mozilla/layout/base/nsPresShell.cpp, line 4526
WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004003: file c:/work/src/browser/mozilla/extensions/spellcheck/src/mozInlineSpellWordUtil.cpp, line 110
WARNING: nsComposerCommandsUpdater::SelectionIsCollapsed - no domSelection: file c:/work/src/browser/mozilla/editor/composer/src/nsComposerCommandsUpdater.cpp, line 377
--WEBSHELL 0812B040 == 7
--DOMWINDOW == 19 (03EDD1BC) [serial = 36] [Outer = 03EDCFA8]
--DOMWINDOW == 18 (03EDCFD4) [serial = 35] [Outer = 00000000]

Comment 4

[Martijn Wargers (dead)]

Ok, let's morph this into the viewmanager assertion bug then, since that assertion is fairly unique.

Comment 5

[Chris Pearce [:cpearce (Not reading bugmail)]]

Now that bug 430624 has landed, I see the following errors when loading testcase2:

###!!! ASSERTION: Calling ClearCacheEntry with a NULL pointer!: '!aAccessNode', file c:/work/src/browser/mozilla/accessible/src/base/nsAccessNode.cpp, line 797
###!!! ASSERTION: Calling ClearCacheEntry with a NULL pointer!: '!aAccessNode', file c:/work/src/browser/mozilla/accessible/src/base/nsAccessNode.cpp, line 797
###!!! ASSERTION: Calling ClearCacheEntry with a NULL pointer!: '!aAccessNode', file c:/work/src/browser/mozilla/accessible/src/base/nsAccessNode.cpp, line 797
###!!! ASSERTION: no frame, see bug #188946: 'frame', file c:/work/src/browser/mozilla/editor/libeditor/base/nsEditor.cpp, line 4123
WARNING: NS_ENSURE_TRUE(parentDoc) failed: file c:/work/src/browser/mozilla/accessible/src/base/nsDocAccessible.cpp, line 532
WARNING: NS_ENSURE_TRUE(parentDoc) failed: file c:/work/src/browser/mozilla/accessible/src/base/nsDocAccessible.cpp, line 216

Do we care about these assertions/warnings? Can we just close this?

Comment 6

[Martijn Wargers (dead)]

I'm still seeing the view manager assertion in my debug build (last updated, yesterday).
I'm not seeing those ClearCacheEntry assertions, fwiw.

Comment 7

[Jesse Ruderman]

testcase2 crashes for me.

Comment 8

[Jesse Ruderman]

Now testcase2 doesn't crash for me, but instead makes the entire window (including toolbars!!!) black and/or white.

Comment 9

[Jesse Ruderman]

Is this bad?

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Potentially...

Comment 11

[(no longer active)]

(In reply to comment #8)
> Now testcase2 doesn't crash for me, but instead makes the entire window
> (including toolbars!!!) black and/or white.

This reminds me of bug 611798.

Jesse, I think you should file a new bug for the rendering problem and nominate that for blocking.

Also, now that we have two assertion/crash tests which have rendering effects on the entire browser, do you think we should go through the entire set of such tests and test them for this?  Is this an easy task to do?  Is it something that the QA folks can do?

Comment 12

[Jesse Ruderman]

I bet it's the same as bug 611798.  Its testcase (from bug 432114) has similar ingredients (editor, frames, mutation events) and similar results ("dying in the middle of our own update", no painting).  I'll retest this once bug 611798 is fixed to be sure.

Comment 13

[(no longer active)]

OK, setting a dependency to make sure that we won't miss this.

Comment 14

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/6c38591a76a4

Comment 15

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/6c38591a76a4

Comment 16

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-b2g44_v2_5/rev/6c38591a76a4

Comment 17

[Carsten Book [:Tomcat]]

removing the b2g 2.5 flag since this commit has been reverted due to an incorrect merge, sorry for the confusion