490949 - bmp image served from router fails to reload despite Cache-control: no-cache directive

Status: RESOLVED FIXED

(Core :: Graphics: ImageLib, defect)

Description

[Erik Putrycz]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b4) Gecko/20090423 Firefox/3.0.7, Ant.com Toolbar 1.3 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b4) Gecko/20090423 Firefox/3.0.7, Ant.com Toolbar 1.3 (.NET CLR 3.5.30729)

My D-Link DIR 655 login page has a graphical authentication verification (like captcha). On a wrong password, a javascript displays an error box and calls "location.reload(true);"
However the graphical verification is not refreshed.
I traced on linux the http headers for that graphical verification (which is a bmp image).
Cache-control: no-cache\r\n
Server: Ubicom/1.1\r\n
Content-Length: 9454
Content-Type: image/bmp\r\n

I don't see any particular reason why firefox is not reloading the bmp...
This works perfectly with 3.0 and IE.


Reproducible: Always

Steps to Reproduce:
1. Login to DLink access page
2. Enter a wrong password
3. Click OK
Actual Results:  
Page refreshed but not the captcha

Expected Results:  
new captcha refreshed

Comment 1

[Joe Drew (not getting mail)]

I can't reproduce this, even in 3.0. :( I'm working on a mochitest for this behaviour that I'll upload when it's ready.

Comment 2

[Joe Drew (not getting mail)]

Whoops, spoke too soon. I've got both a working testcase and a fix for the 1.9.1/1.9.2 branch.

Comment 3

[Joe Drew (not getting mail)]

Attachment: Mochitest for Cache-Control: no-cache images

This test loads images with Cache-Control: no-cache, and does a location.reload(true) and location.reload(false) to make sure we always reload the image from the network when Cache-Control: no-cache is specified, even if we don't do a force-reload.

Comment 4

[Joe Drew (not getting mail)]

Attachment: Take into account the load group's load flags when checking the cache

The image loading routines check if we're loading while bypassing the cache, but unfortunately that only handled the flags we pass in directly to imgLoader::LoadImage(), not those passed in indirectly via the load group. This made for a weird mismatch between LoadImage, which directly used aLoadFlags, and the methods it called, which used the harmonized load flags stored in requestFlags.

Luckily, this only affected loads that were to bypass the cache.

This problem also exists in 3.0/1.9.0, but I don't think it's necessary to fix there. Fixing for 3.5 should be enough, though we obviously shouldn't block.

Comment 5

[Erik Putrycz]

Strangely enough, this issue doesn't happen with Firefox 3.0 - for some reason location.reload(true) works and reloads the bmp. I wouldn't bother fixing it for 3.0.

Comment 6

[Joe Drew (not getting mail)]

Checked in to mozilla-central:

http://hg.mozilla.org/mozilla-central/rev/bd22fde8a8a4
http://hg.mozilla.org/mozilla-central/rev/b6a74601ee1d

If there are no problem with this, I'll ask for approval for 1.9.1.

Comment 7

[Joe Drew (not getting mail)]

Pushed http://hg.mozilla.org/mozilla-central/rev/d5cc0631c2bd as a bustage fix.

Comment 8

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 376061 [details] [diff] [review]
Take into account the load group's load flags when checking the cache

a191=beltzner

Comment 9

[Joe Drew (not getting mail)]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/2af3e11314df

Comment 10

[Aakash Desai [:aakashd]]

The mochitest for this bug hasn't been pushed to 1.9.1. Is there a reason why?