So it is sticky-specific in the sense that the code path isn't really taken e.g. for the `fixed` element, but the root cause is with the computation of horizontal scroll. We end up trying to center the scroll target horizontally, and this means that we end up with a negative scroll offset. This causes the bailout code in Bug 2019912 Comment 1 to be skipped. I've modified the testcase's scroll target, `#target`, to use a `display: block` element (i.e. `<div>`) - With `width: fit-content`, the negative scroll offset prevents the bailout, leading to the buggy behaviour. OTOH, setting `width: 100vw` causes the target horizontal scroll offset 0, avoiding the buggy behaviour. I would think that the the scroll offsets should be clamped to prospective min/max values, but we in fact [force the range](https://searchfox.org/firefox-main/rev/af3c77e22f88ca06e1b4ac822c1d056f263a64fe/layout/base/PresShell.cpp#3426-3428) to include the computed offset, which is curious. It points to bug 681192, which I will have to investigate a bit.
Bug 2019912 Comment 3 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
So it is sticky-specific in the sense that the code path isn't really taken e.g. for the `fixed` element, but the root cause is with the computation of horizontal scroll. We end up trying to center the scroll target horizontally, and this means that we end up with a negative scroll offset. This causes the bailout code in Bug 2019912 Comment 1 to be skipped. I've modified the testcase's scroll target, `#target`, to use a `display: block` element (i.e. `<div>`) - With `width: fit-content`, centering the target would involve scrolling left, which computes as a negative scroll offset. This prevents the bailout, leading to the buggy behaviour because `originalScrollPt` is based on `GetVisualViewportOffset()`, which wouldn't include this negative scroll offset. OTOH, setting `width: 100vw` causes the target horizontal scroll offset 0, avoiding the buggy behaviour. I would think that the the scroll offsets should be clamped to prospective min/max values, but we in fact [force the range](https://searchfox.org/firefox-main/rev/af3c77e22f88ca06e1b4ac822c1d056f263a64fe/layout/base/PresShell.cpp#3426-3428) to include the computed offset, which is curious. It points to bug 681192, which I will have to investigate a bit.