Bug 176053 – Element positioned with getBoundingClientRect() inside position fixed element is rendered in wrong place

• Status: NEW
• Component: CSS

[Wart Claes]

Created attachment 319253 [details]
test case

When dynamically placing an element with position: absolute inside an position: fixed element renders in the wrong place.

This has been tested in:
- iPhone 7+: iOS 11 public beta 7:  incorrect
- iPhone 7:  iOS 10.3.3:            correct
- iPhone 7+: iOS 10.2:              correct

## Steps to reproduce:
1) Open attached test case
2) Scroll down
3) Click button

## Expected result
A pink block should be shown on top of the button.

## iOS 11 result
The pink block is positioned to high on the page.

[Wart Claes]

Any updates about this?

[Radar WebKit Bug Importer]

<rdar://problem/34384669>

[Wart Claes]

After some debugging I reduced the issue to a wrong value passed from Element.getBoundingClientRect(). On iOS 11 I get a different value then on iOS 10, in most cases even a negative value, which would be weird since the clicked button is in view.

[Simon Fraser (smfr)]

This sounds related to bug 174286, but that was fixed I think before beta 7. Can you test a more recent build?

[Wart Claes]

I tested it today in iOS 11 GM and it still happens. But it does sound similar.

My workaround at the moment is checking in each animationframe if the returned values are stable. This way I can "fix" the issue.

[Simon Fraser (smfr)]

This is about getBoundingClientRect.

[Simon Fraser (smfr)]

When you click the button here's what happens:
1. You read scrollTop (pageYOffset)
2. The main content is set as position:fixed, and given a negative top offset. This removes it from the main flow, so the previously scrollable document now has no scrolling content and shrinks; at this point it's scrollTop should be 0
3. The popup is positioned using an offset inside the position:fixed computed from the old scrollTop and getBoundingClientRect().top.

The bug on iOS is that at step 2, we don't synchronously set the new 0,0 scroll position in the document; this happens later in a message from the UI process. This causes getBoundingClientRect() to use a wrong FrameView::documentToClientOffset() since visibleContentRect().location() is stale.

[Simon Fraser (smfr)]

On macOS this works because we reset the scroll position here:

  * frame #0: 0x00000005ea7b1ac3 WebCore`WebCore::ScrollView::updateScrollbars(this=0x00000005fee00ed0, desiredPosition=0x00007ffee90f2430) at ScrollView.cpp:737
    frame #1: 0x00000005ea7b26df WebCore`WebCore::ScrollView::setContentsSize(this=0x00000005fee00ed0, newSize=0x00007ffee90f2560) at ScrollView.cpp:349
    frame #2: 0x00000005ea606b5f WebCore`WebCore::FrameView::setContentsSize(this=0x00000005fee00ed0, size=0x00007ffee90f2560) at FrameView.cpp:599
    frame #3: 0x00000005ea608533 WebCore`WebCore::FrameView::adjustViewSize(this=0x00000005fee00ed0) at FrameView.cpp:631
    frame #4: 0x00000005ea60b061 WebCore`WebCore::LayoutContext::layout(this=0x00000005fee012e0) at LayoutContext.cpp:198
    frame #5: 0x00000005e9d65ffa WebCore`WebCore::Document::updateLayout(this=0x00000005fd59e000) at Document.cpp:1992
    frame #6: 0x00000005e9d6b83e WebCore`WebCore::Document::updateLayoutIgnorePendingStylesheets(this=0x00000005fd59e000, runPostLayoutTasks=Asynchronously) at Document.cpp:2006
    frame #7: 0x00000005e9e0a6cf WebCore`WebCore::Element::boundingClientRect(this=0x000000060379d348) at Element.cpp:1212
    frame #8: 0x00000005e9e0aa63 WebCore`WebCore::Element::getBoundingClientRect(this=0x000000060379d348) at Element.cpp:1241

via the call to adjustScrollPositionWithinRange(). We probably need to do something similar on iOS.