Recurring into document.write using DOMCharacterDataModified event can hang Firefox

RESOLVED FIXED

Status

()

Core
HTML: Parser
P5
critical
RESOLVED FIXED
11 years ago
8 years ago

People

(Reporter: Jesse Ruderman, Unassigned)

Tracking

(Blocks: 1 bug, {assertion, hang, testcase})

Trunk
x86
Mac OS X
assertion, hang, testcase
Points:
---
Dependency tree / graph
Bug Flags:
wanted1.9.0.x +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fixed by the HTML5 parser])

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
Created attachment 279218 [details]
testcase (hangs Firefox when loaded)

Loading the testcase triggers:

###!!! ASSERTION: Tag mismatch.  Closing tag on wrong context or something?: 'nodeType == eHTMLTag_form || nodeType == aTag', file /Users/jruderman/trunk/mozilla/content/html/document/src/nsHTMLContentSink.cpp, line 928

###!!! ASSERTION: Error: invalid tag stack position: 'mBodyContext->GetCount() > 0', file /Users/jruderman/trunk/mozilla/parser/htmlparser/src/CNavDTD.cpp, line 2719

Firefox hangs, repeatedly reporting the second assertion.

I'm not sure this is a parser bug.  The bug might be that the mutation event fires despite the page being in a "loading" state (see bug 90983).
Flags: blocking1.9?
Might not be a real blocker since it's not exploitable. But would be great if you could have a look at this blake. We'll probably degrade this to [wanted-1.9] once we get closer to release.
Assignee: nobody → mrbkap
Flags: blocking1.9? → blocking1.9+
(Reporter)

Comment 2

11 years ago
This isn't the only bad thing that happens with the combination of mutation event handlers and document.write, fwiw.
Bug 394418 may have an impact on the behavior here.
Jesse, does this happen still now that bug 394418 is fixed?
Priority: -- → P5
(Reporter)

Comment 5

11 years ago
I still get the two assertions in comment 0.  I don't know whether it still leads to a hang because I turned the second assertion into an abort locally.
Isn't the issue that we end up notifying sync from inside the content sink when we append text to an already-flushed and existing text node?  See also bug 235255.  Maybe we should just get that patch in?
Depends on: 235255
suer since there is a patch we might as well land it
Well.  That patch isn't quite done is the problem....  ;)  Otherwise it would _be_ in.
Marking as wanted for a dot release per driver reprio triage w/ jst and sicking.
Flags: tracking1.9+ → wanted1.9.0.x+
Priority: P5 → --

Updated

10 years ago
Priority: -- → P5

Updated

9 years ago
Assignee: mrbkap → nobody
(Reporter)

Comment 10

9 years ago
Still happens with html5.enable false, but not with html5.enable true.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Whiteboard: [fixed by the HTML5 parser]
You need to log in before you can comment on or make changes to this bug.