Right now only a problem I see in Chrome, but I suspect/fear it is only a matter of time before I will see same problem in Firefox…
I have a browser-extension reading (using XMLHttpRequest()) EXIF-data from image files already included on the webpage itself. Even though I only have made this extension officially available for Firefox, it is written “cross-platform style” and basic functionality is working too in Chromium based browsers. Except…
Except maybe a year ago Chrome suddenly couldn’t read image-files on some webpages. And after some investigation I greatly suspect it is related to CORS updates for Content Scripts implemented in preparation of Manifest v3 support:
Ideally I would like my extension to fully work in Chrome too, but as a Firefox user it is not a major problem as long as it still works in Firefox. But I fear I will see same issue in Firefox too as Mozilla’s work for Manifest v3 support in Firefox continues…?
First of all I don’t understand there’s an issue [in Chromium]. I understand that cross-platform calls from Content Scripts will be more restricted in the future, but I have also understood it as I from Content Scripts still should be able read the same resources as used by the webpage itself? And that is exactly what I’m doing, I’m using XMLHttpRequest() to read data from image files already embedded on the webpage itself. Shouldn’t that always be possible no matter if it is cross-domain request or not?
… or do I need to do something to make XMLHttpRequest() call in my Content Script work completely like it was the webpage itself that did the request?
It is some time ago I experimented with the problem, but as I remember I also tried using fetch() instead of XMLHttpRequest(), but with no better results.
I also tried reading image-file from background-script instead, and sending the result to the Content-Script for parsing. But I could also only get that to work in Firefox. Maybe because the data I tried sending to Content-Script for parsing is still somehow “marked” as being “cross domain data” - or maybe (likely) because of other limitations in Chromium for sending data using messaging API. I have previously observed that messaging in Chrome is not as flexible as in Firefox when it comes to type and size of data sent.
An option to solve problem would probably be a rewrite to do both image reading and parsing from background-script. I assume that would work, but it would be a lot of work refactoring the code for that. So I hope I don’t need to do that.
To round-up, my questions are:
- Will my current code reading image files data from Content-Script continue to work in future versions of Firefox? And also if/when I migrate my extension to be a “native” Manifest v3 extension?
- If not, can I somehow modify my XMLHttpRequest() call to continue to work in Content-Script, or will I need to move read (and possible parse too) of data to background-script?
My xIFr browser-extension:
AMO: https://addons.mozilla.org/firefox/addon/xifr/
GitHub: https://github.com/StigNygaard/xIFr/
Content-script on GitHub: https://github.com/StigNygaard/xIFr/blob/master/WebExtension/contentscript.js
Example page to demonstrate the problem:
https://fstoppers.com/activity
I can look for Exif data in the images of this “activity feed” when using my xIFr extension installed in Firefox. However, when trying from Chrome it fails, and I see something like the following in Chrome’s browser console:
Access to XMLHttpRequest at 'https://cdn.fstoppers.com/styles/medium/s3/photos/364908/08/08/17eb67f08c8136843f66e448f4d01686.jpg' from origin 'https://fstoppers.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.