Provide access to page thumbnails (moz-page-thumb:// is blocked)

RESOLVED DUPLICATE of bug 1246693

Status

()

Toolkit
WebExtensions: Untriaged
RESOLVED DUPLICATE of bug 1246693
2 years ago
2 years ago

People

(Reporter: Nancy Grossman, Unassigned)

Tracking

46 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

2 years ago
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20160425115337

Steps to reproduce:

moz-page-thumb://thumbnail/?url=https%3A%2F%2Fsupport.mozilla.org%2Fen-US%2Fquestions%2F941770

Attempted to load the thumbnail via XMLHttpRequest from the background script and from the content script of a WebExtension after loading the URL from the location bar to confirm that the image existed.


Actual results:

Failed in both cases. From background.js:

Security Error: Content at moz-extension://144de1e5-ba0c-4ddb-92e9-275aad969c54/_blank.html may not load or link to moz-page-thumb://thumbnail/?url=https%3A%2F%2Fsupport.mozilla.org%2Fen-US%2Fquestions%2F941770.
NS_ERROR_DOM_BAD_URI: Access to restricted URI denied background.js:13:0

From content.js:
Security Error: Content at https://userstyles.org/ may not load or link to moz-page-thumb://thumbnail/?url=https%3A%2F%2Fsupport.mozilla.org%2Fen-US%2Fquestions%2F941770.
Security Error: Content at moz-extension://144de1e5-ba0c-4ddb-92e9-275aad969c54/ may not load or link to moz-page-thumb://thumbnail/?url=https%3A%2F%2Fsupport.mozilla.org%2Fen-US%2Fquestions%2F941770.
NS_ERROR_DOM_BAD_URI: Access to restricted URI denied ExtensionUtils.jsm:30:0

Notice that loading the URI from the content script always generates two Security Errors, the first naming the page as the origin and the second naming the extension as the origin.


Expected results:

At the least, thumbnails of URLs open in browser tabs should be available to the background script. Either WebExtensions should have cross-origin access to `moz-page-thumb:`, or the images should be available to them via a `runtime.sendMessage` call to a browser-supplied WebExtension with a well-known extensionId. The 'tabs' permission should be required for access.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1246693
(Reporter)

Comment 2

2 years ago
This isn't a duplicate, Kris. That bug asks for a way to generate a new thumbnail for an arbitrary URL without displaying the page in the active tab. This bug asks for a way to retrieve existing thumbnails, already generated automatically by the browser and available via `moz-page-thumb://`, in a WebExtension.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
(Reporter)

Comment 3

2 years ago
(In reply to Nancy Grossman from comment #0)
> At the least, thumbnails of URLs open in browser tabs should be available to
> the background script. Either WebExtensions should have cross-origin access
> to `moz-page-thumb:`...

This could be resolved by adding an optional `Tab.thumbnailURL` property, analogous to the exisiting `Tab.favIconUrl` property, with a URI that can be downloaded by the background script. In Chrome that would be a chrome:, chrome-extension:, chrome-extension-resource: URL, so maybe in Firefox a moz-extension: or moz-extension-resource: URL. The URL should be acceptable in HTML tags and CSS stylesheets in override pages and other extension pages.


(In reply to Nancy Grossman from comment #0)
> ... or the images should be available to them via a
> `runtime.sendMessage` call to a browser-supplied WebExtension with a
> well-known extensionId. The 'tabs' permission should be required for access.

Bug 1246693 asks for a means to retrieve a thumbnail for any given URL. That could also resolve this issue; the `tabs` permission isn't needed if all URLs have thumbnails. That's more than is needed here, though.
The moz-page-thumb: protocol is an implementation detail. One of the explicit goals of this project is to hide implementation details as much as possible, so if we're going to provide access to page thumbnails (which I think we should), it has to be via thumbnail API. If the the API described in bug 1246693 doesn't meet your needs, please add a comment there explaining why, and what more you need from it.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1246693
(Reporter)

Comment 5

2 years ago
There is no API at all described in bug 1246693. You've commented there already, so you know that already.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
I really don't want to get into an argument over this. There's only going to be one thumbnail API, and it's being tracked in bug 1246693. If you need something different than is being described there, please add a comment describing it.

I have authority in this matter, so please don't continue to reopen this bug without discussion. It's not going to get us anywhere.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1246693
You need to log in before you can comment on or make changes to this bug.