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

Status: RESOLVED WORKSFORME

(Core :: Graphics: ImageLib, defect, P3)

Description

[Stig Nygaard]

Attachment: Testcase to demonstrate and verify issue.

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.

Comment 1

[Stig Nygaard]

Setting some keywords - hope I don't do anything wrong with that.

Comment 2

[Loic]

What do you mean by "flash"? Because I don't see any flash of the background image when loading or refreshing the testcase.

Comment 3

[Stig Nygaard]

(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?

Comment 4

[Loic]

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

Comment 5

[Stig Nygaard]

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

[Loic]

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

[Loic]

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

[Loic]

Attachment: 161149710_bebaccd3f4_b.jpg

Comment 9

[Loic]

Attachment: 161149710_bebaccd3f4_o.jpg

Comment 10

[Loic]

Attachment: 1267379.html

Comment 11

[Loic]

Attachment: 1267379.html (with images hosted on Imgur)

Comment 12

[Stig Nygaard]

Attachment: Video showing issue as I see it

Video uploaded showing how I see the issue.

Comment 13

[Stig Nygaard]

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

[Stig Nygaard]

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

[Loic]

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

[Stig Nygaard]

(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

[Loic]

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

[Loic]

Attachment: 161149710_bebaccd3f4_o1.jpg

Comment 19

[Stig Nygaard]

Attachment: Testcase to demonstrate and verify issue - longer interval version.

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

[Stig Nygaard]

(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

[Liviu Cirdei]

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.

Comment 22

[Loic]

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:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=cac6192956ab&tochange=369a8f14ccf8

It's another regression from bug 1079627.

Comment 23

[Stig Nygaard]

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.

Comment 24

[Josh Matthews [:jdm]]

This sounds similar to what I discovered in bug 1261442.

Comment 25

[pramuck]

Any workaround is there in code? I also having same kind of issue.

Comment 26

[Andrew Osmond [:aosmond] (he/him)]

Attachment: Retain stale image with new src and intrinsic size if constrained by DOM, v1

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

[Stig Nygaard]

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?

Comment 28

[Loic]

Bug has been introduced in FF38, don't change it, please.

Comment 29

[Stig Nygaard]

(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

[Loic]

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

Comment 31

[Stig Nygaard]

(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

[Stig Nygaard]

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?

Comment 33

[Josh Matthews [:jdm]]

Give a build from https://nightly.mozilla.org/ a try.

Comment 34

[Stig Nygaard]

(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

[Loic]

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

Comment 36

[Stig Nygaard]

(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

[Andrew Ortwein]

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.

Comment 38

[Timothy Nikkel (:tnikkel)]

I also get this as a regression from 45. There could be more than one issue here. Regression range:

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=99a4fb4ba5c1ee96ac745c6ad11894bf0537f73a&tochange=2e19045ba652ca2a5a5fc0e20d6f95293acfa32d

regression from bug 1207355

Comment 39

[Timothy Nikkel (:tnikkel)]

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

[gugurete]

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 :-)

Comment 41

[Liz Henry (:lizzard)]

Too late to fix in 56, seems likely to still affect 58.

Comment 42

[Jonathan Watt [:jwatt]]

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)

Comment 43

[Kacper Michajłow [:kasper93]]

Any news about this issue?

Comment 44

[Stig Nygaard]

I'm just noticing that this is finally fixed in my Firefox 68.0beta1 Developer Edition.

Not yet fixed in Firefox 66. Is it fixed in upcoming version 67? I don't think so, but I could have missed it in previous Developer Edition. I know in a few days when my primary browser updates to version 67...

Comment 45

[Stig Nygaard]

Tested on two PCs today with Ff67 and Ff68DevEd.

PC-A: "Wintel" with NVIDIA GeForce GTX 1070 Ti.
PC-B: "Wintel" with NVIDIA GeForce GTX 960.

On PC-A I tried both with WebRender enabled and disabled in Ff67 via setting gfx.webrender.all, but that didn't do any difference. Results was consistent for the two PCs and browsers:

Still not fixed in Firefox 67
But finally fixed with Firefox 68 Developer Edition

I am the bug reporter, but don't know the procedures. Should I change status of this bug now or something?

Thanks to whoever fixed this :-)

Comment 46

[Stig Nygaard]

See previous comment

Comment 47

[Stig Nygaard]

Just a last confirmation that issue has indeed been fixed with the final release-version of Firefox 68.
The glimpse of the background in testcase (and in my "real world use") is now gone from all my three systems:

1. PC Intel i7-8700/Nvidia GeForce GTX 1070 Ti/Win10 Pro
2. PC Intel i7-2600/Nvidia GeForce GTX 960/Win10 Pro
3. Laptop Intel 5Y10/Intel HD Graphics 5300/Win10 Home
   Thanks.