Last Comment Bug 468562 - "ASSERTION: Inserting multiple children without flushing"
: "ASSERTION: Inserting multiple children without flushing"
Status: RESOLVED FIXED
[needed on 1.9.1 to fix 525276]
: assertion, testcase, verified1.9.1
Product: Core
Classification: Components
Component: HTML: Parser (show other bugs)
: Trunk
: x86 Mac OS X
: -- normal (vote)
: mozilla1.9.2a1
Assigned To: Ben Newman (:bnewman) (:benjamn)
:
:
Mentors:
http://nmuta.fri.macserver.jp/home149...
Depends on:
Blocks: 525276 525814
  Show dependency treegraph
 
Reported: 2008-12-08 20:10 PST by Jesse Ruderman
Modified: 2009-12-17 19:06 PST (History)
13 users (show)
jruderman: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
.5+
.5-fixed


Attachments
testcase 1 (95 bytes, text/html)
2008-12-08 20:10 PST, Jesse Ruderman
no flags Details
testcase 2 (103 bytes, text/html)
2008-12-08 20:10 PST, Jesse Ruderman
no flags Details
using AddLeaf instead of AppendChildTo to add <link>s in ProcessLINKTag [Checkin: Comment 4] (3.90 KB, patch)
2008-12-11 15:37 PST, Ben Newman (:bnewman) (:benjamn)
mrbkap: review+
mrbkap: superreview+
samuel.sidler+old: approval1.9.1.5+
dveditz: approval1.9.1.6+
Details | Diff | Splinter Review

Description Jesse Ruderman 2008-12-08 20:10:02 PST
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.
Comment 1 Jesse Ruderman 2008-12-08 20:10:44 PST
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
Comment 2 Ben Newman (:bnewman) (:benjamn) 2008-12-11 15:37:59 PST
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)
Comment 3 Blake Kaplan (:mrbkap) 2008-12-15 16:42:04 PST
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
Comment 4 Serge Gautherie (:sgautherie) 2008-12-19 17:46:35 PST
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
Comment 5 Daniel Veditz [:dveditz] 2009-10-30 12:13:05 PDT
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
Comment 6 Samuel Sidler (old account; do not CC) 2009-11-01 02:47:09 PST
Can we get this landed on 1.9.1 ASAP?
Comment 7 Olli Pettay [:smaug] (way behind * queues, especially ni? queue) 2009-11-01 11:11:17 PST
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/b33bd180dc32
Comment 8 Henrik Skupin (:whimboo) 2009-11-02 01:00:03 PST
Jesse, this bug should be all/all, right?
Comment 9 Samuel Sidler (old account; do not CC) 2009-11-02 08:14:22 PST
This needs to land on the GECKO1914_20091006_RELBRANCH for 1.9.1.5.
Comment 10 Samuel Sidler (old account; do not CC) 2009-11-02 10:10:44 PST
https://hg.mozilla.org/releases/mozilla-1.9.1/rev/c204f7bb0064
Comment 11 Al Billings [:abillings] 2009-11-02 15:45:57 PST
Verified on 1.9.1 on OS X 10.6 with my own debug 1.9.1 build.
Comment 12 Nelson Bolyard (seldom reads bugmail) 2009-11-07 14:43:14 PST
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.
Comment 13 Ben Newman (:bnewman) (:benjamn) 2009-11-09 13:08:23 PST
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.
Comment 16 Al Billings [:abillings] 2009-11-09 17:12:22 PST
Soon we will make wikipedia.
Comment 17 Yuhong Bao 2009-12-17 19:06:59 PST
"Perhaps we should take slightly more care in wording assertion messages."
I think the real fault is the terminology used.

Note You need to log in before you can comment on or make changes to this bug.