Bug 19402 – Dynamic javascript-based layout changes do not render properly

• Component: Layout and Rendering
• Status: RESOLVED WORKSFORME

[Jon-Eric Eliker]

Visit the URL then select "Author" from the "Select a Field" select list.  The page changes to show the Author field, "search type" (substring by default), a text box for data entry, an X graphic icon and a + graphic icon.  In WebKit, the "search type" box is obscured by the text box.  This behavior is not seen in other browsers tested including Firefox 2.x and Internet Explorer 6.x/7.x.

[Jon-Eric Eliker]

Created attachment 21508 [details]
Set of screenshots showing error in WebKit 5525.20 and correct behavior in other browsers

Includes screenshots from WebKit 5525.20 (Mac/Windows), Firefox 2 (Mac), Firefox 3 (Mac), IE 6 (Windows), IE 7 (Windows)

Created attachment 21511 [details]
Reduction

Created attachment 21512 [details]
Reduction

A more robust version

Created attachment 21518 [details]
Ensure that containers are marked as needing layout and pref widths recalc

[Darin Adler]

Comment on attachment 21518 [details]
Ensure that containers are marked as needing layout and pref widths recalc

Is there a way to do this without replacing a single function call with four? Is there something we can do to avoid making this type of mistake in the future?

(In reply to comment #5)
> (From update of attachment 21518 [details] [edit])
> Is there a way to do this without replacing a single function call with four?

Yes. By calling setNeedsLayout(false) and setPrefWidthsDirty(false) before calling setNeedsLayoutAndPrefWidthsRecalc(). That'd be adding just two function calls. Another option is to add a parameter to the "dirtying" function to force unconditional marking. Yet another option is to patch <select>s to make sure they don't dirty themselves when they don't have a parent, but maybe the problem is not limited to <select>s.

> Is there something we can do to avoid making this type of mistake in the
> future?

I don't know. I'd like to hear what Hyatt thinks about this bug and the proposed patch.

[Darin Adler]

Comment on attachment 21518 [details]
Ensure that containers are marked as needing layout and pref widths recalc

I'd set r=me on this, except I think Mitz is waiting specifically for Hyatt to do so.

Comment on attachment 21518 [details]
Ensure that containers are marked as needing layout and pref widths recalc

Hyatt and I talked a little about this, and I am looking into other situations in which a child renderer being inserted is already marked as needing layout or preferred widths recalculation, to see if they can be avoided (and then appendChildNode() and insertChildNode() could stay the same, with an added assertion that the child is not dirty).

[Alexey Proskuryakov]

FWIW, I cannot reproduce this in Safari 4.0.5.