772 bytes, text/html
47 bytes, text/x-phabricator-request
|Details | Review|
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.120 Safari/537.36 Steps to reproduce: 1. Open the attached testcase or visit it online at http://plnkr.co/edit/vooLd13AygHzTrQcrvYr 2. Click "Test Main Thread" to perform 3 POSTs using an XMLHttpRequest, one each for a string, Uint8Array, and ArrayBuffer. See the results below the buttons in the "Main Thread Results" section. 3. Click "Test Worker Thread" to do the same using a web worker. See the results in the "Worker Thread Results" section. In addition to the 36.0a1 (2014-10-18) nightly, this is also seen in 32.0.3 and was observed on both Mac and Windows (64-bit) installations. Chrome 37, Safari 6.0.5, and Internet Explorer 11 pass all 6 test cases. Actual results: On the main thread, the XMLHttpRequest accepts all three data types as shown by the output "ok". In the web worker, the string and ArrayBuffer pass with "ok" but the Uint8Array fails with the exception: "Data conversion error" nsresult: "0x80460001 (NS_ERROR_CANNOT_CONVERT_DATA)". Expected results: As the main thread succeeds for all three data types, the web worker should have succeeded for the types as well.
This is a problem in the variant handling. Attempting to turn the variant into a string is failing for some reason.
Status: UNCONFIRMED → NEW
Ever confirmed: true
XPCVariant doesn't handle TypedArrays. It ends up creating an XPCWrappedJS for them. It does have code to handle regular Arrays though. Should this be something we can expect XPConnect to handle?
(In reply to Kyle Huey [:khuey] (email@example.com) from comment #7) > XPCVariant doesn't handle TypedArrays. It ends up creating an XPCWrappedJS > for them. It does have code to handle regular Arrays though. Should this > be something we can expect XPConnect to handle? We could add support yes, though I doubt that teaching XPConnect how to convert a TypedArray into an XPCOM array (which is what adding support in XPCVariant would mean) is actually what we want here. We just want to treat it as a jsval, which nsIVariant doesn't do. Shouldn't SendRunnable::MainThreadRun create the appropriate RequestBody directly rather than using the nsIVariant stuff?
(In reply to Bobby Holley (:bholley) from comment #8) > Shouldn't SendRunnable::MainThreadRun create the appropriate RequestBody > directly rather than using the nsIVariant stuff? Yeah. I was asking about the XPConnect stuff mostly for completeness.
Assignee: nobody → khuey
Assignee: nobody → shuang
Assignee: shuang → nobody
This will be resolved by one of the patches pending to land in bug 792808.
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → DUPLICATE
Duplicate of bug: 792808
Marion, the cleanup in bug 792808 doesn't seem like it's really going to land anytime. Should we really block this web compat issue on that cleanup? Seems like we should reopen and fix this on its own terms, unless we're going to push bug 792808 over the line.
You raise a good point.
Status: RESOLVED → REOPENED
Priority: -- → P3
Resolution: DUPLICATE → ---
bz, this is safe to close as a dupe of bug 792808 (now that it has landed), right?
Assuming the testcases here are fixed and we have wpt coverage for them, yes.
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/01cbcad8bb67 update WPTs for XHR sends to also test with workers; r=annevk
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/15897 for changes under testing/web-platform/tests
You need to log in before you can comment on or make changes to this bug.