MV3 and accessing file:/// resources (images)?

[stig (Stig Nygaard)]

With Mozilla and Google/Chromium (and Apples) latest agreement to allow a background-script to be defined as both a “event page” and a “service worker” in one and same manifest file, and browser picking only one way of running the script (preferable as service worker if/when supported), I have managed to create a “single-file” crossbrowser compatible MV3 version of my xIFr webextension (an exif-reader) supporting both Firefox 121+ and Chromium 121+ browsers.

It seems mostly to work as well as my current MV2 version of the extension, but besides the current confusing handling of host-permissions (at least for Firefox users), I have noticed that accessing images from file:/// urls are not supported in the MV3 version of my extension. Neither MV2 or MV3 version is able to display the images in my extension popups, which is probably a security feature. But in the MV2-version, I can still read and parse metadata of the image in my contentscript. Any way I can do the same when using MV3? An extra permission maybe?

My extension(s) is able to fetch image from both content and background scripts, so it could be either way.

Both MV2 and MV3 extensions, have the “<all_urls>” host permission. I have also tried adding the “activeTab” permission, but to no effect.

Current documentation I have found is lacking, unclear and confusing I think. Probably partly because it is a mix of MV2 and MV3 relevant information.

It’s a nice feature currently having xIFr (MV2-version) able to display metadata also in images which browser has opened from the local filesystem. Would love to keep that feature in a future MV3-version if I can!?

PS. The new more flexible browser support I’m talking about: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/background#browser_support

[juraj.masiar]

@stig

in the MV2-version, I can still read and parse metadata of the image in my contentscript

You can access image info of the file on the drive? That sounds like a huge security hole

In any case, there is a workaround for allowing access to files on the drive, but it’s not simple: https://github.com/fastaddons/GroupSpeedDial/wiki/Opening-local-.HTML-pages-stored-on-drive#solution-for-firefox

[stig (Stig Nygaard)]

@juraj.masiar

You can access image info of the file on the drive? That sounds like a huge security hole

I have had that thought too. But ended thinking that the browser probably was considering the “context”. Maybe only allowing me fetch the image if it is already open in the browser-tab (or at least only if content-script is running on a page hosted on file-system). But I have never investigated it further.

@juraj.masiar

In any case, there is a workaround for allowing access to files on the drive, but it’s not simple

Thanks. A good reference to have in case someone asks, but probably not something I’m going to use myself.

PS. I have many times tried to replace the “<all_urls>” host permission with the “activeTab” permission for general use in my extension. But I have never succeeded to fetch any image at all with that permission. So a possible scenario could be that it technically still is possible to access images loaded from file-system with that permission, just not the way my extension is designed or work. But maybe it is good policy if it is not possible at all. But it is practical for my extension if it is

[dotproto (Simeon Vincent)]

I’m very glad to hear you were able to get your MV3 extension manifest to work across multiple browsers, @stig!

I haven’t experimented too much with file:/// URLs in Firefox yet, but I agree with @juraj.masiar’s assessment that giving Manifest V2 unrestricted access to file:/// URLs (that is, not gated behind an additional flag like Chrome) is a surprising and concerning prospect. Especially in web page content scripts (that is, not on pages served form the local filesystem). That said, the details matter for this kind of thing and I may have misunderstood what is/isn’t possible.

@stig, at first glance xIFr seems like a good use case for the ability to access local resources. It might be best if you open a feature request on http://bugzilla.mozilla.org.

[stig (Stig Nygaard)]

@dotproto

Especially in web page content scripts (that is, not on pages served form the local filesystem)

Just to be clear… I have so far only tried fetching file:/// URLs from contentscripts running in “file: page content”. I have no reason to believe it works in “web page content”, but I haven’t tried it. I have also only tried fetching images already shown in the browser.

But yes. I will investigate a bit more and probably open a feature request.

PS. I have no current plans to release the MV3-version of xIFr any time soon, but if someone is curious about the “MV3 multi platform” support, I have checked it into a branch in my github(*). But be warned, it is not a little easy-read “demo extension” (though, if you focus only on how script in background is set up, that’s probably not too difficult to get).

(*) Sorry, but in the light of another current issue with spam-copies of my extension being posted on AMO, I don’t feel like linking directly to repository or the new branch right now.