Open Bug 1315616 Opened 8 years ago Updated 2 days ago

Give extensions access to cached favicon URLs

Categories

(WebExtensions :: Compatibility, enhancement, P3)

51 Branch
enhancement

Tracking

(Not tracked)

People

(Reporter: from_bugzilla3, Unassigned)

References

(Blocks 3 open bugs)

Details

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

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.
Severity: normal → enhancement
Component: Untriaged → WebExtensions: Untriaged
Product: Firefox → Toolkit
Whiteboard: [design-decision-needed]
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#
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]
Priority: -- → P3
Whiteboard: [design-decision-approved][tabs] → [design-decision-approved][tabs][triaged]
webextensions: --- → ?
(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.
(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.
...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)
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)
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
(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.
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.
Lack of favicon access is resulting in extensions like "Bookmarks Manager and Viewer" fetching them from Google which is a privacy concern.

https://addons.mozilla.org/en-US/firefox/addon/bookmarks-manager-and-viewer/
(In reply to Kestrel from comment #14)
> Lack of favicon access is resulting in extensions like "Bookmarks Manager
> and Viewer" fetching them from Google which is a privacy concern.
> 
> https://addons.mozilla.org/en-US/firefox/addon/bookmarks-manager-and-viewer/

Same with Tree Style Tabs. And that made me remove favicons from the tab-stat addon.

Comment 9 is very true too.

How about making faviconurl return a data: url of the cached icon when the property is read?
(that would have the side effect of fixing the issue on all addons using faviconurl without fixing every single one of them)
Related: Bookmarks BookmarkTreeNode API should expose favicon URL - https://bugzilla.mozilla.org/show_bug.cgi?id=1411120
Thanks for linking the two bugs, Geoffrey. This is definitely the same problem I was running into in https://bugzilla.mozilla.org/show_bug.cgi?id=1411120
Blocks: 1311472
This missing feature is also what forced me to develop code to fetch() the favicon in my extension Bookmark Search Plus 2 https://addons.mozilla.org/fr/firefox/addon/bookmark-search-plus-2/
to avoid the privacy problem mentioned above.

I had to develop a basic parser to retrieve the favicon URL out of each bookmarke page, then fetch the favicon and store it in local storege as an URI using 

FReader.readAsDataURL(blob);

This is still perfectible, but significant work and there are still some cases failing .. while all is already inside the browser database :-( (but inaccessible)

So this is:
- duplicate work
- duplicate storage


The browser.bookmarks API should make the favicon available as part of the BookmarkTreeNode object, and displayable as an image.

Note: ready to help if I can, let me know.
See Also: → 1411120
Hi,

I'd like to see favicons exposed as part of history search items:

https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/history/HistoryItem

https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/history/search

Since it appears per comments on bug 1411120, that this has become a more generic issue in also tackling BookmarkTreeNode, and since the latter is, if previous FF add-on behavior is any indication, closely related to history search, I wonder if my request should be tacked on here as well, or whether I should file a separate issue?
Product: Toolkit → WebExtensions
Any chance making this work in Firefox 64?

Because Firefox 64 will block popular way to get favicon using Google service:
https://plus.google.com/_/favicon?domain_url=https://bugzilla.mozilla.org
1. This way is really a privacy-nightmare… sending potentially all your domains to Google Plus.
2. Why does Firefox 64 block access to those? Any source? Or why do you think, it does?
I'm sorry I should mention more info. This is the error you get now in 64:

The resource at “https://plus.google.com/_/favicon?domain_url=http://shmu.sk” was blocked because content blocking is enabled and the resource was classified as a slow tracking resource.

Using the "<all_urls>" permission. Adding new permission for the host will fix it as per docs: "bypass tracking protection if the host is a full domain without wildcards".
I couldn't find any release info for version 64.

Any news on this? I still have to use a workaround to load the extension page favicon (chrome://mozapps/skin/extensions/extensionGeneric-16.svg).
https://github.com/eoger/tabcenter-redux/blob/699694ff0ebdc0cc06a5c3a1318c6e4519df663e/src/sidebar/tab.js#L175

It would be nice to have this to avoid ugly hacks in WebExtensions.

Only 3 years later and still no progress? Can you guys please fix this API as @aafn mentions
"The browser.bookmarks API should make the favicon available as part of the BookmarkTreeNode object, and displayable as an image."

Does this bug cover both read access and write access?

Hello @Sean Feng, only read access is demanded here.

Blocks: manifest-v3
No longer blocks: 1687757

Was it resolved? I need to access favicons for my extension.

It would be nice if this could be resolved to allow extension authors use the ressources available.
I have two extensions installed that need to do their own thing to retrieve page icons.

Sync doesn't cover this type of data so on every machine and every FF instance installed these addons have to retrieve favicons allover again and again and again ... that's painful to watch.

Please! Get this sorted.

Severity: normal → S3
Duplicate of this bug: 1806955
Duplicate of this bug: 1806956

Are there any plans to allow the page-icon protocol (bug 1354248) on webExtension pages? I wrote an extension to display my bookmarks on new tabs, using the bookmarks API, but currently to show the favicons I request them from a Google server, by doing: <img src="https://s2.googleusercontent.com/s2/favicons?domain_url='+[the bookmark ur]+'"/>...
It's fairly horrible in terms of performance and privacy, because the favicons are right there in storage, but each bookmark being displayed results in a network request and the url gets sent to Google.

About 40 people use my extension, so I warn them of that in the description because it's not even something that can be added to the permissions section. It looks like this bug is taking a while because of privacy/security concerns, but without an official way to fetch favicons, devs will resort to terrible hacks that leak bookmarks data to sketchy services, or custom fetching code for a job that should be handled by the browser.

What are the technical obstacles that prevent implementing this?

I need the implemented "chrome://favicon/" permission to get site's icon for a bookmark manager extension.

The favicons are already in favicons.sqlite SQLite DB in browser's profile folder.
Just publish the API to access them.

Duplicate of this bug: 1893674

"chrome://favicon/" permission was implemented in Chromuim a long time ago.

There are "chrome://favicon/" for MV2 and "favicon" for MV3 permissions.

It would useful for extensions that work with bookmarks, history, downloads and for extensions that just list of urls.


For example, a HTML code that uses this feature:

<img id="favicon" src="chrome://favicon/size/16@2x/https://twitter.com/">

(MV2 version)

See Also: → 1905397
See Also: → 1906755
You need to log in before you can comment on or make changes to this bug.