1832675 - Jittery scrolling on nodejs.org (and generally, at pages with `content-visibility:auto` and huge discrepancy between elements' `contain-intrinsic-size` vs. their actual content height)

Status: RESOLVED DUPLICATE of bug 1804761

(Core :: Layout, defect)

Description

[Ksenia Berezina [:ksenia]]

We've received a report in https://github.com/webcompat/web-bugs/issues/121843 about the issue with scrolling on nodejs.org

To reproduce, visit https://nodejs.org/docs/latest-v16.x/api/process.html#processplatform in Nightly (2023-05-11) and try to scroll by dragging the scroll bar up or down.

Expected:
Content is visible

Actual:
Content is not visible, sometimes the page jitters (also jittering happens on the initial load)

Same happens when trying to navigate to anchors links by clicking on any anchor links under "Process" in the Table of contents at the top of the page. When scrolling with the mousewheel, I don't seem to be experiencing the same issue.

From mozregression:

Differential Revision: https://phabricator.services.mozilla.com/D171514

2023-05-09T00:24:02.071000: DEBUG : Did not find a branch, checking all integration branches
2023-05-09T00:24:02.073000: INFO : The bisection is done.
2023-05-09T00:24:02.074000: INFO : Stopped

Comment 1

[Ksenia Berezina [:ksenia]]

Attachment: testcase 1 (partially reduced)

I've attached a slightly reduced test case

Comment 2

[Ksenia Berezina [:ksenia]]

Hi Daniel, wonder if you could take a look at this, please?

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1820058

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (further reduced)

Comment 5

[Daniel Holbert [:dholbert]]

Thanks, Ksenia! Triaging as S3 since this is Nightly-only for the time being. This does look quite bad and is something we should fix before letting content-visibility make it any further towards release.

This seems to have to do with there being an extreme discrepancy between the declared contain-intrinsic-size on an element vs. its actual size (which we find out when it becomes "relevant to the user" i.e. appears on-screen, per content-visibility:auto). In this case, we seem go get into trouble when updating the scroll position to account for that.

Some observations, using testcase 2:

• A lot of the weirdness here seems to be related to whether or not you initiate a scroll while a smooth-scroll operation is happening. This part can be somewhat mitigated (for testing purposes) by turning off smooth scrolling in Firefox preferences. In my notes below, the references to "generous pause" are for the purposes of letting the smooth-scroll complete; those pauses can be omitted if you've disabled smooth scrolling.

• If I scroll to the end of the page slowly by repeatedly pressing PageDn (with a generous pause between each keypress to let smooth-scroll complete), then everything seems to work just fine (aside from the scrollbar jumping a bit which is expected due to discovering the contain-intrinsic-size discrepancy).

• The same is true if I start at the end of the page (pressing End) and then repeatedly press the "up" arrow-key in the same way (allowing any smooth scroll operations to complete).

• However, PageUp is broken. If I start at the end and press PageUp a few times (with a pause between each keypress), I end up looking at a series of blank screens with intermediate scroll positions, and then I end up looking at the bottom of the page again.

• Similarly, if I mousewheel-scroll, or try to scroll while a smooth-scroll is already taking place (e.g. by holding down or rapidly pressing up/down/PageUp/PageDn), then I get similar weirdness.

Comment 6

[Daniel Holbert [:dholbert]]

asurkov, I believe you're looking at some content-visibility bugs -- maybe you could take a look at this one?

Comment 7

[Emilio Cobos Álvarez (:emilio)]

Attachment: Flickering.webm

I see that page flicker a ton when it probably shouldn't. It seems we're not using the last remembered size properly / are forgetting it at one point which causes the flicker between states?

Comment 8

[Oriol Brufau [:Oriol]]

This is basically https://github.com/w3c/csswg-drafts/issues/8407

Using content-visibility: auto without contain-intrinsic-size: auto is a very bad idea, so we resolved

RESOLVED: content-visibility: auto forces contain-intrinsic-size to gain an auto value

Indeed if I use contain-intrinsic-size: 1px auto 5000px, the behavior is much better.

Comment 9

[Daniel Holbert [:dholbert]]

(In reply to Oriol Brufau [:Oriol] from comment #8)

Using content-visibility: auto without contain-intrinsic-size: auto is a very bad idea, so we resolved

RESOLVED: content-visibility: auto forces contain-intrinsic-size to gain an auto value

Aha. I just poked the mozilla-apprentice bot to file a bug for this resolution: bug 1832706 , which I've added as a dependency.

Indeed if I use contain-intrinsic-size: 1px auto 5000px, the behavior is much better.

Cool! It sounds like that might happen automagically under-the-hood as part of bug 1832706, without the site needing to change its style. Hypothetically, we could submit a pull request to directly change this in the NodeJS docs, specifically this line:
https://github.com/nodejs/node/blob/745083abb4a73ba1f5a3441db706bdfdeaed2243/doc/api_assets/style.css#L439

...but maybe that's not worth doing, given that our content-visibility support is Nightly-only right now, and bug 1832706 will fix this on Nightly. (if I'm understanding correctly)

Comment 10

[alexander :surkov (:asurkov)]

it could be a dupe of bug 1804761, especially if bug 1832706 will likely fix this one.

Comment 11

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #9)

Cool! It sounds like that might happen automagically under-the-hood as part of bug 1832706, without the site needing to change its style. Hypothetically, we could submit a pull request to directly change this in the NodeJS docs, specifically this line:
https://github.com/nodejs/node/blob/745083abb4a73ba1f5a3441db706bdfdeaed2243/doc/api_assets/style.css#L439

...but maybe that's not worth doing, given that our content-visibility support is Nightly-only right now, and bug 1832706 will fix this on Nightly. (if I'm understanding correctly)

Hopefully we can still fix this (via bug 1832706) soon, but in the meantime I submitted https://github.com/nodejs/node/pull/48195 to fix this in the node.js docs themselves (adding the auto value explicitly, per Oriol's observation in comment 8).

Comment 12

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #11)

Hopefully we can still fix this (via bug 1832706) soon

Update: this is fixed (via bug 1832706's dupe-target, bug 1804761) in today's Nightly. i.e. that change effectively fixes this bug, hence, duping to that bug.

Note that the nodeJS docs (e.g. the page linked in comment 0) may still scroll a bit oddly (e.g. scrollbar jumping a different distance than you might expect, and/or content possibly doing a one-off jitter when scrolling) -- but that happens for Chrome as well (because the page is declaring offscreen elements to be 5000px tall despite them being quite short in some cases). That remaining issue is not our bug, and the NodeJS folks have https://github.com/nodejs/node/issues/40099 to track this on their end.

but in the meantime I submitted https://github.com/nodejs/node/pull/48195 to fix this in the node.js docs themselves

Closing the loop on this: that^ pull request was merged, but it hasn't made it to their publicly-visible stylesheet yet (https://nodejs.org/docs/latest/api/assets/style.css still has contain-intrinsic-size: 1px 5000px -- my pull request adds auto between the two px values there). And per this comment it might not make it to the version-specific URL that was in comment 0 here.

Anyway: that pull request shouldn't make a meaningful difference to Firefox Nightly users, now that bug 1804761 has made us do the same change that the pull request is doing automatically, under the hood. (Also, content-visibility is still only enabled in Nightly at this point, so other release channels aren't affected.)