Bug 11109

Summary: REGRESSION (r15471): menus are offset on eink.com
Product: WebKit Reporter: mitz
Component: DOMAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Major CC: darin, enadil, hyatt, jluisfa
Priority: P1 Keywords: GoogleBug, InRadar, Regression
Version: 420+   
Hardware: Mac   
OS: OS X 10.4   
URL: http://www.eink.com/
Bug Depends on:    
Bug Blocks: 11582    
Attachments:
Description Flags
Test case (expected values are based on Firefox and WinIE)
none
[WIP] Patch without change log
none
Match Firefox's offset{Left,Top} behavior for objects whose containing block is the root darin: review+

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. ***