Bug 16774 – REGRESSION (r27464-r27504) javascript popup menu does not display 'close' button

• Status: RESOLVED
• Resolution: FIXED
• Component: Layout and Rendering

[Cameo Wood]

1. Go to http://www.parkplaza.com/londonuk_sherlockholmes
2. Choose an arbitrary check-in and check out date, hit 'go'
3. click on the 'hot deal' or other room/rate description links
4. The box should appear, but not the 'close' button in the top upper right of the window, on the grey bar.

[Matt Lilek]

(In reply to comment #0)
> 4. The box should appear, but not the 'close' button in the top upper right of
> the window, on the grey bar.
> 

Just to clarify, a box *will* appear, but the close button in the upper right *won't* appear.

This is a regression from Leopard.

[David Kilzer (:ddkilzer)]

Not just a windows bug; occurs with a local debug build of WebKit r29227 with Safari 3.0.4 (523.12.2) on Mac OS X 10.4.11 (8S165).

[David Kilzer (:ddkilzer)]

I tried running bisect-builds on this bug, but the range keeps changing.  There seems to be a race condition that happens when the "close" button is drawn versus how the rest of the window is drawn.

The results I've had (both "Works" revisions have been invalidated by rechecking the range):

Works: r27595  Fails: r27628
Works: r27504  Fails: r27582

You can prove to yourself that the "close" button is still present by double-clicking on the link that brings up the "pop-up" menu.  It causes a drawing issue with the JavaScript, but after two or three double-clicks, you'll see the "close" button reappear.

Created attachment 18696 [details]
Reduction

Works: r27464  Fails: r27504

Probably <http://trac.webkit.org/projects/webkit/changeset/27486> or <http://trac.webkit.org/projects/webkit/changeset/27504>.

Created attachment 18700 [details]
Patch, including change log and pixel test

Perhaps some further explanation is in order: this is the case where the parent is "returning" a float to the child because it is no longer overhanging from the parent. In most circumstances when this happens, the child needs layout, so it reclaims the float anyway, but not in this particular case. If the parent becomes shorter again, it will scan its children for overhanging floats and reclaim them (that is what the code added in r27486 does).

[Darin Adler]

Comment on attachment 18700 [details]
Patch, including change log and pixel test

I was waiting for Hyatt to review this, but I think I've waited long enough.

Looks right. r=me

Fixed in <http://trac.webkit.org/projects/webkit/changeset/29834>.