Bug 19402 - Dynamic javascript-based layout changes do not render properly
Summary: Dynamic javascript-based layout changes do not render properly
Status: RESOLVED WORKSFORME
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac (Intel) OS X 10.5
: P2 Normal
Assignee: Nobody
URL: http://aosdemeamt04.oracle.com:7779/i...
Keywords: HasReduction
Depends on:
Blocks:
 
Reported: 2008-06-05 07:05 PDT by Jon-Eric Eliker
Modified: 2010-06-11 17:40 PDT (History)
4 users (show)

See Also:


Attachments
Set of screenshots showing error in WebKit 5525.20 and correct behavior in other browsers (759.59 KB, application/octet-stream)
2008-06-05 07:48 PDT, Jon-Eric Eliker
no flags Details
Reduction (386 bytes, text/html)
2008-06-05 11:38 PDT, mitz
no flags Details
Reduction (377 bytes, text/html)
2008-06-05 11:56 PDT, mitz
no flags Details
Ensure that containers are marked as needing layout and pref widths recalc (12.63 KB, patch)
2008-06-05 20:47 PDT, mitz
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jon-Eric Eliker 2008-06-05 07:05:40 PDT
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.
Comment 1 Jon-Eric Eliker 2008-06-05 07:48:43 PDT
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)
Comment 2 mitz 2008-06-05 11:38:02 PDT
Created attachment 21511 [details]
Reduction
Comment 3 mitz 2008-06-05 11:56:49 PDT
Created attachment 21512 [details]
Reduction

A more robust version
Comment 4 mitz 2008-06-05 20:47:38 PDT
Created attachment 21518 [details]
Ensure that containers are marked as needing layout and pref widths recalc
Comment 5 Darin Adler 2008-06-06 09:28:58 PDT
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?
Comment 6 mitz 2008-06-06 19:51:54 PDT
(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.
Comment 7 Darin Adler 2008-06-11 12:04:32 PDT
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 8 mitz 2008-06-11 12:49:39 PDT
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).
Comment 9 Alexey Proskuryakov 2010-06-11 17:40:36 PDT
FWIW, I cannot reproduce this in Safari 4.0.5.