Open Bug 1132800 Opened 9 years ago Updated 2 years ago

firefox displays stale background image on page refresh

Categories

(Core :: Graphics: ImageLib, defect)

Product:
Core
Component:
Graphics: ImageLib
Version:
38 Branch
Platform:
x86_64
Linux
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: c.heller, Unassigned)

References

Details

(Whiteboard: gfx-noted) 

An image that should change on page reload doesn't if included via "background-image:url()". Steps to reproduce the problem (tested with, quoting my user-agent header, "Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0", latest Nightly build):

1. From any web server, serve any image file called "test.png", and a HTML file "test.html" that contains this code refering to it:

<html>
<body style="background-image:url('test.png')">
</bod>
</html>

2. Load test.html in Firefox. It should show the test.png image.

3. On the server, replace test.png with another image file of the same name.

4. In Firefox, reload test.html from the server. (When I do this, the image remains the same.)

5. Reload test.html once more. (When I do this, the image now changes.)

I can only reproduce the problem when including the image via "background-image:url()". When I instead include it via, for example, "<img src='' />", no problem occurs. (I may include it in both ways at once. The result is that, in step 4, the old *and* the new version of the image is shown in the browser window.)

I assume it's not a server problem, since the problem appears with all the different ones I tested (Apache, Python's SimpleHTTPServer, NodeJS). Using Firefox' Network Monitor, I checked what happened during the different stages. (Header logs for test.png as gathered with Network Monitor below – everything seems to be in order with them.) On step 4, the new image actually seems to be loaded, even if not displayed in the browser window: The file icon shown by Network Monitor is a tiny version of the new one I expect (the big version of which I only get to see on stage 5).

Bug 734062 seems similar, but its status is "RESOLVED FIXED", and I can't reproduce its specifics (not without using "background-image:url()" anyway).

Header log step 2:

Request:
Host: localhost:8000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://localhost:8000/test.html
Connection: keep-alive

Response:
Content-Length: 33296
Content-Type: image/png
Date: Fri, 13 Feb 2015 05:03:42 GMT
Last-Modified: Fri, 13 Feb 2015 05:01:06 GMT
Server: SimpleHTTP/0.6 Python/2.7.3

Header log step 4:

Request:
Host: localhost:8000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://localhost:8000/test.html
Connection: keep-alive
If-Modified-Since: Fri, 13 Feb 2015 05:01:06 GMT
Cache-Control: max-age=0

Response:
Content-Length: 11397
Content-Type: image/png
Date: Fri, 13 Feb 2015 05:04:32 GMT
Last-Modified: Fri, 13 Feb 2015 05:04:27 GMT
Server: SimpleHTTP/0.6 Python/2.7.3

Header log step 5:

Request:
Host: localhost:8000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://localhost:8000/test.html
Connection: keep-alive
If-Modified-Since: Fri, 13 Feb 2015 05:04:27 GMT
Cache-Control: max-age=0

Response:
Content-Length: 11397
Content-Type: image/png
Date: Fri, 13 Feb 2015 05:05:01 GMT
Last-Modified: Fri, 13 Feb 2015 05:04:27 GMT
Server: SimpleHTTP/0.6 Python/2.7.3
(Just noticed a typo in my own example code, namely the "</bod>" that should be "</body>". The same effect happens without the typo.)
Component: General → ImageLib
Depends on: 734062
Product: Firefox → Core
Version: Firefox 38 → 38 Branch
Milan,

Is Seth the imagelib person? This feels like a caching issue, more than graphics.
Flags: needinfo?(milan)
Whiteboard: gfx-noted
Christian, does the same thing happen if you do "Shift" reload, instead of reload in step 4?
Flags: needinfo?(milan) → needinfo?(c.heller)
Milan: No. When I add pressing "Shift", the image changes instantly.
Flags: needinfo?(c.heller)
I think this is bug 1063369. In a couple of hours a try build will appear at https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/tnikkel@gmail.com-2161fae57027/ can you download it and test it to see if it has this bug? If not, then my guess will be confirmed.
Flags: needinfo?(c.heller)
Testing the above procedure with https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/tnikkel@gmail.com-2161fae57027/try-linux64/firefox-38.0a1.en-US.linux-x86_64.tar.bz2 currently leads to partly bizarre results on my system (Debian GNU/Linux Wheezy). Once started, the browser seems to behave in only one of two ways until closed, and I can't tell whether this choice depends on anything (it feels random). The first of these two ways is the buggy behavior described in my initial post, without changes – so this seems to rule out your guess.

The second one I can't reproduce reliably due to not knowing how to initiate it, so this description has to be taken with a grain of salt; the whole thing feels like specific strangenesses of my own system. On step #4, no test.png is shown at all initially, neither the old or the new: just whiteness. Not even reloading (step #5) changes this. What does change it, however, is changing the Firefox window size, or making the window disappear and reappear in some way on my window manager (i3): The new test.png as expected does appear then, no matter whether it's the first reload (step #4), or a subsequent one.
Flags: needinfo?(c.heller)
Oops, made a mistake, just found out the source of my confusion: Only the second behavior fits the proposed binary, I accidentally used an older one to trigger the first. So this does *not* rule out your guess.
Some additions to the behavior of the proper binary: The failure to display the image described by me in Comment #5 does not seem to depend on the procedure I described in my initial post. The file I use as the second test.png from step #3 on fails to display even when used from the beginning in step #1/#2 (until I do that window resizing / temporary window disappearing described).

I guess this is some problem with my own system / my window manager, or at least a different bug. I can make the new picture appear after step #4 by just doing the described window manager activity, no need for reload. I *cannot* make it appear in this way by using the Nightly build from my first post. So this seems to actually confirm your guess.
Severity: minor → S4
You need to log in before you can comment on or make changes to this bug.