Bug 10983 – REGRESSION (r12290): Drop shadow of flickr photo note is positioned incorrectly the second time it's shown

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

If you go to the URL and mouse over the photo and into the note square, the note shows up. The first time it looks ok, but on subsquent mouseovers the drop shadow is positioned a few pixels above where it should be.

The regression appears to be in r12290 (fix for bug 3508).

Created attachment 10700 [details]
Partial reduction

Created attachment 10703 [details]
Root cause? (not a regression)

The partial reduction reduced to this case, which renders incorrectly in shipping Safari too. In TOT, the positions are corrected at the next relayout, e.g. if you resize the window or mousedown on a button (even before releasing it), whereas in shipping Safari, hiding and showing will reproduce the bad layout. Looks like Flickr actually expects the bad layout.

[Dave Hyatt]

So did Firefox match our rendering for 3508?

(In reply to comment #3)
> So did Firefox match our rendering for 3508?
> 

No, Firefox matches TOT. Flickr possibly tries to work around the bug in shipping Safari (by "the bug" I don't mean bug 3508, but rather the fact that dynamically setting the margin results in incorrect layout). I think the bottom line is that TOT is broken, but shipping Safari is even more broken.

Looks like Firefox, Opera and (normally) WebKit collapse the margins between a static box and an absolutely positioned box, which http://www.w3.org/TR/CSS21/box.html#collapsing-margins suggests that you shouldn't do (the spec doesn't make an exception for "absolutely positioned with top: auto"). WinIE doesn't do that.

I think the positioning of the note in http://flickr.com/photos/jhawke/231017499/in/set-72057594049560325/ (when you're not logged in to flickr, so there's no toolbar between the title and the photo) is wrong in Firefox and Opera. In WebKit it happens to be positioned correctly only because it's dynamic, but the drop shadow eventually moves up.

Hyatt explained to me that the "collapsing" is correct, but it isn't really collapsing: with 'top' and 'bottom' being 'auto', you set the vertical margins to 'auto' and use the static position, according to case 2 of http://www.w3.org/TR/CSS21/visudet.html#abs-non-replaced-height .

Flickr will need to change their website to lay out correctly in Firefox and -- once this bug is fixed -- WebKit.

[David Kilzer (:ddkilzer)]

(In reply to comment #6)
> Flickr will need to change their website to lay out correctly in Firefox and --
> once this bug is fixed -- WebKit.

Is a separate evangelism bug needed to track this?

Created attachment 12065 [details]
"Static position" test case

Here is a simple case, which has not changed between shipping WebKit and TOT.

Created attachment 12652 [details]
Ensure proper relayout when the static y position changes.

Includes a test for three cases fixed by this patch and another one that has been fixed but doesn't have a test.

[Darin Adler]

Comment on attachment 12652 [details]
Ensure proper relayout when the static y position changes.

Looks good to me, but I'm slightly out of my depth. Needs a layout expert review.

[Maciej Stachowiak]

Comment on attachment 12652 [details]
Ensure proper relayout when the static y position changes.

I'm sufficiently convinced by the test cases and the relatively simple changed, plus the fact that Mitz himself is a layout expert.

[Mark Rowe (bdash)]

Landed in r19148.