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

RESOLVED WORKSFORME

Status

()

Core
Editor
RESOLVED WORKSFORME
10 years ago
3 years ago

People

(Reporter: Martijn Wargers (zombie), Unassigned)

Tracking

({assertion, testcase})

Trunk
x86
Windows XP
assertion, testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [depends on 611798])

Attachments

(2 attachments)

(Reporter)

Description

10 years ago
Created attachment 316327 [details]
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
(Reporter)

Comment 1

10 years ago
Created attachment 318215 [details]
testcase2

This one crashes directly, after 200 ms.
(Reporter)

Comment 2

10 years ago
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]
(Reporter)

Comment 4

10 years ago
Ok, let's morph this into the viewmanager assertion bug then, since that assertion is fairly unique.
Severity: critical → normal
Keywords: crash → assertion
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?
(Reporter)

Comment 6

10 years ago
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

10 years ago
testcase2 crashes for me.

Comment 8

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

Comment 9

8 years ago
Is this bad?
blocking2.0: --- → ?

Comment 11

8 years ago
(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

8 years ago
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

8 years ago
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]
(Reporter)

Updated

7 years ago
Status: NEW → RESOLVED
Last Resolved: 7 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
status-b2g-v2.5: fixed → ---
You need to log in before you can comment on or make changes to this bug.