"Flash" of the background showing when replacing an image via img.src - even when pre-cached

(NeedInfo from)



3 years ago
9 months ago


(Reporter: stig, Unassigned, NeedInfo)


(4 keywords)

38 Branch
parity-chrome, parity-edge, regression, testcase
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr52 wontfix, firefox55 wontfix, firefox56 wontfix, firefox57 fix-optional, firefox58 ?)


(Whiteboard: [gfx-noted])


(9 attachments)



3 years ago
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20160407164938

Steps to reproduce:

Via javascript replacing an image by assigning a new to the src attribute.

Actual results:

Flicker occurs showing a "flash" of the background. Might mostly be with big images, but pre-caching the new image doesn't help. Test case included as attachment. Tested on several Windows PCs and both with 32bit and 64bit versions of Firefox.

Expected results:

In previous versions of Firefox (44 and earlier) no flicker was seen. Even without pre-caching the new image, replacement was smooth.
In other browsers like IE, Edge, Opera and Chrome the replacement also happens smooth - with or without pre-caching.


3 years ago
OS: Unspecified → Windows


3 years ago
Attachment #8745044 - Attachment description: imagereplace.html → Testcase to demonstrate issue.


3 years ago
Attachment #8745044 - Attachment description: Testcase to demonstrate issue. → Testcase to demonstrate and verify issue.

Comment 1

3 years ago
Setting some keywords - hope I don't do anything wrong with that.
Keywords: regression, reproducible, testcase, verifyme

Comment 2

3 years ago
What do you mean by "flash"? Because I don't see any flash of the background image when loading or refreshing the testcase.
Flags: needinfo?(stig)


3 years ago
Keywords: reproducible, verifyme
OS: Windows → Windows 10
Hardware: Unspecified → x86_64

Comment 3

