Firefox InternalError (MV3)

So if you get a Firefox “InternalError” in browser-console when running your extension/contentscript on some sites, should you report a bug in bugzilla, or could it still be “your own” error?

It’s complicated code (and a complicated case). Won’t be easy to create a simplified test-case. Especially since it involves image-parsing (exif-data extraction) code I haven’t written myself, but inherited from an old extension which I forked my “xIFr” exif-reader extension from. And I’m not really expert on that subject.

I traced the error to a Int8Array. subarray() call throwing an

Error: Permission denied to access property “constructor”

accompanied by the error

Uncaught (in promise) InternalError: Promise rejection value is a non-unwrappable cross-compartment wrapper.

Any idea what that means?

Error only happens in MV3 version of my extension (not yet published on AMO, but in a secondary branch in my github repository) and seems to depend on

  1. Site visited
  2. Fetching image (to parse data from) from backgroundscript or fetching from frontend/contentscript
  3. The browser used

First of all, image is located at the same origin/domain as the page it is embedded in. For other cases I always use fetch from backendscript (well unless protocol is file:, data: or blob:). But fetching image (to parse) from frontend when image is located at same origin/domain as page, solved a problem on another site where it failed when fetching from background.

The parsing always happens in frontend and involves several parallel running scripts (if image is fetched from backgroundscript, imagedata is sent to contentscript for parsing).

For the site creating problems:

  • It works in Chrome MV3 no matter if I am fetching from frontend/contentscript or from backendscript.
  • It works in Firefox MV3 if I fetch from background, but fails when fetching from frontend/contentscript.
  • It works in Firefox MV2 no matter if I am fetching from frontend/contentscript or from backendscript.

It doesn’t matter if I open image directly in the browser or open the page embedding the image.

It works on some sites, others it doesn’t [EDIT: removed claim it worked on most sites].

Does this ring a bell to anyone? Any ideas?

Yes, this is a though one. Curious to see if there will be any response to this at all…

1 Like

And btw, one of the sites creating problems is my own F.ex:

or the image opened directly:

So I could eventually experiment with setup of the site…

I found an issue in bugzilla which sounds related, even though I don’t really understand the technical details discussed?:

Since I don’t really understand the technical discussion, I’m not sure if a possible work-around is hidden in the details?

EDIT: Or maybe not directly related anyway? In my case the fetching seems to be successful. It is not until playing with fetched data in “TypedArrays”, problem seems to occur. But still, depends on how the data was fetched?!..

1 Like

I think the problem isn’t how the file is fetched.
It’s how the add-on creates an Int8Array from the fetched ArrayBuffer. (4.6 KB)

  1. Install the attached add-on.
  2. Go to the add-on options, and enable the “” host permission.
  3. Go to
  4. Open the console with Ctrl-Shift-I

See Typed arrays generated by TextEncoder belong to a wrong context


Thanks a lot @hans_squared !

My hope for help wasn’t too big without a simple little test-case to demonstrate the issue.
This definitely looks related to how the arrays are created as you suggest. Console output from your extension:

The tricky part might be to get it to work no matter if fetched data comes from backgroundscript or contentscript. But I got a very good clue now for further investigations and experiments.

Thanks :slightly_smiling_face:

At first tries it seems just using window.Uint8Array in my contentscript solves my problem. There are however many combinations of code-paths depending on browser, background/foreground fetch and types of metadata detected in images. But very promising! :+1: