Steps to reproduce: 1. Open WebKit nightly. 2. Log into WWDC 2006 Attendee Site. https://developer.apple.com/wwdc2006/ Expected results: The green menu should be the same height all the way across. Actual results: The green menu is 2 pixels short on the "My Agenda" menu item. Regression: The menu draws correctly on production Safari 2.0.4 (419.3) on Mac OS X 10.4.7 (8J135/PowerPC). Firefox 1.5.0.4 also draws the menu correctly on the same OS X. Notes: Tested with locally-built debug build of WebKit r15633.
Created attachment 9693 [details] Screenshot showing menu issue
Created attachment 9694 [details] Partial reduction test case
I think this is a regression from the shadow repaint bug fix(es), bug 7301. Shadow is added to the inlines' overflow rect, and table cells are sized to contain all overflows. I don't know how to fix it :-(
Created attachment 9701 [details] Further reduction The padding-bottom: 1px on the span is necessary. I don't know why.
The problem is there's visual overflow and layout overflow. (The former includes the latter but not vice versa). Although it's annoyingly complicated, maybe we need to separate the two (and have two rects instead of just one).
The custom highlight code I just added in my last check-in has the same issue. It's intended to be purely visual overflow and should not have affected layout. So shadow and highlight are both suffering from this problem now.
Radar <rdar://problem/4959690>
The patch I just posted for bug 12123 (attachment 13090 [details]) fixes this bug as well.
Even more reduction: <table style="border:1px solid black;"> <tr><td style="border:1px solid blue;text-shadow:gray 100px 100px;">Shadowed Text</td></tr> </table> This shows that on tip of tree, the vertical (but not horizontal) shadow offset is affecting the height of the enclosing td, and thus the enclosing table. In released Safari, the td and table size ignore the shadow offset. This doesn't happen on browsers that don't support text-shadow, of course. I don't know what the expected behavior is here, but it seems clear that what we're doing now is wrong. One of the following seems like it must be true: 1) the shadow offset should not affect the enclosing td size at all 2) the shadow offset should affect both the width and height of the enclosing td If (1) is true, then this is a regression from correct behavior in Safari 2.0.4. If (2) is true, then the change is part-way towards the correct behavior.
The patch for bug 12123 (r19588) fixed this bug as well.
Reopening because r19588 was rolled out.