Bug 24426

Summary: Regression from r41207
Product: WebKit Reporter: Scott Violet <sky>
Component: WebCore Misc.Assignee: Nobody <webkit-unassigned>
Status: RESOLVED INVALID    
Severity: Normal CC: sam
Priority: P2 Keywords: Regression
Version: 528+ (Nightly build)   
Hardware: PC   
OS: Windows XP   
Attachments:
Description Flags
Test case for bug
none
Reduced test case none

Description Scott Violet 2009-03-06 10:05:28 PST
I'll attach a test case after I create the bug.

This can be seen with any of the chromium bug pages. When you edit a bug and click in one of the fields a DIV is moved to the location of the form field. The DIV is absolutely placed. The position is determined by getBoundingClientRect. Prior to 41207 this location was not relative to the viewport, so that setting the location of the div to that returned from getBoundingClientRect worked correctly. Now that getBoundingClientRect is relative to the viewport this code no longer works. The code is also attempting to offset by scrollTop (more specifically a.document.documentElement.scrollTop where a is the window), but that appears to be 0.

The script on this page isn't new, what is new is it hitting the getBoundingClientRect code. The script only executes this if getBoundingClientRect is defined.
Comment 1 Scott Violet 2009-03-06 10:07:58 PST
Created attachment 28365 [details]
Test case for bug

To repro do the following:
1. Click the button.
2. Notice the red div appears right beneath the button.
3. vertically scroll a bit.
4. click the button again.

Notice the red div is no longer placed beneath the button.

The script in the test is rather ugly as it's reduced from a real page. I could certainly create a more reduced test case, but I thought you might want to see how this ever worked prior to adding getBoundingClientRect.
Comment 2 Scott Violet 2009-03-06 10:34:21 PST
FF's getBoundingClientRect is relative to the viewport, just as ours is after Sam landed 41207. Given that, I suspect this is a bug in the page. The page is assuming 'window.document.documentElement.scrollTop' returns the vertical offset, but that doesn't appear to have ever been the case in WebKit. It works in FF though.

I'm going to leave open just to make sure this was intentional. Sam, please close if you think this is a bug in the page.
Comment 3 Scott Violet 2009-03-06 10:41:34 PST
Created attachment 28367 [details]
Reduced test case

Here's a more reduced test case given my knowledge of the bug. It basically comes down to repositioning a div with the following code:

  var scrollTop = window.document.documentElement.scrollTop;
  var targetYLoc = target.getBoundingClientRect().top;

  var b = document.getElementById("adiv");
  b.style.top = (scrollTop + targetYLoc) + "px";
Comment 4 Sam Weinig 2009-03-06 15:05:40 PST
I suspect this is a bug in your page since we match Firefox.