Closed Bug 110077 Opened 24 years ago Closed 14 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: 14 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: