Closed Bug 110077 Opened 23 years ago Closed 13 years ago

Empty or invalid favicon.ico

Categories

(Core :: Graphics: ImageLib, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME
mozilla1.2alpha

People

(Reporter: logan+mozilla-bmo, Unassigned)

References

(Blocks 1 open bug, )

Details

Attachments

(1 file, 1 obsolete file)

Empty or invalid favicon.ico caused no icon to be displayed in the location bar.

I had just grabbed latest nightly and loaded it up. Went to a few sites, and
noticed that CNN had it's own icon. So I just continued working and hit a web
server at work with an empty favicon.ico in /, no idea why it was there, but
regardless...

Then created an empty file on my machine (url above), and again mozilla
displayed nothingness.

I can't seem to reproduce the error anymore. :/ A regular icon appears, but I
thought I'd submit anyway.
hyatt
Assignee: asa → hyatt
Status: UNCONFIRMED → NEW
Ever confirmed: true
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.1
I can't reproduce a missing icon with the given url. There are a few 
cases though where it does drop out. I'll note that one quirk for 
http://beer.dct.com/ is that a request for http://beer.dct.com/favicon.ico
returns a '301 Moved Permanently' with 'Location: http://beer.dct.com', which
results in a '200 OK' with the contents of http://beer.dct.com/
According to the MS specs, it suggests to create a zero-length favicon.ico, if
you want to stop having 404s show up on your web logs.  Is this related, and
should we  change the behavior to display the generic bookmark icon if it's 0 bytes?
Blocks: 120352
This sounds like either a WFM or a dup of bug 109959 or bug 109112. Can anybody
still reproduce this bug? I can't.

A clean reproduction (that is not a dup of 109959) should probably involve
1) Clean all caches
2) Go to some URL and see no favicon

Anobody know a URL that acts like that?
Alexsey, no, it's not. This bug is that no icon is displayed if the favicon is
an invalid icon.
This seems to be a dupe of bug #115357, which has a suggested patch....
Matthew, I don't think so. That bug is for a specific kind of invalid icons.
This is for the general case.
taking, I have an idea that might work
Assignee: hyatt → cbiesinger
Status: ASSIGNED → NEW
Setting Target Milestone, Platform/OS All, and accepting
OS: Linux → All
Hardware: PC → All
Target Milestone: mozilla1.1 → mozilla0.9.9
really accepting this time
Status: NEW → ASSIGNED
Attached patch Suggested Patch (obsolete) — Splinter Review
This should fix it
actually, the two comment lines in nsICODecoder::Flush (// Set Data here...)
should also be removed, they don't really apply here anymore. They data needs to
be set after the initializations.
Attached patch Working patchSplinter Review
OK, this patch does not prevent any icon from showing up.
Attachment #65779 - Attachment is obsolete: true
Comment on attachment 65828 [details] [diff] [review]
Working patch

no, this doesn't work either
Attachment #65828 - Flags: needs-work+
Component: Browser-General → ImageLib
QA Contact: doronr → tpreston
Back to hyatt. There must be some XUL magic going on that I don't understand...
Assignee: cbiesinger → hyatt
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.9 → mozilla1.2
In case you're not aware of this, many servers present favicon.ico as
Content-Type: text/plain
instead of
Content-Type: image/x-icon 
Just mentioning this in case it's related.

Also, Phoenix 0.5 (Win98) differs from IE6 in one way:
If you go directly to the URL of a text/plain favicon.ico, you will see the text
instead of the image:
http://www.weather.gov/favicon.ico
http://www.timeanddate.com/favicon.ico
http://www.humanclock.com/favicon.ico 
http://nytimes.com/favicon.ico 

If you're keeping score, these are image/x-icon:
http://www.yahoo.com/favicon.ico
http://www.washingtonpost.com/favicon.ico
http://www.latimes.com/favicon.ico
http://news.google.com/favicon.ico

I don't see a <link ...> override in any of these examples.

Apache has relented and included image/x-icon as default for *.ico in ver 2.*:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10993 
QA Contact: tpreston → imagelib
Assignee: hyatt → nobody
This is a mass change. Every comment has "assigned-to-new" in it.

I didn't look through the bugs, so I'm sorry if I change a bug which shouldn't be changed. But I guess these bugs are just bugs that were once assigned and people forgot to change the Status back when unassigning.
Status: ASSIGNED → NEW
Nine years on and 6.5 to 9.5 versions, and a new name later, test case fails to reproduce.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Resolution: FIXED → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: