Open Bug 705826 Opened 13 years ago Updated 2 years ago

Images are flashing when updates by img.src[]=url in Firefox >= 8.0

Categories

(Core :: Graphics: ImageLib, defect)

Product:
Core
Component:
Graphics: ImageLib
Version:
8 Branch
Platform:
x86_64
Windows 7
Type:
defect

Tracking

()

People

(Reporter: tania.joukova, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

Attachments

(5 files)

images for sample application
(deleted), application/octet-stream
Details
First image
(deleted), image/jpeg
Details
Second image
(deleted), image/jpeg
Details
Testcase, relies on loading those images from file://
(deleted), text/html
Details
Large image loading very slowly in FF8
(deleted), image/png
Details
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0.1) Gecko/20100101 Firefox/8.0.1 Build ID: 20111120135848 Steps to reproduce: In my javascript I am updating image.src in setInterval, or on mouse move. For example: function updateImage() { document.images["L2"].src = 'Default.ashx?Ind=' + ind.toString() + '&no-cache' + '=' + Math.random().toString(10); } Actual results: Images are blinking/flashing when updated. it's especially noticeable when images are in grey scale on the black background. In other browsers and Firefox 7 images are updated smoothly so you have the impression that black part of the images remains the same only central area is changing. Starting from Firefox version 8.0 it seems the image area first blinks (turns white) and only then the image is updated. Expected results: Images should be updated smoothly as in version 7.
This isn't security-sensitive. Can you please either point to a complete testcase showing the problem or use http://harthur.github.com/mozregression/ to find when the problem first appears for you? Or both, of course.... ;)
Group: core-security
Component: General → ImageLib
QA Contact: general → imagelib
I am using asp.Net for the test but I think it shouldn't be matter, could be done on java. My Default.aspx <%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs" Inherits="SimpleAspWebApplication._Default" %> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" > <head runat="server"> <title></title> </head> <body id="Page" onload="window.setInterval('vistar();', 200);"> <div id="Conteneur"> <div id="Aff_Images_grd"> <div id="Grp_image"> <img id='L1' alt="" src="http://www.linternaute.com/nature-animaux/magazine/photo/les-100-paysages-de-france/image/etretat-262711.jpg" /> <img id='L2' style="width:800px;height:800px" alt="" src="http://www.linternaute.com/nature-animaux/magazine/photo/les-100-paysages-de-france/image/etretat-262711.jpg" /> </div> </div> </div> </body> <script type="text/javascript"> var ind = 0; function vistar() { if (ind == 0) ind = 1; else ind = 0; document.images["L2"].src = 'Default.ashx?Ind=' + ind.toString() + '&no-cache' + '=' + Math.random().toString(10); text.value = ind.toString(); } </script> </html> My request handler: public class Default : IHttpHandler { private int ind = 0; private string[] data=new string[]{"C:\\Test\\image11.jpg", "C:\\Test\\image22.jpg"}; public void ProcessRequest(HttpContext context) { context.Response.ContentType = "image/jpg"; context.Response.CacheControl = "no-cache"; // Return an jpeg image ind = Int32.Parse(context.Request.Params["Ind"]); string test = data[ind]; context.Response.BinaryWrite(File.ReadAllBytes(test)); }
The actual image data probably matters (because I can't reproduce anything like what you're describing so far using images I have here). Please link to an actual live site showing the problem?
Attached file images for sample application (deleted) —
I've attached images for testing. We don't have live site, our application installed on internal customer's servers.
(In reply to Boris Zbarsky (:bz) from comment #3) > The actual image data probably matters (because I can't reproduce anything > like what you're describing so far using images I have here). Please link > to an actual live site showing the problem? Is it reproducible with attached images?
Yep. Sorry for the lag.... I'll attach a testcase to this bug. I'd assume we're dispatching the notification that makes the image loading content switch to the new request before the decode is done. That's sort of broken.
Attached image First image (deleted) —
Attached image Second image (deleted) —
Over http from Bugzilla the 200ms timeout is too small for me to get the broken effect; the response is just not fast enough. And if I precache the images the flicker disappears...
Status: UNCONFIRMED → NEW
Ever confirmed: true
In my testing with our proprietary code (I cannot post) I pull images from our external device as fast as they can load (binding on the load event callback) - I am displaying monochrome on black background. Since upgrading to 8.0 this is extremely noticible if network load times for images are > 200 ms per image - anything faster than that and you don't see the flash of the black background - anything slower than that and it's very noticible. Same network speeds and different browsers you don't see anything like this at all. It's like the imaging library changed how it renders image data in the browser. Local testing on really fast network loads it is not reproducable.
jcurtis, whatever you're seeing sounds different from this bug. The code in this bug does not wait for load events, for one thing. I'd appreciate you filing a separate bug and using http://harthur.github.com/mozregression/ to find when the problem you see first appears for you, since you can't share the site that shows the problem.
Hi Boris, I am having the same issue. We used to be proud of Firefox to demo our system on, but now it is the slowest of the bunch. The problem seems to be related to image size. The following attachment can cause the issue even when loading from local disk. In the past < FF8 this image used to show in a few milliseconds, now takes many seconds to load. All other browsers are fine
Attached image Large image loading very slowly in FF8 (deleted) —
Large image loading very slowly in FF8
Samir, that's a separate issue from what this bug is about, related to async decoding of images. There are existing bugs on that. Again, this bug is about flicker on dynamic src _changes_.
I'm seeing something similar on the following page: http://localhost:8090/~vouillon/bug2/ Using mozregression, it seems the regression was introduced by the following changeset: changeset: 79230:8b89d7037306 user: Matt Woodrow <mwoodrow@mozilla.com> date: Wed Oct 26 16:24:58 2011 +1300 summary: Bug 695275 - Fix conversion of ThebesLayers to ImageLayers. r=roc Here is a detailed presentation of my issue. When clicking on an image on the page above, a larger version of the image is displayed. To provide a quick feedback, I use a canvas containing a low quality version of the image, and I put above it an img element containing a higher quality image. Previously, this image was loaded progressively over the canvas, in a smooth way (the part not yet loaded was transparent). Now, I get a dark background for a short time when the image starts loading. Then, the canvas becomes visible again, while being progressively replaced by the image.
Jérôme, you're seeing something very different from this bug, I think. In particular, this bug was filed on a build that predates the changeset you mention in comment 16. Could you please file a separate bug on your issue?
Also, we're probably going to need a public URL or testcase; the one you posted is "localhost", which means your local computer, not a server on the Internet.
Boris - I am sorry i haven't been able run mozilla regression until today. And the flickering was introduced on 7/22/11 - the nightly build from 7/21/11 has smooth image transitions - but 7/22/11 clearly introduced erasing of background before redrawing (that is what it seems like) and shows as a black flicker because the background is black. We can't use firefox for our product until this gets addressed. I will go ahead and post another bug.
(In reply to Boris Zbarsky (:bz) from comment #17) > Jérôme, you're seeing something very different from this bug, I think. In > particular, this bug was filed on a build that predates the changeset you > mention in comment 16. > > Could you please file a separate bug on your issue? Indeed, this appears to be a different issue. I have filed a separate bug report (bug 717572).
I also have this issue. Google didn't offer any good solutions and Firefox 13 & Nightly also have this issue. Problem: Need to show low quality image when full quality is still downloading. Solution: I decided to go with specific "css hack" for mozilla only. I used jQuery. Image flicker is still present but it is not visible to human eye because low quality image is in the background. Solution works for my current needs. Maybe someone will find this helpful. $wrapper = jQuery('#wrapper'); $image = $wrapper.find('img'); if(jQuery.browser && jQuery.browser.mozilla) { $wrapper.css({ 'background-color':'#FFF' ,'background-repeat':'no-repeat' ,'background-attachment':'scroll' ,'background-size':'100% 100%' ,'background-position':'center center' }); $image.removeAttr('src'); $wrapper.css('background-image', 'url("'+image_path+'")'); } else { $image.attr('src', image_path); } Html: <div id="wrapper"><img src="somepath.jpg"></div>
Here's some simple code that demonstrates the problem. Create your own, 1.png, 2.png, 3.png, 4.png to complete the example. Create them at 1440 X 900 pixels. You'll see the screen flash when the image source is changed. If you run this same test on IE or Chrome - no flash on update. <!DOCTYPE html/> <html> <head> <title></title> <script type="text/javascript"> var ct = 0; function click() { var im1 = document.getElementById("myimage"); im1.src = "" + (ct + 1) + ".png"; ct = (ct + 1) % 4; } </script> </head> <body> <a href="javascript:click();">click here</a><br /> <img id="myimage" src="" alt=""/> </body> </html>
I am also seeing this bug on Firefox 17 and 18. Setting the src attribute of an <img> sporadically causes the blink whether or not the image is pre-cached. Creating two stacked img's and setting src attributes and swapping visibility after a small delay following the onload trigger seems to work around the issue (though very clumsily). Any progress tracking this down since IE and Chrome do not exhibit the same behavior?
Still seeing this bug in Firefox 33.1.1 (osx 10.9.5). Any plans or progress with fixing?
Flags: needinfo?(seth)
This bug is still present in Firefox 36.0.4 (Windows 8). An update would be appreciated, as we would like to use Firefox as a reference browser to showcase sites in client meetings, but sadly we can't until this is fixed.
What testcase are you using to test? I tried the testcase attached to this bug ("First Image", "Second Image", "Testcase, relies on loading those images from file://") and it looked fine to me on Firefox 36, 37, 38, and 40. For people who are still seeing this bug, what testcase are you using?
In my case it happens on a client website, which I am currently asking permission to provide a link to. I can also reproduce it on the testcase posted in comment #22 though ( http://matti.no-ip.org/bug717323/ferntest.html ). Using Firefox 37.0.1 on Windows 8.1 x64
Alright, we got permission from the client to supply a link to their site. https://www.busch-jaeger.de/en/solutions/ Select any of the indoor or outdoor links, and drag / scroll the scene left to right. There is no flickering on Chrome, IE, Safari (neither on the mobile versions), with Firefox 37.0.2 (Windows 8.1 x64) there is. There is a script on the site that preloads all the images so they are cached, even after waiting for all images to load it happens. Any replies or updates to this report are greatly appreciated.
We experienced the same problem. Ended up working around it by doing our image looping/transitions in a canvas. Firefox seems to handle what looks like same job on a canvas just fine. Which makes this bug even more puzzling to the layman
I can reproduce this. I haven't debugged it at the Gecko level, but it seems pretty clear that we aren't decoding the preloaded images because they aren't visible. Fixing this is nontrivial without severely regressing memory usage. We need more sophisticated heuristics than the ones we currently have, which requires that we track more information about images than we currently are tracking. We should revisit this after bug 1123976. (In reply to Chris.Lauer from comment #31) > We experienced the same problem. Ended up working around it by doing our > image looping/transitions in a canvas. Firefox seems to handle what looks > like same job on a canvas just fine. Yes, the canvas case is quite different, because when you draw an image to a canvas we decode and draw the image synchronously - it's required by the spec. Changing an <img> element's 'src' attribute or changing the 'background-image' property, by contrast, triggers asynchronous decoding. That can result in flashing because we may repaint before the image is fully decoded. Using <canvas> is probably a better choice for this particular use-case. (Either a single <canvas> which you draw the Image's into, or a <canvas> per frame.) A <video> would be even more efficient if it meets your needs.
Depends on: 1123976
Flags: needinfo?(seth)
First of all, thank you for your insights. Secondly I'd just like to note that the test case (the client site) I posted in comment #30 can't be used to reproduce the issue anymore, since we found a (very simple to be honest) workaround and implemented that. I'd have liked to make it into a <canvas>, but time constraints only let me implement the workaround. For those who are interested, the workaround is simply having two more <img>s with the two possible images that may come next, placed behind the actual <img> so they're not visible.
(In reply to F. Rauch from comment #33) > For those who are interested, the workaround is simply having two more > <img>s with the two possible images that may come next, placed behind the > actual <img> so they're not visible. I'd advise others to use the <canvas> approach, which is guaranteed to work by the spec. Decoding heuristics for <img> elements can and will change in the future.
This is still a bad bug today. When using responsive images with lazy loading, the images will flash/flicker when they're being swapped. It happens on both Firefox and Firefox mobile. In IE, Chrome, Chrome Mobile the image transition from old to new is smooth, unlike Firefox.
One more note, I think it has gotten worse in Firefox v45, is that possible? At least it's now that I noticed it.
I only just recently started seeing this problem, and I think started after I had upgraded to the 64 bit version of Firefox (Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:45.0) Gecko/20100101 Firefox/45.0). I see this problem on both my stationary and my on laptop. Both are Firefox 64 bit running on Windows 10. I also have a 32bit Windows XP partition on my stationary, and when booting to WinXP and running 32 bit Firefox on that, the problem is gone.
I have to correct my comment from yesterday. When I yesterday on my Windows XP partition tested the 32-bit version of Firefox, I forgot to update the browser first. When updating my 32 bit Firefox from version 44.0.2 to the latest 45.0.2 I see same problem as in my 64 bit Firefox on Windows 10. So, sorry... No relation to OS or to 32 vs. 64 bit versions of Firefox it seems. The annoying flicker/flashing when replacing an image seems to be introduced in version 45 (or in one of its minor revisions). I see this is a very old bug. Maybe there's another one directly related to this recently (re?)introduced problem? I haven't succeeded finding one, though...
I have created a new bug for the issue I see introduced in FF45, https://bugzilla.mozilla.org/show_bug.cgi?id=1267379 I don't know if the issue I'm describing is related to this bug. I have only seen the problem after upgrading to FF45, and this is a very old bug talking about FF8+ - But by description, issues looks very similar)
is anybody actively working on this? The internet is full of websites with images that are hurt by this bug :(
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 :-)
Any news about it?

I've found a pretty solid work-around for this, which is to basically create a temporary image with the new image URL, wait until decode is done on that temporary image, and only then replace the src of the actual DOM element, like this:

const imgUrl = 'yournewimage.png'; // your new image
const img = new Image(); // create temporary image
img.src = imgUrl; // add your new image as src on the temporary image

img.decode().then(() => { // wait until temporary image is decoded
    document.querySelector('img').src = imgUrl; // replace your actual element now
});

However keep in mind that it made the whole thing lag a lot in Chrome, so I only added this decode() thing for Firefox by checking that navigator.userAgent.toLowerCase().indexOf('firefox') > -1; would be true.

Hope this helps someone!

Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 18 votes.
:aosmond, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(aosmond)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(aosmond)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: