304574 - CGI/dynamically-generated images are loaded twice when generating preview for URL bar favicon

Status: RESOLVED FIXED

(Firefox :: Tabbed Browser, defect)

Description

[Gordon Tran]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050813 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050813 Firefox/1.0+

Firefox appears to re-request a dynamically-generated image to render the
preview favicon in the URL bar if the tab bar is present. While the tab's
preview favicon matches the content, an additional request is made to generate
the preview in the URL bar, the result of which will not necessarily match the
content being viewed.

Reproducible: Always

Steps to Reproduce:
1. Start Firefox with only one start page (no extra tabs, as in a fresh profile)
2. Visit http://unbuffered.info/count.php and reload a few times. Note that the
counter increments only once per reload and that the URL bar's icon matches the
content.
3. Create a new tab to get the tab bar to appear.
4. Switch back to the first tab and reload a few times. Note that the URL bar no
longer matches the content or the tab's preview icon, and that the counter is
now increments by 2 after each reload.

Actual Results:  
Preview in URL bar is not of the same image as the one displayed, server
receives two requests.

Expected Results:  
URL bar preview icon should match the tab's preview icon, without generating an
extra request.

The PHP script records a separate count per IP.
To reset to zero, use: http://unbuffered.info/count.php?reset
To get the current value without incrementing the counter, use:
http://unbuffered.info/count.php?noinc

Comment 1

[Dave Townsend [:mossop]]

Confirming on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1)
Gecko/20050813 Firefox/1.0+ ID:2005081307

Watching a http trace shows firefox sending two requests on every reload. The
image is set to not be cached.

Interestingly if you open the page in a background tab the image is only
requested once, then the url bar icon is correct when you switch to the tab with
no extra request.

Comment 2

[Stéphane Nicaise]

Attachment: Similar bug with html <img> tag

This little php file reproduces the same bug with the html <img> tag.

when using <img src=""> as a temporary source for an image in website
development, the page is loaded twice (as the counter shows), which is
particularly annoying when using session variable increments.

Comment 3

[Peter van der Woude [:Peter6]]

What do IE and Opera ?

Comment 4

[Asa Dotzler [:asa]]

not going to block on something this minor this late in the game.

Comment 5

[Dave Townsend [:mossop]]

*** Bug 325751 has been marked as a duplicate of this bug. ***

Comment 6

[Sachin]

*** Bug 327216 has been marked as a duplicate of this bug. ***

Comment 7

[Philip Withnall (unavailable)]

*** Bug 331126 has been marked as a duplicate of this bug. ***

Comment 8

[Phil Ringnalda (:philor)]

*** Bug 342353 has been marked as a duplicate of this bug. ***

Comment 9

[[e-mail]]

Odd, since I thought that was what validate="never" was for...

Comment 10

[Uriah Narmed]

Could the approach proposed in bug 305986 address this problem (drawing the image to canvas and resizing there to generate a favicon)?

Comment 11

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

(In reply to comment #9)
> Odd, since I thought that was what validate="never" was for...

http://lxr.mozilla.org/seamonkey/source/browser/base/content/browser.xul#229

Firefox doesn't set validate="never".  SeaMonkey does:
http://lxr.mozilla.org/seamonkey/source/xpfe/browser/resources/content/navigator.xul#200

Looks like hyatt broke toolkit in 2002: http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/browser/base/content&command=DIFF_FRAMESET&file=browser.xul&rev2=1.90&rev1=1.89

Comment 12

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Attachment: likely patch, restore validate="never"

I don't build or use Firefox, so I can't easily test this.

Comment 13

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

I doubt this is fallout from bug 125998.

Comment 14

[Phil Ringnalda (:philor)]

*** Bug 338533 has been marked as a duplicate of this bug. ***

Comment 15

[Phil Ringnalda (:philor)]

*** Bug 338176 has been marked as a duplicate of this bug. ***

Comment 16

[Tuukka Tolvanen (sp3000)]

*** Bug 345431 has been marked as a duplicate of this bug. ***

Comment 17

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Fixed on trunk.

Comment 18

[Mike Connor [:mconnor]]

Comment on attachment 226741 [details] [diff] [review]
likely patch, restore validate="never"

a=mconnor on behalf of drivers for 1.8 branch checkin

Comment 19

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Fixed on branch

Comment 20

[Rodney]

Testing in 1.5 and 1.5.01, I've found this fixed when I add a Last-Modified header to the response that was earlier than client time. That is, difference in server and client clock causing last-modified to be a few seconds in the future also got double loading.
--rrb

Comment 21

[[e-mail]]

(In reply to comment #20)
>Testing in 1.5 and 1.5.01, I've found this fixed when I add a Last-Modified
>header to the response that was earlier than client time. That is, difference
>in server and client clock causing last-modified to be a few seconds in the
>future also got double loading.
I always thought you're supposed to use a Date header to avoid that time issue.

Comment 22

[Adam Guthrie]

*** Bug 353047 has been marked as a duplicate of this bug. ***