Closed
Bug 1411120
Opened 8 years ago
Closed 7 years ago
Bookmarks BookmarkTreeNode API should expose favicon URL
Categories
(WebExtensions :: General, enhancement, P5)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 1315616
People
(Reporter: mock.brian, Unassigned)
References
Details
(Whiteboard: [bookmarks][design-decision-approved])
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.62 Safari/537.36
Steps to reproduce:
I used the WebExtensions bookmarks API to make a new tab page extension but was unable to find a way to obtain favicons for bookmarks.
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/bookmarks/BookmarkTreeNode
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/bookmarks/getSubTree
Actual results:
BookmarkTreeNode does not expose the favicon for a bookmark.
Expected results:
There should be a new optional property called `faviconUrl` which is a URL pointing to the favicon for the website. Ideally this URL would point at the browser's cached version to avoid network requests.
Updated•8 years ago
|
Component: Untriaged → WebExtensions: General
Product: Firefox → Toolkit
Updated•8 years ago
|
Status: UNCONFIRMED → NEW
status-firefox57:
--- → wontfix
Ever confirmed: true
Priority: -- → P5
Whiteboard: [bookmarks][design-decision-needed]
Comment 1•8 years ago
|
||
Related: Give extensions access to cached favicon URLs - https://bugzilla.mozilla.org/show_bug.cgi?id=1315616
Updated•7 years ago
|
Severity: normal → enhancement
Comment 2•7 years ago
|
||
From a standpoint of an addon developer, it would be better to expose the favicon as base64 to avoid having to do a lot of requests to multiple favicon URLs.
Indeed, as add-on developers, what we need is a data: URI as faviconUrl, to directly display as an <img>.
This also has the additional benefit of avoiding cases where the destination URL is asking for credentials (user/pwd) to retrieve the contents.
Comment 4•7 years ago
|
||
Hi mock-brian, this has been added to the agenda for the WebExtensions APIs triage on March 13, 2018. Would you be able to join us?
* We normally spend 5 minutes per bug
* The more information in the bug, the better
* The goal of the triage is to give a general thumbs up or thumbs down on a proposal; we won't be going deep into implementation details
Relevant Links:
* Wiki for the meeting: https://wiki.mozilla.org/WebExtensions/Triage#Next_Meeting
* Meeting agenda: https://docs.google.com/document/d/1b4r8z964_Est_mbSYUx9jtRt-HTtXgu-EAzM_3yr7ww/edit
* Vision doc for WebExtensions: https://wiki.mozilla.org/WebExtensions/Vision
Reporter | ||
Comment 5•7 years ago
|
||
Hi Caitlin, I've put it on my calendar and should be able to attend. Thanks for the invite.
- Brian
Comment 6•7 years ago
|
||
I'd like to see favicon data exposed for history (as well)
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/history/HistoryItem
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/history/search
Should I file a separate issue or is this close enough to tack on here?
Comment 7•7 years ago
|
||
This was approved in the design-decision meeting, but we're going to dupe this into the more general bug 1315616, which has been approved.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
See Also: → 1315616
Whiteboard: [bookmarks][design-decision-needed] → [bookmarks][design-decision-approved]
Comment 8•7 years ago
|
||
Did that approval include exposing favicons on history items as well, Caitlin?
Reporter | ||
Comment 9•7 years ago
|
||
Brett: I believe the resolution from the meeting was close this in favor of https://bugzilla.mozilla.org/show_bug.cgi?id=1315616 which is a more general solution that would solve both of our use cases and also address some security concerns around the API.
Updated•7 years ago
|
Product: Toolkit → WebExtensions
Updated•7 years ago
|
status-firefox57:
wontfix → ---
You need to log in
before you can comment on or make changes to this bug.
Description
•