854956 - (hidpi-favicon-ui) [meta] Use higher-res favicons in the Firefox UI

Status: NEW

(Firefox :: General, defect)

Description

[Jonathan Kew (:jfkthame)]

In bug 828508, we're adding support for higher-resolution favicons in the tabbrowser UI when running on hi-dpi display (Retina Mac, or Windows with >96dpi resolution setting.) This applies to the tab titles, and to the All Tabs menu. This is done using the new -moz-resolution media fragment identifier from bug 419588.

However, the favicons shown in bookmarks and in awesomebar results are still low-res. It's not immediately obvious to me where this should be fixed, but I'm filing this as a Places bug as these elements are all based on the Places data, AIUI.

Comment 1

[Marco Bonardo [:mak]]

bug 492172 and bug 768703 and bug 391589 and probably others.
The short answer is that when we store icons we store them in the DB, and they get scaled down to 16x16 for size concerns. We are not against changing this though.
Also a bunch of style hardcodes 16px around, so that will need to change as well.

Comment 2

[Jonathan Kew (:jfkthame)]

Attachment: comparison of favicons in tab titles and bookmarks

This screenshot shows the contrast between hidpi favicons (in the tab titles) and lodpi ones (in the bookmarks) on a Retina Mac, following the landing of bug 828508.

With expanding hidpi support (this will impact increasing numbers of Windows users, as well as Retina Mac users), I think it's becoming pretty important that we address this. The blurry bookmark icons are one of the most glaring problems on hidpi Windows systems.

Comment 3

[Jonathan Kew (:jfkthame)]

Bug 492172 certainly looks relevant here.

Note that bug 768703 ("Use 32x32 favicons in location bar results") is a different issue: it's about redesigning the UI to present bigger favicons, whereas the issue here is about using larger images (i.e. with more pixels) in order to display a higher-res image at the -current- size.

Comment 4

[Marco Bonardo [:mak]]

I agree, we should give more priority to designing a good storage for larger icons in Places.

Comment 5

[Frank Yan (:fryn)]

I think this depends on bug 798223, but I'm not certain.

Setting PREFICONSIZE to 32 in nsICODecoder enables higher-res favicons in the  bookmarks button menu and awesomebar results, but not in the menu bar bookmarks menu.

Comment 6

[Jonathan Kew (:jfkthame)]

