-
Notifications
You must be signed in to change notification settings - Fork 146
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AV.Asset.fromFile doesn't work with user-submitted files in Firefox WebExtensions #176
Comments
Interesting. What does |
Aha, that works - Now there's a different problem, though - the subarray call in return new Uint8Array(this.data.buffer, this.data.byteOffset+position, Math.min(length, this.length-position)) works. |
I brought the subarray thing up with the Mozilla people and they agreed it's a bug, so it'll probably get fixed in a future version of Firefox. The Uint8Array type difference still needs to be worked around by aurora.js, as they can't change it without contradicting the spec. For that, using |
When supplying a
File
received from an<input type=file>
or a drag-'n'-drop event toAV.Asset.fromFile
in extension code, trying to actually decode the asset throws anError: Constructing buffer with unknown type.
This is because files supplies by the user come from the page context, and Firefox Xrays them before passing them on to extension code. The Xrayed property apparently propagates through theFileReader
interaction inFileSource
into theUint8Array
passed to theAVBuffer
constructor, whose if-else switch doesn't recognize it as an instance ofUint8Array
- because it's checking against the non-Xrayed type.Firefox does provide an API for un-Xraying objects, but it's not yet available to WebExtensions, and shouldn't be necessary besides - Xrayed objects can still be read, which is all that aurora.js really cares about. An ideal fix would be one that smuggles the Xrayed buffers past the type check while still confirming that they have all the properties that
AVBuffer
needs, but I'm not sure what those are.One fix that does work is simply doubly constructing the
Uint8Array
in theFileReader.onload
callback, as in:This works because the second
Uint8Array
constructor performs a memory-to-memory copy from Xrayed memory to extension memory, but it's a rather costly workaround for (to my knowledge) a Firefox-only problem.The text was updated successfully, but these errors were encountered: