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

NEW
Unassigned

Status

()

Core
ImageLib
7 years ago
12 days ago

People

(Reporter: TJ, Unassigned)

Tracking

(Depends on: 1 bug)

8 Branch
x86_64
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments)

(Reporter)

Description

7 years ago
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
(Reporter)

Comment 2

7 years ago
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?
(Reporter)

Comment 4

7 years ago
Created attachment 577332 [details]
images for sample application
(Reporter)

Comment 5

7 years ago
I've attached images for testing. We don't have live site, our application installed on internal customer's servers.
(Reporter)

Comment 6

7 years ago
(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.
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...
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 11

7 years ago
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.

Comment 13

7 years ago
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

7 years ago
Created attachment 580210 [details]
Large image loading very slowly in FF8

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_.

Comment 16

7 years ago
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.

Comment 19

7 years ago
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

7 years ago
(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).
Duplicate of this bug: 717323

Comment 23

6 years ago
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

6 years ago
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

5 years ago
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

4 years ago
Still seeing this bug in Firefox 33.1.1 (osx 10.9.5). Any plans or progress with fixing?
Flags: needinfo?(seth)

Comment 27

3 years ago
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?

Comment 29

3 years ago
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

3 years ago
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

3 years ago
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)

Comment 33

3 years ago
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.

Comment 35

2 years ago
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

2 years ago
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

2 years ago
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

2 years ago
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

2 years ago
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

2 years ago
is anybody actively working on this? 
The internet is full of websites with images that are hurt by this bug :(

Comment 41

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 :-)
Any news about it?
You need to log in before you can comment on or make changes to this bug.