multilayered windows icons (*.ico) dont disply in highest possible quality

RESOLVED FIXED in mozilla1.1alpha

Status

RESOLVED FIXED
17 years ago
10 years ago

People

(Reporter: subotnik, Assigned: hyatt)

Tracking

(Blocks: 1 bug)

Trunk
mozilla1.1alpha

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

17 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.5+) Gecko/20011109
BuildID:    20011112

A windows icon file may have several layers with different resolutions. Mozilla
does not choose the best available in a file but the worst.

Reproducible: Always
Steps to Reproduce:
1. go to <http://michael.nahrath.de/dnet/> or view the .ico file directly:
<http://michael.nahrath.de/dnet/img/favicon.ico>

Actual Results:  The 1-bit version of the icon is displayed in the URL bar and
in the tabs

Expected Results:  It should use the highest possible quality. If the icon file
is displayed directly in the browser window the bigger version (32x32) should be
used. 

I built this icon with the Mac tool 'Icon Builder Pro' but checked it on 
Windows-Systems. In IE the highest resolution and different sizes work.

Maybe I should rather have reopened bug 18502 for this but unfortunately this
bug is already bloated with advocacy.
(Reporter)

Comment 1

17 years ago
Created attachment 57580 [details]
Screenshot with all resolutions of the test .ico file

In the attached screenshot you may see what the different layers of
<http://michael.nahrath.de/dnet/img/favicon.ico> should look like.
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: sairuh → claudius
*** Bug 112242 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

17 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.1

Updated

17 years ago
Blocks: 120352
not the worst layer is chosen, but the first one of the size 16x16. if such one
does not exist, the last existant layer is used.
Created attachment 82903 [details] [diff] [review]
suggested patch

note that still only the 16x16 version is displayed. however, there's no way
for the decoder to know if the icon is for a favicon or the browser window.

of course I could always use the largest version, but I'm not sure if that
would look good in the urlbar/tab bar
hyatt or pavlov, could one of you review this patch? thanks!

Comment 6

17 years ago
Comment on attachment 82903 [details] [diff] [review]
suggested patch

r=pavlov
Attachment #82903 - Flags: review+

Comment 7

17 years ago
Comment on attachment 82903 [details] [diff] [review]
suggested patch

Please split the "if ((e.Width..." line.
sr=tor
Attachment #82903 - Flags: superreview+
checked in
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
*** Bug 109214 has been marked as a duplicate of this bug. ***
*** Bug 187322 has been marked as a duplicate of this bug. ***
Created attachment 159352 [details]
favicon from url field

unfortunately I'm not sure that this is the icon that triggered this bug
(Reporter)

Comment 12

14 years ago
Christian, it is the icon I opened the bug with.

For me it was solved by the patch, at least for the use in the URI-bar.

Doublecheck the Icon with other browsers! Safari still has the same bug.
ah, thank you!

I do not have safari available, unfortunately.
Product: Core → Mozilla Application Suite

Updated

10 years ago
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.