Open Bug 751712 Opened 12 years ago Updated 5 months ago

Add support for HTML5 sizes attribute in <link rel=icon>

Categories

(Firefox :: General, enhancement)

Product:
Firefox
Component:
General
Type:
enhancement

Tracking

()

People

(Reporter: Margaret, Unassigned)

References

(Blocks 4 open bugs)

Details

(Keywords: dev-doc-needed, html5, Whiteboard: [parity-fennec] p=0) 

See http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#attr-link-sizes.

To start, we should re-work DOMLinkHandler and our favicon-updating code to deal with the fact that there might be multiple <link rel=icon> tags with icons of different sizes. Then, we could start by looking for a 16x16 icon, since that's what we currently use in the UI. And then if we eventually want to introduce larger icons to the UI, it shouldn't be too hard to do that.

We're working on this for mobile in bug 715263, but right now it looks like we're just trying to find the largest icon possible.

And if we eventually want to be able to handle multiple icon sizes in the same .ico/.icns file, we'll need bug 419588.
Keywords: html5
Assignee: nobody → fracture91
Blocks: 768703
Blocks: 120352
Blocks: 779027
In addition, Firefox currently loads all declared pictures. For example, if the <head> section contains:

<link rel="icon" type="image/png" href="/favicon-16x16.png" sizes="16x16" />
<link rel="icon" type="image/png" href="/favicon-32x32.png" sizes="32x32" />
<link rel="icon" type="image/png" href="/favicon-96x96.png" sizes="96x96" />
<link rel="icon" type="image/png" href="/favicon-160x160.png" sizes="160x160" />
<link rel="icon" type="image/png" href="/favicon-196x196.png" sizes="196x196" />

Then:
- Firefox loads the 5 pictures (checked in Apache's log).
- Firefox uses the last declared picture. In this example, it uses the 196x196 picture.
Blocks: fxdesktopbacklog
Whiteboard: p=0
I just stumbled upon this stalled issue, and was wondering what it would involve to get it fixed. From the description seems to be an relatively easy thing to fix, but I clearly have no clue what it would involve.
Flags: firefox-backlog?
Whiteboard: p=0 → [parity-fennec] p=0
(In reply to Hernán Rodriguez Colmeiro (:peregrino) from comment #2)
> I just stumbled upon this stalled issue, and was wondering what it would
> involve to get it fixed. From the description seems to be an relatively easy
> thing to fix, but I clearly have no clue what it would involve.

I saw you were talking to rnewman on IRC last night. Let me know if I can do anything to help! Right now I think we may be one of the only browsers to support this, so not many sites do it, but maybe more would do it if more browsers implemented it :)
Hey! Yeah, some guidance on this would be awesome. I'm picking no-so-big issues to get back on track, but I don't know what should I do in order to fix this one :) Ideas? Pointers? Files/Docs to read?
(In reply to :Margaret Leibovic from comment #3)
> 
> I saw you were talking to rnewman on IRC last night. Let me know if I can do
> anything to help! Right now I think we may be one of the only browsers to
> support this, so not many sites do it, but maybe more would do it if more
> browsers implemented it :)

There are two issues in one:
- "sizes" attribute support: Safari and Opera supports it. Not sure about IE. You can find some clues here: http://realfavicongenerator.net/favicon_compatibility
- Multiple loading (that was my comment on 2013-12-01): only Firefox and Chrome are impacted. IE, Safari, Opera, etc. are not impacted.

