468562 - "ASSERTION: Inserting multiple children without flushing"

Status: RESOLVED FIXED

(Core :: DOM: HTML Parser, defect)

Description

[Jesse Ruderman]

Attachment: 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]

Attachment: 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)]

Attachment: 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) (inactive)]

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)]

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]]

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)]

Can we get this landed on 1.9.1 ASAP?

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/b33bd180dc32

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Jesse, this bug should be all/all, right?

Comment 9

[Samuel Sidler (old account; do not CC)]

This needs to land on the GECKO1914_20091006_RELBRANCH for 1.9.1.5.

Comment 10

[Samuel Sidler (old account; do not CC)]

https://hg.mozilla.org/releases/mozilla-1.9.1/rev/c204f7bb0064

Comment 11

[Al Billings [:abillings - ex-MoCo]]

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)]

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)]

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 14

[Samuel Sidler (old account; do not CC)]

http://www.google.com/#hl=en&source=hp&q=ASSERTION%3A+Inserting+multiple+children+without+flushing

Comment 15

[Jesse Ruderman]

http://search.twitter.com/search?q=Inserting+multiple+children+without+flushing

Comment 16

[Al Billings [:abillings - ex-MoCo]]

Soon we will make wikipedia.

Comment 17

[Yuhong Bao]

"Perhaps we should take slightly more care in wording assertion messages."
I think the real fault is the terminology used.