Bug 1585378 Comment 10 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

(In reply to andre from comment #9)
> Enabling webrender doesn't solve the problem on my machine unfortunately.

Ok, thanks for testing.

> The issue you linked (and the issues stemming from there) do indeed seem similar, and have been open for years. Is this something that's unlikely to be fixed anytime soon then? Any timing related information you could share would be appreciated so that we might communicate to our customers and/or attempt workarounds.

Bug 1424714 is fairly high on my priority list, and I hope to do a pass over it and other position:sticky correctness bugs fairly soon after work on desktop zooming (my current project) quiets down a bit. (And subsequently to that, a pass over issues of scrolled content checkerboarding as well, because I think we can do better for simple pages like this testcase.) Let's say Q1 2020.

I did think about bug 1424714 a bit just now, to see if there's a quick fix we could deploy. I suspect the root cause is related to the issue described in bug 1548397 comment 6 (another position:sticky correctness bug), which will at least need some discussion with coworkers who are on vacation until January, so I wouldn't expect any movement before then.

In terms of a workaround, making the elements position:fixed instead of position:sticky should solve the problem. That should be doable for the attached testcase (since the top and sides are in fact fixed in place throughout), but of course I don't know if that generalizes to your actual application.

I will mark this bug as depending on bug 1424714, so we re remember to test this page after that bug fixed.
(In reply to andre from comment #9)
> Enabling webrender doesn't solve the problem on my machine unfortunately.

Ok, thanks for testing.

> The issue you linked (and the issues stemming from there) do indeed seem similar, and have been open for years. Is this something that's unlikely to be fixed anytime soon then? Any timing related information you could share would be appreciated so that we might communicate to our customers and/or attempt workarounds.

Bug 1424714 is fairly high on my priority list, and I hope to do a pass over it and other position:sticky correctness bugs fairly soon after work on desktop zooming (my current project) quiets down a bit. (And subsequently to that, a pass over issues of scrolled content checkerboarding as well, because I think we can do better for simple pages like this testcase.) Let's say Q1 2020.

I did think about bug 1424714 a bit just now, to see if there's a quick fix we could deploy. I suspect the root cause is related to the issue described in bug 1548397 comment 6 (another position:sticky correctness bug), which will at least need some discussion with coworkers who are on vacation until January, so I wouldn't expect any movement before then.

In terms of a workaround, making the elements position:fixed instead of position:sticky should solve the problem. That should be doable for the attached testcase (since the top and sides are in fact fixed in place throughout), but of course I don't know if that generalizes to your actual application.

I will mark this bug as depending on bug 1424714, so we re remember to test this page after that bug is fixed.

Back to Bug 1585378 Comment 10