[this was originally filed as https://webcompat.com/issues/48606 - morphing that into a bugzilla bug.]

STR:

1. Open RDM (Ctrl+Shift+M)
2. Choose "Galaxy S9" as your device at the top-left of our RDM UI
3. Visit https://www.dochkisinochki.ru/icatalog/search.php?q=huggies
4. Scroll down (I'm using the mouswheel, scrolling a few "swipes", maybe 30-50% of the way down the page)
5. Scroll back up.

ACTUAL RESULTS:
Some of the time (around 30% of pageloads maybe?), there's blank white space between the page title and the menubar at the top. See attached screenshot. (Also, the scroll position "janks" while you're scrolling, though the stray blank space is the most prominent symptom of this.)

EXPECTED RESULTS:
No such blank space.

The blank area goes away when I use Firefox Screenshots to take a screenshot, or when I focus the node in DOM inspector (which draws a translucent overlay and hence does a little bit of flushing/drawing). This "instability" makes it seem likely that this is our bug rather than a bug in the site's own markup.

The top-menubar here has position:sticky. If I make it position:static, then the issue goes away (though of course that makes the menubar scroll offscreen, which the site doesn't want to happen).

Note:

• enabling/disabling webrender doesn't seem to make a difference
• enabling/disabling scroll anchoring doesn't seem to make a difference
• karlcow captured a performance profile in RDM mode, which may give us some clues about what's going on. I think some extra layout space is created (i.e. the .page wrapper-element gets its position suddenly changed) at around 3.2s , according to karlcow's observation of a jump at that point in the screenshots track: https://perfht.ml/2Tbk7gm

From karl's profile and also my own local testing, the jump seems to be associated with image-loads finishing. And images seem to get loaded lazily/dynamically, in the "tiles", as you scroll down the page. So there are a lot of images that load.

A single offscreen tile's DOM initially looks like this (notice the image URL in the meaningless "data-original" attribute):

<a href="/icatalog/products/9935160/" class="cat-item__img"
  data-original="https://static.dochkisinochki.ru/upload/resize_cache/img_loader/e9/9e/24/169_198_1/GL000884820_001_0001.jpg">
  <div class="uids-loader is-block">
    <div class="dots">
      <div class="dot"></div>
      <div class="dot"></div>
      <div class="dot"></div>
      <div class="dot"></div>
      <div class="dot"></div>

And then when you scroll the tile into view, the tile's DOM changes to this (notably: becoming display:block, getting a background-image, and losing its placeholder child elements).

<a href="/icatalog/products/9935160/" class="cat-item__img"
  data-original="https://static.dochkisinochki.ru/upload/resize_cache/img_loader/e9/9e/24/169_198_1/GL000884820_001_0001.jpg"
  style="display: block;
    background-image: url(&quot;https://static.dochkisinochki.ru/upload/resize_cache/img_loader/e9/9e/24/169_198_1/GL000884820_001_0001.jpg&quot;);"></a>

The element has the same height (40px) before vs. after this change, so the dynamic change isn't expected to impact the layout really. But it does, for some reason (in an "unstable"/heisenbuggy way that goes away when you focus the node in devtools).

I was browsing the issues with sticky positioning and I think this one is the same I'm having.
Although I cannot reproduce it on that website, here's a a jsfiddle that displays the same behaviour consistently on different devices and versions of Firefox:
https://jsfiddle.net/vctls/mac2Ls0d/16/

Video of the problem:
https://imgur.com/a/28KhPEY

In the case of this jsfiddle, this only happens when elements change size, and the container has an overflow property.
If you remove the overflow property on the container, or if you change the CSS rules on hover to make the animated icon at the bottom become blue, for example, instead of changing size, it does not produce the issue.

Daniel, do you know if this issue still exists?

I'm still not 100% sure if it's the same issue, but my JSFiddle still displays the same behavior on FF 103.0b9, while chromium handles it correctly.

(In reply to Dennis Schubert [:denschub] from comment #5)

Daniel, do you know if this issue still exists?

The original site seems to be down (403 forbidden). Not sure if it's really-down vs. geo-blocked outside of Russia (or something like that), but it seems we can't re-test at the moment.

(In reply to toulousevictor from comment #6)

I'm still not 100% sure if it's the same issue, but my JSFiddle still displays the same behavior on FF 103.0b9, while chromium handles it correctly.

Thank you for the fiddle & for confirming it's still problematic! I'm also not 100% sure it's the same issue, given the different sort of interaction required. So, I'm going to spin off a separate bug for your jsfiddle issue.

Thank you both!

Sure! FWIW, bug 1781297 is the bug that I spun off for the thing that toulousevictor rerported.