Closed Bug 429586 Opened 12 years ago Closed 8 years ago

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

Categories

(Core :: Editor, defect)

x86
Windows XP
defect
Not set

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: martijn.martijn, Unassigned)

References

Details

(Keywords: assertion, testcase, Whiteboard: [depends on 611798])

Attachments

(2 files)

Attached file 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
Attached file testcase2
This one crashes directly, after 200 ms.
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?
Depends on: 386782
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]
Ok, let's morph this into the viewmanager assertion bug then, since that assertion is fairly unique.
Severity: critical → normal
Keywords: crashassertion
Summary: Crash [@ nsEditor::EndUpdateViewBatch] with pasting and domattrmodified removing iframe → ASSERTION: Must have view manager: '!isSafeToFlush || mViewManager' with pasting and domattrmodified removing iframe
Version: unspecified → Trunk
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?
I'm still seeing the view manager assertion in my debug build (last updated, yesterday).
I'm not seeing those ClearCacheEntry assertions, fwiw.
testcase2 crashes for me.
Now testcase2 doesn't crash for me, but instead makes the entire window (including toolbars!!!) black and/or white.
Is this bad?
blocking2.0: --- → ?
(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?
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.
OK, setting a dependency to make sure that we won't miss this.
Depends on: 611798
blocking2.0: ? → ---
Whiteboard: [bug 611798]
Whiteboard: [bug 611798] → [depends on 611798]
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
Flags: in-testsuite+
removing the b2g 2.5 flag since this commit has been reverted due to an incorrect merge, sorry for the confusion
You need to log in before you can comment on or make changes to this bug.