(In reply to Frank Yan (:fryn) from comment #5)
> Setting PREFICONSIZE to 32 in nsICODecoder enables higher-res favicons in
> the  bookmarks button menu and awesomebar results, but not in the menu bar
> bookmarks menu.

Really? That doesn't seem to work for me in a local build - I'm still only seeing lo-dpi favicons in those places.

Comment 7

[Greg Edwards]

I think a more sustainable approach to dealing with icon sizes/DPI scaling would be to automatically append a media fragment to icons when used as images/backgrounds, such that:

<img src="myIcon.ico" width="16" height="16" />

becomes equivalent to

<img src="myIcon.ico#-moz-resolution=16,16" width="16" height="16" />

at 1x scale, but

<img src="myIcon.ico#-moz-resolution=32,32" width="16" height="16" />

at 2x, so that the resolution fragment is scaled to match the pixel ratio/zoom. So if no resolution fragment is used, treat it as #-moz-resolution=width*devicePixelRatio,height*devicePixelRatio.

This approach ought to fix all cases of fuzzy favicons unrelated to Bug 798223.

Comment 8

[Terrell Kelley]

To avoid fuzzy icons, it may actually be preferable to scale 16x16 favicons using nearest neighbor or some other sharp scaling algorithm.

That is, of course, if no larger favicon is available.

Comment 9

[Greg Edwards]

Ideally they should use image-rendering: pixelated. (Bug 856337) Mac OSX uses -moz-crisp-edges but that only looks good at integer scale factors.

I filed Bug 888823 as a proposed implementation strategy for global hi-res ICO support.

Comment 10

[Terrell Kelley]

(In reply to Greg Edwards from comment #9)
> Ideally they should use image-rendering: pixelated. (Bug 856337) Mac OSX
> uses -moz-crisp-edges but that only looks good at integer scale factors.
> 
> I filed Bug 888823 as a proposed implementation strategy for global hi-res
> ICO support.

I don't know. That algorithm seems to be designed to make things appear pixelated, not to maximize sharpness. Not only does it say it's for sprite-work, it specifically states you must use nearest-neighbor or similar, which is a point-scaling algorithm. Point-scaling algorithms do maintain sharpness, but there are other ways that do not create a blocky appearance. 

image-rendering:crisp-edges would probably be better, if we ever implement other crisp scaling algorithms other than the pixelated nearest-neighbor. An example given in the spec is EPX, which is fairly low cost and works pretty well for small images at 2x scaling or lower. (Lower requires downscaling, of course. But we already have a high quality downscaler and we'd have to use it anyway if a larger icon was provided.) 

It would be nice to handle both icon upscaling and downscaling with a single CSS rule, but I don't think the image-rendering:pixelated spec is really designed for that--at least, as written. To do it all in CSS, we'd either need a new option or a way to set the upscaling and downscaling algorithms separately.

Comment 11

[Simon Howes]

Attachment: Screenshot 2013-11-18 14.00.01.png

I think we have a bug that doesn't need implementation to display hi-res favicons on the bookmarks bar but requires a fix, as it seems it is intermittent as some web sites' 32x32 favicon appears in all bars and menus. Engadget favicon second to left is hidpi version the rest are not, as an example.

Comment 12

[Greg Edwards]

That happens when the favicon is a PNG. The bug described here is that when the favicon is an ICO, only the 16x16 image gets stuffed in the Places database.

Comment 14

[Marco Bonardo [:mak]]

adding some more dependecies on similar reports that may contain useful information. Most of them could be fixed by adding support for high res favicons to the favicon service.

Comment 15

[Bret Shimomura]

Attachment: Comparison between Chrome (top) and Firefox (bottom) bookmark icons. Yuck!

Comment 16

[apropostech]

There are still a lot of icons (and other images) in Firefox 29 for Mac that are not retina.

Here are some that I've discovered...

The following in the bookmarks dropdown menu in the menu bar:
- folder icons for bookmarks (including smart folder icons)
- link icons for links without favicons 
- "Bookmarks toolbar" icon
- RSS folder icon
- the "get bookmark add-ons" icon

All of the above in the "Show All Bookmarks" pane as well as all the Toolbar icons in the bookmarks pane.

Icons in the Preferences Pane:
- All top icons
- (?) help button
- the action icons under Applications

All icons in the Add-ons manager.

Icons in the Preferences Pane, Add-ons manager and toolbar icons in the Bookmarks menubar dropdown.

The embedded window that appears for activating plugins (in particular the cross for closing it).

Comment 17

[Greg Edwards]

Bug 795665 that a way.

Comment 18

[Justin Dolske [:Dolske]]

This bug has meandered a bit, but I'm going to attach it to bug 1016548 to track completing our work for getting hidpi favicons into Firefox UI.

Previous work has already fixed favicons as shown in tabs. By my count, the remaining areas where we commonly need hidpi favicons are:

    * Awesomebar results
    * Places Library
    * Bookmarks toolbar
    * Back/forward navbutton dropdown
    * Sidebars (bookmarks/history)
    * Native menu menuitem favicons (Bookmarks/History from menubar)
    * Bookmarks/History subviews (from Menu Panel or in toolbar)
    * about:sessionrestore
    * Panorama (see also bug 1022005)

I've probably missed some places. :)

I suspect the first step is going to be to fix Places / the favicon service to do whatever we need (ie, fix the backend), and then we can go through and make sure the UI is doing the right thing to use it.

Comment 19

[Simon Howes]

Is anyone still working on this bug and its dependants? Can we push this any faster? 

Retina MacBook Pro computers were released over two years ago, plus many Windows machines now on the market with HiDpi monitors. Would be good to get this out the door with Yosemite UI improvements (bug 1040250)

Comment 20

[:Gavin Sharp [email: [e-mail]]]

We don't track meta bugs in the backlog generally, but the dependent bugs may merit tracking.

Comment 21

[Sören Hentzschel]

Now there are ten instead of six entries visible in the location bar by default without scrolling (bug 1195054). That means the situation is even more worse than before for HiDPI users. Could this feature request get more priority, please? The location bar is one of the most visible UI elements of the browser, it looks really bad and the number of users with HiDPI displays is more and more increasing.

Comment 23

[Pierre Ossman]

I don't think it is fully solved for tabs either, I'm afraid. It seems to only work for .ico files, not more standardised formats like .png.

Comment 24

[Marco Bonardo [:mak]]

Yes, there are 2 problems, one side the backend is not storing icons properly, the other side the frontend uses the first/last (don't recall atm) icon defined by the page, rather than the "best" one. the issues are sort of related, but both should be fixed.

Comment 25

[Loic]

(In reply to Marco Bonardo [::mak] from comment #24)
> Yes, there are 2 problems, one side the backend is not storing icons
> properly, the other side the frontend uses the first/last (don't recall atm)
> icon defined by the page, rather than the "best" one. the issues are sort of
> related, but both should be fixed.

That's why I got 2 different favicons for YouTube in the location bar e.g.?
http://i.imgur.com/pUrj2tP.jpg

Comment 26

[Marco Bonardo [:mak]]

(In reply to Loic from comment #25)
> That's why I got 2 different favicons for YouTube in the location bar e.g.?
> http://i.imgur.com/pUrj2tP.jpg

that's because one url has an older icon, visiting it may update the icon to a newer version, or not, depending on how the 2 pages expose the icon in their html code.
Btw, it's surely related to the above bugs.

Comment 27

[Terrell Kelley]

YouTube for some reason has one icon for the site (favicon.ico) and serves a different icon on every page of the site.

Comment 28

[Pierre Ossman]

Something has happened in this area and I'm now getting randomly different sizes for the icon on the tab as I reload the page.

Should I file a new bug or should we consider it covered by the overhaul needed for this bug?

Comment 29

[Chris Peterson [:cpeterson]]

(In reply to Pierre Ossman from comment #28)

Something has happened in this area and I'm now getting randomly different sizes for the icon on the tab as I reload the page.

Should I file a new bug or should we consider it covered by the overhaul needed for this bug?

Please file a new bug and link it to this bug # in the new bug's "Blocks" field. It's easier to close a new bug report as duplicate than to discuss and fix two bugs in one bug report. :) Linking the new bug #s will ensure the right people get CC'd on the new bug email.