Bug 206228 – element.style position DOM updates are laggy / not in sync

• Status: NEW
• Component: Layout and Rendering

Created attachment 387649 [details]
Demonstration of the problem

Minimal Example:

```html
<style>
  body {
    height: 5000px;
  }

  .popper {
    position: absolute;
    width: 100px;
    height: 100px;
    background: red;
  }

  #scrollContainer {
    position: relative;
    width: 300px;
    height: 300px;
    background: gray;
    overflow-y: scroll;
    left: 200px;
  }

  #scrollContainer::after {
    content: '';
    display: block;
    width: 1px;
    height: 900px;
  }
</style>

<div id="windowElement" class="popper"></div>

<div id="scrollContainer">
  <div id="scrollingContainerElement" class="popper"></div>
</div>

<script>
  window.addEventListener('scroll', () => {
    windowElement.style.top = `${window.pageYOffset}px`;
  });

  scrollContainer.addEventListener('scroll', () => {
    scrollingContainerElement.style.top = `${scrollContainer.scrollTop}px`;
  });
</script>
```html

When scrolling the main window/body, the element is not updated synchronously and "lags" behind its correct position. The one inside the scrolling container however is updated correctly. On iOS, both of these are laggy.

A popular overlay (tooltip, popover, drop-down) positioning engine Popper.js - https://popper.js.org/ - relies on this behavior being 1:1 (in-sync), otherwise unsightly lagging is visible. `position: fixed` has its own problems in other scenarios, so it cannot be used.

[Simon Fraser (smfr)]

Scroll events are, per spec, asynchronous. Other browsers do a better job of sending them in sync with scrolling than WebKit, but you should never rely on them to reposition things. Use position:sticky, position:fixed etc instead.

(In reply to Simon Fraser (smfr) from comment #1)
> Scroll events are, per spec, asynchronous. Other browsers do a better job of
> sending them in sync with scrolling than WebKit, but you should never rely
> on them to reposition things. Use position:sticky, position:fixed etc
> instead.

If I wrap the updates in `setInterval()` without any duration argument, so it updates as fast as possible, the problem remains the same.

Just want to point out as well that this library has 4M downloads/week on npm, and billions of hits across CDNs - it solves an important problem in web applications that many people rely on. It's used in the biggest UI libraries (Bootstrap and Material UI) and needs to constrain the position of the element within the viewport so it's visible for the user as best as possible. Tons of developers are using this library right now in production, and millions upon millions of users are experiencing it.

Its entire purpose is to reposition an element near another one in sync with the layout. The "Overlow Prevention" example in the website link is an example of this, and the lag in Safari defeats this purpose (which seems unrelated to async scroll events - which should(?) not show the same effect with setInterval).

Even if the problem is with async scrolling, perhaps the spec should be ignored or updated to account for this problem. The positioning property cannot be updated to `fixed/sticky` at will either due to a host of other problems it causes regarding clipping containers, and massively complicates library logic due to the need to switch based on a variety of conditions.

[Simon Fraser (smfr)]

Created attachment 387703 [details]
Testcase

[Simon Fraser (smfr)]

It hiccups in Chrome too sometimes.

The stutters in Chrome aren't great, but they seem to rarely happen (and for at most 1 frame) and match Safari's behavior inside scrolling containers. In the case of the window in Safari, the lag is much more severe, and it even seems to "transition" to the position rather than be at 1:1 in position as expected.

I may make an issue for the slight stutters in Chromium as well.