Found while fuzzing m-c 20220105-138105a14659 (--enable-debug --enable-fuzzing)

To reproduce via Grizzly Replay:

$ pip install fuzzfetch grizzly-framework
$ python -m fuzzfetch -d --fuzzing -n firefox
$ python -m grizzly.replay ./firefox/firefox testcase.zip

LQC Signature: tag-div,x-extreme,left-extreme,right-extreme

LQC Results:
Conflicting dimensions for element two<div>
    Dimensions after reload: {"x":1371.683349609375,"left":1371.683349609375,"right":1424.683349609375}
    Dimensions after modify: {"x":4855.10009765625,"left":4855.10009765625,"right":4908.10009765625}
END of LQC Results
CSS Styles Used: {
    "base_styles": [
        "background-color",
        "border-right-style",
        "inset-inline-start",
        "min-height",
        "min-width",
        "overflow-x",
        "position",
        "transform",
        "width"
    ],
    "modified_styles": [
        "padding-block-start"
    ]
}

If a Pernosco session would be helpful please ni? :tsmith.

Bugmon Analysis
Unable to reproduce bug 1748891 using build mozilla-central 20220105170324-138105a14659. Without a baseline, bugmon is unable to analyze this bug.
Removing bugmon keyword as no further action possible. Please review the bug and re-add the keyword for further analysis.

I can reproduce. STR are
(1) Load testcase.html
(2) F12 to open console
(3) inspect the logged output

I see:

Dimensions after style changes, before reload
#two 
Object { x: 4855.10009765625, left: 4855.10009765625, right: 4908.10009765625 }

Dimensions after reload
#two 
Object { x: 1371.683349609375, left: 1371.683349609375, right: 1424.683349609375 }

(All three values are substantially larger in the "after style changes" part)

Here's a further-reduced testcase, which I've also edited to be less-fully-automated, so you can see the rendering after the initial load + dynamic-style-change, and see how it changes when the DOM is reserialized.

In Chrome, when you load this testcase, the yellow-and-teal element is visible (and there's no rendering difference and no difference in the console.log output when you click the button)

In Firefox, when you first load this testcase, the scrollable area is fully pink. When you click the button, the yellow-and-teal element appears. (Also: scrolling is a bit horked -- if you load the testcase and try to scroll right by e.g. clicking the pink area and then pressing rightarrow on your keyboard, the scrollbar moves very slowly & jittery; it looks like we're continuously pushing the yellow and teal element out-of-view which is forever creating more scrollable distance.)

Here's a further-reduced testcase.

Side note, this is kinda related to the discussion on https://bugs.chromium.org/p/chromium/issues/detail?id=1327794

There's still a bit I don't understand about Chrome's behavior there, but one thing that came out of the discussion is that Chrome is computing scrollable overflow by assuming the sticky-positioned element is at its static position.

If we did that, I think that would fix this issue.