Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Give extensions access to cached favicon URLs

NEW
Unassigned

Status

()

Toolkit
WebExtensions: Compatibility
P3
enhancement
9 months ago
12 days ago

People

(Reporter: Stephan Sokolow, Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 1 bug)

51 Branch
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [design-decision-approved][tabs][triaged])

(Reporter)

Description

9 months ago
User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0
Build ID: 20161017194958

Steps to reproduce:

Tried to write an extension that uses tab titles, urls, and favicons to produce an analogue to the backup and export options in the bookmark manager.


Actual results:

To resolve tabs.Tab.favIconUrl, I had to grant the addon "<all_urls>" permission and I've spent a whole day (and counting) trying to write suitably non-fragile fetch() code when all I want is already retrieved and staring me in the face to the left of each Tab.title.


Expected results:

Given that favicons serve a similar role to tab titles and have similar privacy and permissions implications, there should be a simple API to retrieve the already-in-memory data using only the "tabs" permission and without worrying about cache misses.

In line with the naming scheme already in place, I propose tabs.Tab.favIconBlob.

Updated

9 months ago
Severity: normal → enhancement
Component: Untriaged → WebExtensions: Untriaged
Product: Firefox → Toolkit
Whiteboard: [design-decision-needed]

Updated

9 months ago
Component: WebExtensions: Untriaged → WebExtensions: Frontend
Whiteboard: [design-decision-needed] → [design-decision-needed][tabs]
To be discussed at January 24 WebExtensions Triage mtg. 

Agenda: https://docs.google.com/document/d/1add-6FL8mzksvzbyB83HUmEkVmKERd-nt740AYr-4PE/edit#

Comment 2

6 months ago
We talked about this, and decided that we want to support this use case, but that we should do it by giving extensions access to URLs backed by our favicon cache rather than by handing them image blobs.
Status: UNCONFIRMED → NEW
Component: WebExtensions: Frontend → WebExtensions: Request Handling
Ever confirmed: true
Summary: Add tabs.Tab.favIconBlob to WebExtensions API → Give extensions access to cached favicon URLs
Whiteboard: [design-decision-needed][tabs] → [design-decision-approved][tabs]

Updated

6 months ago
Priority: -- → P3
Whiteboard: [design-decision-approved][tabs] → [design-decision-approved][tabs][triaged]

Updated

6 months ago
webextensions: --- → ?
(Reporter)

Comment 3

6 months ago
(In reply to Kris Maglione [:kmag] from comment #2)
> We talked about this, and decided that we want to support this use case, but

That's good to hear.

> that we should do it by giving extensions access to URLs backed by our
> favicon cache rather than by handing them image blobs.

Is the rationale documented anywhere I could read? I'm curious about what makes cache URLs easier to support than blobs in this situation.

Updated

5 months ago
Duplicate of this bug: 1316097

Comment 5

5 months ago
(In reply to Stephan Sokolow from comment #3)
> Is the rationale documented anywhere I could read? I'm curious about what
> makes cache URLs easier to support than blobs in this situation.

In the case of blobs, we would need to fetch, decode, and store them in memory for every tab, and there would be additional overhead involved in displaying them as well. Providing access to favicon cache URLs has better performance characteristics and a simpler implementation, and still allows extensions to fetch blobs if and when they actually need them.
(Reporter)

Comment 6

5 months ago
...oh yeah! e10s is a thing now!

I was still in a mindset that it'd be cheaper to just reference the existing decoded blob used to render the tab.

(Because I don't know of a way to display an arewee10syet-style report for just the ~30 extensions I have installed and because I don't want to risk my privacy extensions silently failing, I decided to just disable e10s in my Aurora and wait until I'm forced to migrate onto it... despite my loadout and tab use being pathologically unsuited to single-process operation.)
(In reply to Kris Maglione [:kmag] from comment #2)
> We talked about this, and decided that we want to support this use case, but
> that we should do it by giving extensions access to URLs backed by our
> favicon cache rather than by handing them image blobs.

Was the idea to have a tab.faviconUrl property, or some API that would return a (cached) favicon URI for any domain?  And if it's the latter, does it make sense to make it part of the MozURLUtils WebIDL from bug 1315558 comment 4?
Flags: needinfo?(kmaglione+bmo)

Comment 8

5 months ago
My thought was that faviconUrl would point to a URL backed by the favicon cache, and then we'd have to give extensions access to those URLs.
Flags: needinfo?(kmaglione+bmo)
Blocks: 1339561

Updated

4 months ago
webextensions: ? → ---
Some ideas/issues regarding this:

- Apps that serve different favicons for logged in users won't work for container tabs (EG WhatsApp does this)
- Querying for a future page load rather than an existing tab would permit use cases like:
  https://github.com/mozilla/testpilot-containers/issues/500
- In the near/distant future we might permit different icons like PWA icon, mask-icon
  - perhaps other files are relevant here too like manifest, feature policy etc

Would it make sense to permit an api similar to:

browser.cache.icons({url: "example.com", cookieStoreId: 'blah-12'});
Relatedly, Whimsy would like the user to be able to choose to show the thumbnails of sites instead of gifs on the overridden newtab page, but we have no way of getting them.  A similar api (or an extension to this api) would be very helpful.
Surprisingly, Chromium have a way to access to the favicon cached in a browser through "chrome://favicon/" (e.g. chrome://favicon/https://youtube.com/).
And this is used as implicit public way to access to the favicon from chrome extension

- https://stackoverflow.com/questions/10301636/how-can-i-get-the-bookmark-icon-in-chrome
- https://github.com/yemount/IconicHistory
   - https://github.com/yemount/IconicHistory/blob/c75a1c0/iconic_history.js#L111
   - https://github.com/yemount/IconicHistory/blob/c75a1c0/iconic_history.js#L138
Component: WebExtensions: Request Handling → WebExtensions: Compatibility

Comment 12

22 days ago
(In reply to Tetsuharu OHZEKI [:tetsuharu] [UTC+9] from comment #11)
> Surprisingly, Chromium have a way to access to the favicon cached in a
> browser through "chrome://favicon/" (e.g.
> chrome://favicon/https://youtube.com/).
> And this is used as implicit public way to access to the favicon from chrome
> extension
> 
> -
> https://stackoverflow.com/questions/10301636/how-can-i-get-the-bookmark-icon-
> in-chrome
> - https://github.com/yemount/IconicHistory
>    -
> https://github.com/yemount/IconicHistory/blob/c75a1c0/iconic_history.js#L111
>    -
> https://github.com/yemount/IconicHistory/blob/c75a1c0/iconic_history.js#L138

Firefox has page-icon: protocol, for chrome context so far. It may need to be extended to support getting (and policy for privacy), status, and so on.
(Reporter)

Comment 13

22 days ago
And you'll want to make sure it's clearly documented as the recommended way to do thing in all of the places people are likely to look.

Even with the StackOverflow answers pointing to it, the approach Chrome took comes across as an internal API that got accidentally exposed to the world and is only allowed to continue to work because of the sheer number of extensions which would break if they fixed their mistake.
Depends on: 1354248
You need to log in before you can comment on or make changes to this bug.