Last Comment Bug 705826 - Images are flashing when updates by img.src[]=url in Firefox >= 8.0
: Images are flashing when updates by img.src[]=url in Firefox >= 8.0
Status: NEW
:
Product: Core
Classification: Components
Component: ImageLib (show other bugs)
: 8 Branch
: x86_64 Windows 7
-- normal with 17 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Andrew Osmond [:aosmond]
Mentors:
: 717323 (view as bug list)
Depends on: 1123976
Blocks:
  Show dependency treegraph
 
Reported: 2011-11-28 12:05 PST by TJ
Modified: 2018-07-09 10:03 PDT (History)
32 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
images for sample application (153.05 KB, application/octet-stream)
2011-11-28 12:47 PST, TJ
no flags Details
First image (101.67 KB, image/jpeg)
2011-12-01 14:28 PST, Boris Zbarsky [:bzbarsky, bz on IRC]
no flags Details
Second image (100.15 KB, image/jpeg)
2011-12-01 14:33 PST, Boris Zbarsky [:bzbarsky, bz on IRC]
no flags Details
Testcase, relies on loading those images from file:// (642 bytes, text/html)
2011-12-01 14:44 PST, Boris Zbarsky [:bzbarsky, bz on IRC]
no flags Details
Large image loading very slowly in FF8 (643.24 KB, image/png)
2011-12-08 15:19 PST, Samir
no flags Details

Description User image TJ 2011-11-28 12:05:34 PST
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.
Comment 1 User image Boris Zbarsky [:bzbarsky, bz on IRC] 2011-11-28 12:10:45 PST
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.... ;)
Comment 2 User image TJ 2011-11-28 12:36:23 PST
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));
    
        }
Comment 3 User image Boris Zbarsky [:bzbarsky, bz on IRC] 2011-11-28 12:39:12 PST
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?
Comment 4 User image TJ 2011-11-28 12:47:44 PST
Created attachment 577332 [details]
images for sample application
Comment 5 User image TJ 2011-11-28 12:50:32 PST
I've attached images for testing. We don't have live site, our application installed on internal customer's servers.
Comment 6 User image TJ 2011-11-29 08:09:57 PST
(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?
Comment 7 User image Boris Zbarsky [:bzbarsky, bz on IRC] 2011-12-01 14:27:58 PST
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.
Comment 8 User image Boris Zbarsky [:bzbarsky, bz on IRC] 2011-12-01 14:28:31 PST
Created attachment 578395 [details]
First image
Comment 9 User image Boris Zbarsky [:bzbarsky, bz on IRC] 2011-12-01 14:33:34 PST
Created attachment 578397 [details]
Second image
Comment 10 User image Boris Zbarsky [:bzbarsky, bz on IRC] 2011-12-01 14:44:44 PST
Created attachment 578407 [details]
Testcase, relies on loading those images from file://

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...
Comment 11 User image jcurtis 2011-12-06 13:49:53 PST
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.
Comment 12 User image Boris Zbarsky [:bzbarsky, bz on IRC] 2011-12-06 13:53:21 PST
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.
Comment 13 User image Samir 2011-12-08 15:18:40 PST
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
Comment 14 User image Samir 2011-12-08 15:19:29 PST
Created attachment 580210 [details]
Large image loading very slowly in FF8

Large image loading very slowly in FF8
Comment 15 User image Boris Zbarsky [:bzbarsky, bz on IRC] 2011-12-08 15:22:44 PST
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_.
Comment 16 User image Jérôme Vouillon 2012-01-10 08:01:39 PST
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.
Comment 17 User image Boris Zbarsky [:bzbarsky, bz on IRC] 2012-01-10 08:33:33 PST
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?
Comment 18 User image Joe Drew (not getting mail) 2012-01-10 15:41:12 PST
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.
Comment 19 User image jcurtis 2012-01-11 11:04:12 PST
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.
Comment 20 User image Jérôme Vouillon 2012-01-12 10:45:33 PST
(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).
Comment 21 User image Matthias Versen [:Matti] 2012-01-12 11:01:16 PST
*** Bug 717323 has been marked as a duplicate of this bug. ***
Comment 22 User image Matthias Versen [:Matti] 2012-01-12 14:09:09 PST
Here is a testcase from bug 717323
http://matti.no-ip.org/bug717323/ferntest.html
Comment 23 User image phobos 2012-07-18 00:25:05 PDT
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>
Comment 24 User image Eddie Wyatt 2012-12-05 11:38:10 PST
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>
Comment 25 User image Eric 2013-04-10 09:20:54 PDT
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?
Comment 26 User image u524665 2014-11-25 06:08:58 PST
Still seeing this bug in Firefox 33.1.1 (osx 10.9.5). Any plans or progress with fixing?
Comment 27 User image F. Rauch 2015-04-02 03:16:34 PDT
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.
Comment 28 User image Timothy Nikkel (:tnikkel) 2015-04-06 01:54:37 PDT
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?
Comment 29 User image F. Rauch 2015-04-17 07:09:09 PDT
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
Comment 30 User image F. Rauch 2015-04-24 00:59:29 PDT
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.
Comment 31 User image Chris.Lauer 2015-04-24 06:42:22 PDT
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
Comment 32 User image Seth Fowler [:seth] [:s2h] 2015-04-24 13:10:37 PDT
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.
Comment 33 User image F. Rauch 2015-05-07 01:20:39 PDT
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.
Comment 34 User image Seth Fowler [:seth] [:s2h] 2015-05-07 10:07:06 PDT
(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.
Comment 35 User image enm 2016-03-22 10:28:14 PDT
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.
Comment 36 User image enm 2016-03-22 10:30:20 PDT
One more note, I think it has gotten worse in Firefox v45, is that possible? At least it's now that I noticed it.
Comment 37 User image Stig Nygaard 2016-04-16 00:08:39 PDT
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.
Comment 38 User image Stig Nygaard 2016-04-17 09:42:29 PDT
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...
Comment 39 User image Stig Nygaard 2016-04-26 00:31:04 PDT
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)
Comment 40 User image yair even or 2016-10-24 15:33:50 PDT
is anybody actively working on this? 
The internet is full of websites with images that are hurt by this bug :(
Comment 41 User image gugurete 2017-01-16 02:37:03 PST
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 42 User image Kacper Michajłow [:kasper93] 2018-07-06 14:34:30 PDT
Any news about it?

Note You need to log in before you can comment on or make changes to this bug.