Bug 11109 - REGRESSION (r15471): menus are offset on eink.com
Summary: REGRESSION (r15471): menus are offset on eink.com
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 420+
Hardware: Macintosh OS X 10.4
: P1 Major
Assignee: Nobody
URL: http://www.eink.com/
Keywords: GoogleBug, InRadar, Regression
: 12294 12330 (view as bug list)
Depends on:
Blocks: 11582
  Show dependency treegraph
 
Reported: 2006-10-01 07:50 PDT by mitz
Modified: 2007-01-26 04:44 PST (History)
4 users (show)

See Also:


Attachments
Test case (expected values are based on Firefox and WinIE) (578 bytes, text/html)
2006-10-01 07:51 PDT, mitz
no flags Details
[WIP] Patch without change log (1.68 KB, patch)
2007-01-07 14:44 PST, mitz
no flags Details | Formatted Diff | Diff
Match Firefox's offset{Left,Top} behavior for objects whose containing block is the root (22.48 KB, patch)
2007-01-25 14:40 PST, mitz
darin: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description mitz 2006-10-01 07:50:36 PDT
The drop-down menus on eink.com are offset by 10px up and to the left since r15471 (fix for bug 9943). It turns out that the body's offsetLeft and offsetTop should be 0 (this part was fixed), but consequently the body's margins should be included in the offsetLeft/Top of any element whose offsetParent is the body. See the attached test case.
Comment 1 mitz 2006-10-01 07:51:33 PDT
Created attachment 10855 [details]
Test case (expected values are based on Firefox and WinIE)
Comment 2 mitz 2007-01-07 14:44:46 PST
Created attachment 12289 [details]
[WIP] Patch without change log

The behavior is slightly more subtle - although the body element is always in the offsetParent hierarchy, if it's static it's skipped over in offsetTop/Left computation. This patch fixes eink.com and doesn't fail any layout tests, but I still need to verify that it doesn't silently break any of the tests that use offset*.
Comment 3 Dave Hyatt 2007-01-07 15:19:28 PST
Double check quirks vs. strict mode here please to make sure the behavior in WinIE stays the same.

Comment 4 mitz 2007-01-08 08:23:04 PST
(In reply to comment #3)
> Double check quirks vs. strict mode here please to make sure the behavior in
> WinIE stays the same.
> 

Firefox behaves the same in both modes. IE's behavior is totally different: in strict mode it gives the body's true offsets, and in quirks mode it gives 0 and skips over the body regardless of whether it's positioned or not.
Comment 5 mitz 2007-01-17 04:10:52 PST
*** Bug 12294 has been marked as a duplicate of this bug. ***
Comment 6 David Kilzer (:ddkilzer) 2007-01-17 06:40:21 PST
Per Bug 12294 Comment #5:

<rdar://problem/4928707>

Comment 7 mitz 2007-01-25 12:25:43 PST
I think this is affecting the new format of Google Image Search results: the box around the hovered result is broken.
Comment 8 David Kilzer (:ddkilzer) 2007-01-25 12:44:06 PST
(In reply to comment #7)
> I think this is affecting the new format of Google Image Search results: the
> box around the hovered result is broken.

That sounds like Bug 12330.

Comment 9 Darin Adler 2007-01-25 14:33:41 PST
<rdar://problem/4824760>
Comment 10 mitz 2007-01-25 14:40:49 PST
Created attachment 12674 [details]
Match Firefox's offset{Left,Top} behavior for objects whose containing block is the root

Includes change log, layout test, and updated tests or results for tests that were relying on the old behavior.
Comment 11 Maciej Stachowiak 2007-01-25 22:25:16 PST
How does this compare to how IE does it? This may require a layout expert like hyatt to review.
Comment 12 Darin Adler 2007-01-25 23:38:07 PST
Comment on attachment 12674 [details]
Match Firefox's offset{Left,Top} behavior for objects whose containing block is the root

r=me
Comment 13 Mark Rowe (bdash) 2007-01-26 03:58:53 PST
Landed in r19149.
Comment 14 mitz 2007-01-26 04:44:03 PST
*** Bug 12330 has been marked as a duplicate of this bug. ***