Created attachment 8454872 [details] main.js User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Firefox/30.0 (Beta/Release) Build ID: 20140621080000 Steps to reproduce: With a new addon (created with cfx init), I inject a script using the TextEncoder API : var testU8 = new TextEncoder('utf-8').encode('test'); var isU8 = testU8 instanceof Uint8Array; alert('isU8=' + isU8); I attached the complete main.js which injects it with tab.attach. Then, I navigate to any page to trigger the script. Actual results: In Firefox 30 and Firefox nightly (33.0a1 (2014-07-11)), I get "isU8=false". The result of TextEncoder#encode seems to be a Uint8Array but isn't an instanceof Uint8Array. Expected results: I a classic web page (with a <script>), I get the expected result : "isU8=true", the result of TextEncoder#encode is instanceof Uint8Array. The issue is also here when using the addon Scriptish (a fork of Greasemonkey) which doesn't seem to use Jetpack : I'm sorry if I chose the wrong product !
I think because they're living in two different compartments. Basically the `Uint8Array` is in the sandboxed environment, where `TextEncoder` will end up to use the `Uint8Array` of the original window. To make a test, you can simple do: console.log(testU8 instanceof unsafeWindow.Uint8Array); // should be true `instanceof` is not too reliable for this very reason. So, it's a Uint8Array, but just a Uint8Array from a different compartment. Accessing TypedArray across compartments is slow, so I suggest you to clone the object: var testU8 = new TextEncoder('utf-8').encode('test'); var objU8 = cloneInto(testU8, window); // clones the object to the sandboxed window console.log(objU8 instanceof Uint8Array); // true That also should result in faster code – you shouldn't get any warning in the Browser Console anymore too.
The examples with unsafeWindow.Uint8Array and cloneInto work, thank you. I thought that the injected script would get Uint8Array and TextEncoder from the same environment (as the result of TextEncoder#encode) but your explanation proved me wrong.
I'll close the issue as INVALID since Firefox nightly gives a message explicit enough.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.