The default bug view has changed. See this FAQ.

"ASSERTION: Inserting multiple children without flushing"

RESOLVED FIXED in mozilla1.9.2a1

Status

()

Core
HTML: Parser
RESOLVED FIXED
8 years ago
7 years ago

People

(Reporter: Jesse Ruderman, Assigned: bnewman)

Tracking

({assertion, testcase, verified1.9.1})

Trunk
mozilla1.9.2a1
x86
Mac OS X
assertion, testcase, verified1.9.1
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(blocking1.9.1 .5+, status1.9.1 .5-fixed)

Details

(Whiteboard: [needed on 1.9.1 to fix 525276], URL)

Attachments

(3 attachments)

(Reporter)

Description

8 years ago
Created attachment 352039 [details]
testcase 1

Loading the testcase triggers:

###!!! ASSERTION: Inserting multiple children without flushing.: 'mNumFlushed == mContent->GetChildCount()', file /Users/jruderman/central/content/html/document/src/nsHTMLContentSink.cpp, line 903

Reduced from http://nmuta.fri.macserver.jp/home149.html.
(Reporter)

Comment 1

8 years ago
Created attachment 352040 [details]
testcase 2

Adding a "</table>" makes it give me this assertion instead:

###!!! ASSERTION: Node at base of context stack not fully flushed.: 'bottom.mContent->GetChildCount() == bottom.mNumFlushed', file /Users/jruderman/central/content/html/document/src/nsHTMLContentSink.cpp, line 1933

Updated

8 years ago
Assignee: nobody → bnewman
(Assignee)

Comment 2

8 years ago
Created attachment 352628 [details] [diff] [review]
using AddLeaf instead of AppendChildTo to add <link>s in ProcessLINKTag
[Checkin: Comment 4]

This patch
1. reuses AddLeaf, unifying some code
2. keeps the assertions from failing by calling DidAddContent before it's too late (in AddLeaf)
3. no longer forces <link>s to be appended (they may be inserted at other positions now, too)
(Assignee)

Updated

8 years ago
Attachment #352628 - Flags: review?(mrbkap)
(Assignee)

Updated

8 years ago
Status: NEW → ASSIGNED

Updated

8 years ago
Attachment #352628 - Flags: superreview+
Attachment #352628 - Flags: review?(mrbkap)
Attachment #352628 - Flags: review+
Comment on attachment 352628 [details] [diff] [review]
using AddLeaf instead of AppendChildTo to add <link>s in ProcessLINKTag
[Checkin: Comment 4]

Looks good. r+sr=mrbkap
(Assignee)

Updated

8 years ago
Keywords: checkin-needed
Comment on attachment 352628 [details] [diff] [review]
using AddLeaf instead of AppendChildTo to add <link>s in ProcessLINKTag
[Checkin: Comment 4]

http://hg.mozilla.org/mozilla-central/rev/4b94808ccb23
Attachment #352628 - Attachment description: using AddLeaf instead of AppendChildTo to add <link>s in ProcessLINKTag → using AddLeaf instead of AppendChildTo to add <link>s in ProcessLINKTag [Checkin: Comment 4]
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.2a1
(Reporter)

Updated

8 years ago
Flags: in-testsuite+
Attachment #352628 - Flags: approval1.9.1.5?
Blocks: 525276
blocking1.9.1: --- → .5+
status1.9.1: --- → wanted
Whiteboard: [needed on 1.9.1 to fix 525276]
Attachment #352628 - Flags: approval1.9.1.5? → approval1.9.1.5+
Comment on attachment 352628 [details] [diff] [review]
using AddLeaf instead of AppendChildTo to add <link>s in ProcessLINKTag
[Checkin: Comment 4]

Approved for 1.9.1.5, a=dveditz for release-drivers
Can we get this landed on 1.9.1 ASAP?
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/b33bd180dc32
status1.9.1: wanted → .5-fixed
Blocks: 525814
Jesse, this bug should be all/all, right?
Attachment #352628 - Flags: approval1.9.1.5+
This needs to land on the GECKO1914_20091006_RELBRANCH for 1.9.1.5.
blocking1.9.1: .6+ → .5+
status1.9.1: .6-fixed → ---
https://hg.mozilla.org/releases/mozilla-1.9.1/rev/c204f7bb0064
status1.9.1: --- → .5-fixed
Verified on 1.9.1 on OS X 10.6 with my own debug 1.9.1 build.
Keywords: verified1.9.1
Perhaps because it appears in release notes, the summary line of this bug 
seems to be drawing attention in some user circles.  Users are envisioning 
places where (a) flushing occurs, and (b) children are inserted   
(and browsers make assertions about these occurrences).

Perhaps we should take slightly more care in wording assertion messages.
(Assignee)

Comment 13

8 years ago
As appalling as it may sound, Firefox flushes (passes off for rendering) trillions, literally trillions, of children (HTML elements) every day. I believe our users are stronger for knowing the truth. And if even just one volunteer joins the project in order to satisfy her morbid curiosity about the watery plight of all those page elements, we are, all of us, that much better off.
http://www.google.com/#hl=en&source=hp&q=ASSERTION%3A+Inserting+multiple+children+without+flushing
(Reporter)

Comment 15

8 years ago
http://search.twitter.com/search?q=Inserting+multiple+children+without+flushing
Soon we will make wikipedia.

Comment 17

7 years ago
"Perhaps we should take slightly more care in wording assertion messages."
I think the real fault is the terminology used.
You need to log in before you can comment on or make changes to this bug.