2.27 KB, text/html
269.57 KB, image/jpeg
5.92 MB, image/jpeg
871 bytes, text/html
770 bytes, text/html
3.21 MB, video/mp4
1.88 MB, image/jpeg
2.40 KB, text/html
4.60 KB, patch
|Details | Diff | Splinter Review|
Attachment #8745044 - Attachment description: imagereplace.html → Testcase to demonstrate issue.
Attachment #8745044 - Attachment description: Testcase to demonstrate issue. → Testcase to demonstrate and verify issue.
Setting some keywords - hope I don't do anything wrong with that.
Keywords: regression, reproducible, testcase, verifyme
What do you mean by "flash"? Because I don't see any flash of the background image when loading or refreshing the testcase.
Keywords: reproducible, verifyme
OS: Windows → Windows 10
Hardware: Unspecified → x86_64
(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?
I tried again, I am not able to reproduce the "flash" of the background. Could you attach a screencast, maybe?
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.
It could be an issue with HiDPI. I'm on Win 7 64bits with resolution at 125%. I'll test with 100% (default).
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).
Video uploaded showing how I see the issue.
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?
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.
(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).
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)
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.
(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.
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Component: Untriaged → ImageLib
Product: Firefox → Core
Version: 45 Branch → 38 Branch
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.
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.
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
Bug has been introduced in FF38, don't change it, please.
Version: 45 Branch → 38 Branch
(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?
I posted the regression range found by using the testcase in comment #22.
(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.
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.
(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.
I reproduced the issue since FF38 so it didn't started from 45.
(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.
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.
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
We should probably fix the regression from bug 1207355, rather than make nsImageFrame bend over backwards to try to get around this regression.
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
Priority: -- → P3
status-firefox55: --- → wontfix
status-firefox56: --- → affected
status-firefox57: --- → affected
status-firefox-esr52: --- → wontfix
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.