Images are flickering in Firefox, but not Chrome, when scrolling around on diverse.direct
Categories
(Core :: Graphics: ImageLib, defect)
Tracking
()
Webcompat Priority | P3 |
People
(Reporter: twisniewski, Assigned: tnikkel)
References
(Blocks 1 open bug, )
Details
As diagnosed in https://github.com/webcompat/web-bugs/issues/100993, the product gallery code at https://diverse.direct/ is flickering in Firefox because on every DOM scroll event, they are un-setting and then re-setting the images' src elements. This causes a bad flickering effect in Firefox on their gallery images as the user scrolls the page.
I consider this an issues with their site's code, but Chrome seems to manage to avoid this flickering despite running the same code (although that may be a fluke, as when I open the devtools then Chrome also visually struggles).
But it does not seem as though it may be trivial for the site to fix their code, and we have a long-standing bug related to such image flickering, so I'm wondering if we can do something to avoid this flickering in Firefox as well.
Reporter | ||
Comment 1•2 years ago
•
|
||
Note that this flickering is still a general webcompat issue, as I just found another webcompat.com report that boils down to the same difference in behavior with image decoding defaulting to sync on Chrome (which I believe is how Chrome manages to avoid the problem, if memory serves). The other site is https://github.com/webcompat/web-bugs/issues/80232, and while we can probably trivially work around the issue there, there are likely many other sites affected as they are relying on a library named leaflet to do the image-shuffling, not their own code: https://leafletjs.com/
So I suspect it would be worth revisiting this issue in general.
Assignee | ||
Comment 2•2 years ago
|
||
Two things combine to make this particular site bad in Firefox.
src = "" is treated in Gecko as web content telling us to immediately discard the decoded surface, this dates back to the b2g days (bug 854799 has some context).
Normally the setting of the src in quick succession like that would force sync decoded and we, but bug 1787072 means we reframe when going from src="" to src="someurl" and back. That means we call nsImageLoadingContent::FrameCreated and then MaybeForceSyncDecoding, we don't go into the aPrepareNextRequest if block, and so we clear the sync decoding hint we just set milliseconds ago.
Reporter | ||
Comment 3•2 years ago
|
||
Oops, I added the wrong link in comment #1. I meant to link to this firesmoke.ca issue, https://github.com/webcompat/web-bugs/issues/80232
Reporter | ||
Updated•2 years ago
|
Assignee | ||
Updated•2 years ago
|
Reporter | ||
Updated•2 years ago
|
Comment 4•2 years ago
|
||
The severity field is not set for this bug.
:aosmond, could you have a look please?
For more information, please visit auto_nag documentation.
Assignee | ||
Updated•7 months ago
|
Description
•