| Summary: | REGRESSION: Main menu positioned incorrectly on eia.org and fedex.com/us | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | mitz | ||||
| Component: | New Bugs | Assignee: | Nobody <webkit-unassigned> | ||||
| Status: | VERIFIED FIXED | ||||||
| Severity: | Normal | CC: | bdakin, daniele.metilli | ||||
| Priority: | P1 | Keywords: | NeedsReduction, Regression | ||||
| Version: | 420+ | ||||||
| Hardware: | Mac | ||||||
| OS: | OS X 10.4 | ||||||
| URL: | http://www.eia.org/ | ||||||
| Attachments: |
|
||||||
|
Description
mitz
2006-03-30 09:48:47 PST
This bug seems to be caused at least in part by offsetTop() returning the wrong offset, for the same underlying reason as bug 8081. I tried skipping table rows in RenderObject::offsetTop() but it didn't fix the bug completely, only moved the menu up. This bug is seen also in http://fedex.com/us/ . I also noticed that the EIA site behaves differently when I set the user agent to Netscape 7 (still off, but not by as much), so maybe they have Safari-specific code to work around the old behavior where table rows' offsetTop was 0, and the fix for this bug is really not to add table rows in RenderObject::offsetTop(). Created attachment 7489 [details] Fix table cells' offsetTop This patch fixes fedex.com and the site mentioned in bug 8151 but not eia.org. I think the latter either has Safari-specific code to accommodate the old behavior (of rows' offsetTop being 0) or there's a different bug affecting it. fast/dom seems like the wrong place for the layout test. Feel free to relocate it when-if landing. |