Open Bug 1787288 Opened 2 years ago Updated 8 months ago

Images are flickering in Firefox, but not Chrome, when scrolling around on


(Core :: Graphics: ImageLib, defect)

8 Branch
Windows 7



Webcompat Priority P3


(Reporter: twisniewski, Assigned: tnikkel)


(Blocks 1 open bug, )


As diagnosed in, the product gallery code at 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.

Note that this flickering is still a general webcompat issue, as I just found another 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, 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:

So I suspect it would be worth revisiting this issue in general.

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.

Oops, I added the wrong link in comment #1. I meant to link to this issue,

Assignee: nobody → tnikkel
Webcompat Priority: --- → P3

The severity field is not set for this bug.
:aosmond, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(aosmond)
Blocks: 1801052
Severity: -- → S3
Flags: needinfo?(aosmond)
You need to log in before you can comment on or make changes to this bug.