Bug 24426 - Regression from r41207
Summary: Regression from r41207
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Windows XP
: P2 Normal
Assignee: Nobody
URL:
Keywords: Regression
Depends on:
Blocks:
 
Reported: 2009-03-06 10:05 PST by Scott Violet
Modified: 2009-03-06 15:05 PST (History)
1 user (show)

See Also:


Attachments
Test case for bug (4.86 KB, text/html)
2009-03-06 10:07 PST, Scott Violet
no flags Details
Reduced test case (1.40 KB, text/html)
2009-03-06 10:41 PST, Scott Violet
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
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.