3 years ago
(In reply to Loic from comment #2)
> What do you mean by "flash"? Because I don't see any flash of the background
> image when loading or refreshing the testcase.

Thanks very much for taking a look. The testcase cycles through two image-files, changing every 3rd second. It's not meant to be manually refreshed/reloaded, just let it run a few seconds. And at least when going from low-res to high-res image-file, I see a very dominant "glimpse" of the black background I have put behind the image (the first coming 3 seconds after the onload event and then every 6th second). I see this behavior on all Windows PC I have tested on (2x Win10 and 1x WinXP - On Win10 with both 32bit and 64bit versions of the browser). I will try to verify if same behavior on some work-PCs tomorrow. I have not tested on any non-Windows PC, so have no idea if it is OS-related. It was introduced with Firefox 45 (Not 100% sure if from 45.0.0 or 45.0.1, but first sounds most likely). Would it be relevant for me to try to find some way to do a screen-recording?
Flags: needinfo?(seth)

Comment 4

3 years ago
I tried again, I am not able to reproduce the "flash" of the background. Could you attach a screencast, maybe?

Comment 5

3 years ago
Just tried at work on a Windows 7 (Enterprise) PC with Firefox 45.0.2 (in safe mode) and again in latest version 46 when the browser updated just after. 64bit versions. Same issue seen. So now I have seen it on all Windows PC I have tested on. 1x WinXP (32bit), 1x Win7 (64bit) and 2x Win10 (32&64bit browser). Loic, what system are you trying reproduce the issue on?
I tried yesterday to make screen-capture work on one of my Win10 PCs with XBox app and with VLC, but had no luck getting either to capture anything. But I continue trying to find a way tonight.

Comment 6

3 years ago
It could be an issue with HiDPI. I'm on Win 7 64bits with resolution at 125%. I'll test with 100% (default).

Comment 7

3 years ago
I tried to rehost the images on Imgur (because Flickr is low to load the heavy image), but no luck.

To record a screencast, you can use the Java online tool https://screencast-o-matic.com/home (if you have Java installed).

Comment 8

3 years ago

Comment 9

3 years ago

Comment 10

3 years ago
Posted file 1267379.html

Comment 12

3 years ago
Video uploaded showing how I see the issue.

Comment 13

3 years ago
The Imgur version behaves different than my own version with Flickr-hosted images. In Imgur version the black flash is only seen once (in first replacement/cycle). Somehow this is logical behavior. In first "cycle" the big image is not cached and you could expect it to only "flicker" in first cycle and then behave nice afterwards. So this is much nicer, and the first "flash" could probably be prevented by pre-caching the big image in a javascript Image object before replacing.

I guess this suggests that Flickr sets some header data preventing caching or full caching of the big image? However I can't forget that it also worked fine even in first cycle in earlier versions of Firefox, and the Imgur-testcase also still works fine in IE11, Edge, Opera and Chrome. No "flicker" in these browsers, not even in first cycle on empty cache...

Comment 14

3 years ago
Is - or was - Firefox supposed to do some intelligent handling of image-replacement via img.src attribut, and not do the actual replacement until the new image is loaded/cached? It looks like this was the behavior of earlier versions of Firefox, and is the current behavior of IE, Edge, Chrome and Opera?

Comment 15

3 years ago
Stig, is it possible to attach another testcase with an HQ picture less heavy (it's almost 6 MB here), because I think it consumes a lot of bandwith from the CDN staticflickr.com
That'w why the tescase stays stuck to the LQ picture because the HQ never loads and I can't really reproduce it with this issue.

Comment 16

3 years ago
(In reply to Loic from comment #15)
> Stig, is it possible to attach another testcase with an HQ picture less heavy

I'll try to find time for it tonight. Otherwise it will be in the weekend. Alternatively we could also change the interval from 3000ms to something bigger (I'm so privileged to be on a 100 Mbit/s connection myself, so haven't given much thought to that part).

Comment 17

3 years ago
I'll try with an interval higher, because on my side, 95% of times, the HQ image never loads and it's really hard to reproduce the black background flashing during the switch. (that's not the case with the images hosted on Imgur which is pretty fast, surely due to different server configuration)

Comment 18

3 years ago

Comment 19

3 years ago
I have attached a slightly modified version of the original attachment. Still same images used, but I have doubled the length of the interval between flipping between the two images. So here I see the first "black flash" 6 seconds after the onload event, and then a black flash every 12th second (when going from low to high-res version of photo).

I also locally on my PC created a "massive downscaled" version of my testcase which only showed the flash in first "cycle". As soon as I get the time, I try to dig into when the issue is triggered and when it's not.

But as a little background, here's the story why this thing "bugs me":

Back in August last year (2015) I created a browser "userscript" to fix a few things annoying me on Flickr. One of the problems with Flickr, was that they in 2012 when they introduced 1600px and 2048px wide "display-versions" of images, only did it for images uploaded in March 2012 and later. So all older stuff was left only to be viewed 1024px wide even on my 24" monitor. Some photographers (myself included) allow access to the original uploads, which can be any arbitrary size. So my userscript takes advantage of this, up-scales the 1024px version of the image to available space in browser-window and then replaces the 1024px wide image with the original image for optimal sharpness and quality. A little bit to my surprise this worked very smooth and well with all three setups I tested with (Firefox+Greasemonkey, Chrome+Tampermonkey and Opera+Violentmonkey), even though I didn't do anything to pre-cache the big/original image before making the image-replacement. Naturally after Firefox started to flash the background from version 44, I tried adding pre-caching to my userscript, but it had no effect. It still showed a flash of the black background in Firefox.

Of course my case might be a little extreme with megabyte big original image-files. But I know it used to work fine. I have also in general noticed more "flickering" of images on the Flickr website lately, but I'm not sure if it is related to this issue.

Comment 20

3 years ago
(In reply to Stig Nygaard from comment #19)
> Naturally after Firefox started to flash the
> background from version 44,

Above should of course say version 45. In version 44 it was still fine.

Comment 21

3 years ago
User Agent 	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:49.0) Gecko/20100101 Firefox/49.0
Build ID 	20160428030218

Confirmed on Firefox 45.0.2, Firefox 46 and latest Nightly.
Ever confirmed: true

Comment 22

3 years ago
Ok, I'm able to reproduce it with IPv6 disabled in my router, I guess CDN staticflickr.com is broken with IPv6. And I updated the interval from 3000 to 7000 ms.

Regression range:

It's another regression from bug 1079627.
Blocks: 1079627
Component: Untriaged → ImageLib
Flags: needinfo?(stig)
Product: Firefox → Core
Version: 45 Branch → 38 Branch

Comment 23

3 years ago
Thanks for taking a look at this. One question though. Comments and the version set to "38 branch" seems to refer to change made to Firefox 38? The problem I see was clearly introduced this year in FF45, does that makes sense?
Though my first guess the issue was caused by upgrading to 64bit Firefox, I later tested on it rarely used and updated 32bit Win XP partition. Here I first did NOT see the problem in an "old" Firefox 44.0.2 I had installed on it, but two minutes later when I had updated Firefox to latest 45.0.2 the problem was also present when running on my XP-partition. I clearly remember having the problem with 45.0.1 on Win10 and I'm pretty sure I also had it with 45.0.0.
This sounds similar to what I discovered in bug 1261442.
Whiteboard: [gfx-noted]

Comment 25

3 years ago
Any workaround is there in code? I also having same kind of issue.
WIP. This solves the flicker by only clearing the previous image if we lift the DOM size constraint in addition to the previous/current images having a different intrinsic size. However even with the patch, I notice that Chrome doesn't flicker without the DOM size constraint (modifying attachment 8746702 [details]), while we still do. There are several properties that would need to change atomically at the right time (mImage, mIntrinsicSize, mIntrinsicRatio, etc) for us to be able to do that and is probably a more complicated fix.

Comment 27

3 years ago
Changing platform and version.
If I change these to wrong values, please explain why. Bug clearly introduced with version 45 and confirmed on multiple Windows versions (and both on 32 and 64bit versions).

I just saw that Bug 1273455 got a fix checked in. I don't understand much of the technical descriptions and talk in it, but still sounds like it maybe could be related to this. Is there any way I can test a build including the checkin from Bug 1273455?
OS: Windows 10 → Windows
Hardware: x86_64 → All
Version: 38 Branch → 45 Branch

Comment 28

3 years ago
Bug has been introduced in FF38, don't change it, please.
Version: 45 Branch → 38 Branch

Comment 29

3 years ago
(In reply to Loic from comment #28)
> Bug has been introduced in FF38, don't change it, please.

But how can you say it was introduced in FF38? My test-case did not show flicker/flashing before version FF45.
It was in August 2015 I created a userscript for Flickr (https://greasyfork.org/en/scripts/12008-stig-s-flickr-fixr) doing pretty much exactly the same thing as I do in my testcase. There was NO flicker/flash of background at that time. From Firefox release history I see I must have been using FF39 or FF40 at that time. There was NO flash/flickering of background at all at that time (a bit to my surprise actually, because I had expected I needed to pre-cache images. Turned out that wasn't necessary, neither in Firefox, Chrome or Opera). And my script continued to work fine without flash/flickering in FF41, FF42, FF43 and F44. But in FF45 things changed. You could argue that my script and testcase are not completely the same, but after creating my testcase I found an old Windows-partition where I was still running FF44 (see comment 23) and there was NO flash/flickering in FF44 when running testcase with that browser-version. But as soon as it was upgraded to 45 testcase started to show the flash/flicker-problem.
Of course there could be a root problem introduced in FF38 that just wasn't visible until some other change was made in FF45, but you could tell so if that is was you think?

Comment 30

3 years ago
I posted the regression range found by using the testcase in comment #22.

Comment 31

3 years ago
(In reply to Loic from comment #30)
> I posted the regression range found by using the testcase in comment #22.

I don't understand what comment #22 is about, what testcase you are referring to or how you concluded a relation to bug 1079627. But does it make sense to have version set to 38 Branch when problem I have reported was not visible until FF45?
I'm not sure if you have somehow hijacked "my bug" and made it into something else not directly related to the problem I see? The problem I reported was not visible until FF45.

Comment 32

3 years ago
Meanwhile, anybody who has looked at Andrew Osmond's checkin (comment 26)? I can't read from his comment if this is expected to fix the issue, but can I download a build somehow with Andrew's checkin and the checkin on Bug 1273455 (which is now marked as Resolved Fixed), to see if these checkins changes something for this issue?
Give a build from https://nightly.mozilla.org/ a try.

Comment 34

3 years ago

(In reply to Stig Nygaard from comment #31)
> (In reply to Loic from comment #30)
> But does it
> make sense to have version set to 38 Branch when problem I have reported was
> not visible until FF45?

I wish someone would at least answer this question with a short Yes or No. A simple Yes would be enough for me to stop wondering.

Comment 35

3 years ago
I reproduced the issue since FF38 so it didn't started from 45.

Comment 36

3 years ago
(In reply to Loic from comment #35)
> I reproduced the issue since FF38 so it didn't started from 45.

Thanks for the explanation. On my browsers/systems it was not visible until FF45, so there must be multiple factors involved here.

Comment 37

3 years ago
I can verify Stig's earlier comments. I can reproduce this issue on Firefox 45 (OS X) or later, but not on 44 or earlier.
We should probably fix the regression from bug 1207355, rather than make nsImageFrame bend over backwards to try to get around this regression.

Comment 40

2 years ago
Yes, this issue applies to multiple versions of firefox, and it is quite annoying.
Very easy to reproduce, just open for instance valamit.com and the flashes are easily visible.
No other browser has this behavior (not even IE/Edge :-)


2 years ago
status-firefox55: --- → wontfix
status-firefox56: --- → affected
status-firefox57: --- → affected
status-firefox-esr52: --- → wontfix


2 years ago
Whiteboard: [gfx-noted] → [gfx-noted][parity-Chrome][parity-Edge]
Too late to fix in 56, seems likely to still affect 58.
status-firefox56: affected → wontfix
status-firefox57: affected → fix-optional
status-firefox58: --- → ?
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Keywords: parity-chrome, parity-edge
Whiteboard: [gfx-noted][parity-Chrome][parity-Edge] → [gfx-noted]
Any news about this issue?
You need to log in before you can comment on or make changes to this bug.