Android Chrome specs indicate a sizes attribute (https://developer.chrome.com/multidevice/android/installtohomescreen), along with Google TV specs (https://developers.google.com/tv/web/docs/design_for_tv#favicons). Signs that this attribute is getting more popular, even if it is far from mainstream.

In addition, RealFaviconGenerator (http://realfavicongenerator.net/) generates several PNG pictures and relies on the sizes attribute. Although this service is only a few months old, it's becoming more and more popular (yeah, I'm the author of this tool :) ). This FF issue and corresponding Chrome issues are listed here: http://realfavicongenerator.net/faq#troubleshootings
Flags: firefox-backlog? → firefox-backlog+
No longer blocks: fxdesktopbacklog
See Also: → PlacesHiresFavicons
Just a small addition: Coast by Opera also specifies a 228x228 icon with the help of the sizes attribute. See http://dev.opera.com/blog/introducing-coast-by-opera/.

(In reply to Philippe Bernard from comment #5)
> (In reply to :Margaret Leibovic from comment #3)
> > 
> > I saw you were talking to rnewman on IRC last night. Let me know if I can do
> > anything to help! Right now I think we may be one of the only browsers to
> > support this, so not many sites do it, but maybe more would do it if more
> > browsers implemented it :)
> 
> There are two issues in one:
> - "sizes" attribute support: Safari and Opera supports it. Not sure about
> IE. You can find some clues here:
> http://realfavicongenerator.net/favicon_compatibility
> - Multiple loading (that was my comment on 2013-12-01): only Firefox and
> Chrome are impacted. IE, Safari, Opera, etc. are not impacted.
> 
> Android Chrome specs indicate a sizes attribute
> (https://developer.chrome.com/multidevice/android/installtohomescreen),
> along with Google TV specs
> (https://developers.google.com/tv/web/docs/design_for_tv#favicons). Signs
> that this attribute is getting more popular, even if it is far from
> mainstream.
> 
> In addition, RealFaviconGenerator (http://realfavicongenerator.net/)
> generates several PNG pictures and relies on the sizes attribute. Although
> this service is only a few months old, it's becoming more and more popular
> (yeah, I'm the author of this tool :) ). This FF issue and corresponding
> Chrome issues are listed here:
> http://realfavicongenerator.net/faq#troubleshootings
Looking at [this waterfall chart](http://www.webpagetest.org/result/150711_RQ_MY8/1/details/), Firefox is making requests for `favicon16x16.png`, `favicon32x32.png`, `favicon96x96.png`, `favicon160x160.png`, and `favicon192x192.png` interleaved with actual page content.

This uses up parallel connections and slows down actual content during the critical path. This has significant performance problems on shaky or high-latency connections.

Desktop Chrome, Safari, and IE all load a single favicon after the `onLoad` event. That would be an improvement.
(In reply to tigt from comment #7)
> Looking at [this waterfall
> chart](http://www.webpagetest.org/result/150711_RQ_MY8/1/details/), Firefox
> is making requests for `favicon16x16.png`, `favicon32x32.png`,
> `favicon96x96.png`, `favicon160x160.png`, and `favicon192x192.png`
> interleaved with actual page content.
> 
> This uses up parallel connections and slows down actual content during the
> critical path. This has significant performance problems on shaky or
> high-latency connections.
> 
> Desktop Chrome, Safari, and IE all load a single favicon after the `onLoad`
> event. That would be an improvement.

Strange. Firefox doesn't report favicon network data at all in the Network panel even when I do a hard refresh or use a Private Window to bypass the cache... Seems like cause for another bug report.

On my much more simplistic page at https://patrick.dark.name/, I see the same problem: http://www.webpagetest.org/result/150711_G3_SBF/1/details/. Unfortunately, webpagetest.org doesn't report which version of Firefox it's using, which isn't particularly helpful.
(In reply to Patrick Garies from comment #8)

> Unfortunately, webpagetest.org doesn't report which version of Firefox it's
> using, which isn't particularly helpful.

It's well-hidden inside the expandable Request Headers section at the bottom of the page:

User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:39.0) Gecko/20100101 Firefox/39.0 PTST/223
I would like to emphasis the comment of @Tigt about performance by telling why this is important.

More and more favicon generators create several PNG icons:
- RealFaviconGenerator
- Favic-o-matic
- Faviconit
- Epicfavicongenerator
- Favicon-generator
- ...

RealFaviconGenerator alone created nearly 500,000 favicons in a year and a half. The corresponding WordPress plugin has more than 60,000 active installs. (I'm the author of this service)

Bottom line: When this issue was opened 3 years ago, it didn't really matter. A single PNG icon (if any) was the standard. But multiple PNG icons, including a huge 192x192 icon for Android, becomes the new standard.

I don't want to shortcut the vote system. I just really think this issue is undervalued. Plus I somehow feel responsible for this, being one of the guys who produce so many pictures :)
Blocks: 1271838
Also see https://github.com/RealFaviconGenerator/realfavicongenerator/issues/221

This issue also causes ugly icons on devices with high-resolutions (Retina). Also - as it was said already - this issue is more important now, because if more and more website use multiple icons and bandwith becomes important (as the use of mobile devices grows) Firefox really should not load *all* favicons it can find..
Another way to clarify this issue:

Do you plan to either:

- Support the sizes someday
- Support the Web App manifest / manifest.webmanifest (https://www.w3.org/TR/appmanifest/).

Although the first option looks like a "must have", the second would be a good way to mitigate the issue since it also contains icons. As a matter of fact, some people at Mozilla (but not necessarily the FF team) are working on the topic, see https://github.com/RealFaviconGenerator/realfavicongenerator/issues/228
With https://bugzilla.mozilla.org/show_bug.cgi?id=798223 implemented, I think the priority of this issue should be re-evaluated. Issue 798223 is about using a high def icon for high-dpi screens. However, what I observe:

- I visit a page where FF is offered two PNG icons: 16x16 and 32x32 (for an example of this, visit https://realfavicongenerator.net/favicon_compatibility_test)
- FF displays the 16x16 icon in the tab. No surprise, this is the purpose of this issue.
- If I do a screenshot, I notice FF tab icon is 40x40. So using the 32x32 icon would have been a better choice.
Still no news about this issue?
Assignee: adhurle → nobody
Blocks: hidpi-favicon-ui
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 41 votes.
:mossop, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(dtownsend)
Severity: S3 → --
Type: defect → enhancement
Flags: needinfo?(dtownsend)
You need to log in before you can comment on or make changes to this bug.