Open Bug 1168781 Opened 9 years ago Updated 1 year ago

WebCrypto callbacks occur during synchronous XHR

Categories

(Core :: DOM: Core & HTML, defect, P3)

59 Branch
defect

Tracking

()

UNCONFIRMED

People

(Reporter: nicholas, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0
Build ID: 20150511091651

Steps to reproduce:

With synchronous XHR requests, the main JS thread is blocked, and other callbacks do not occur while execution is blocking inside the `send()` method.

Unfortunately, WebCrypto promises are resolved during blocking XHR requests, rather than deferred to the next run of the event loop after the XHR completes.

To reproduce, run the following in a console:

window.testRequest = function() { var req = new XMLHttpRequest(); req.open("GET", "http://start.fedoraproject.org/", false); req.onload = function() { console.log("request loaded") }; return req }

crypto.subtle.generateKey({name: "AES-GCM", length: 128}, false, ["encrypt"]).then(function(rv) { window.aesKey = rv; })

window.testEnc = function() { crypto.subtle.encrypt({name: "AES-GCM", iv: new Uint8Array(16), tagLength: 128}, window.aesKey, new Uint8Array([1,2,3])).then(function(rv) { console.log("got encryption result: "+rv) });}

// Key line: kick off WebCrypto and XHR, WebCrypto callback occurs *inside* send
window.testEnc(); window.testRequest().send(); console.log("send done")

// For comparison: timers *are* deferred during XHR send
setTimeout(function(){ console.log("timer fired") }, 0); window.testRequest().send(); console.log("send done")


Actual results:

We see the following in the console:

"got encryption result: [object ArrayBuffer]"
"request loaded"
"send done"
"request loaded"
"send done"
"timer fired"


Expected results:

Should have seen the following in the console, as occurs in Chrome:

"request loaded"
"send done"
"got encryption result: [object ArrayBuffer]"
"request loaded"
"send done"
"timer fired"
This is a problem with Promises generally, as shown by the following test:

window.testPromise = function() { (new Promise()).then(function() { console.log("Promise resolved") }) }
window.testPromise(); window.testRequest().send(); console.log("send done")

I realise that synchronous XHR is not a high priority web platform feature (deprecated!), and we're not actually using it in production code, but as part of a test harness for some emscripten-generated code. Regardless of how much we dislike synchronous XHR, it probably should interact with Promises in the same way as Chrome.
Hi,

Before change the status of this bug and assigned the component please take a look at this bug 1170760 and also you can try to test this with Nightly 46.0a1. Download it from here: https://nightly.mozilla.org/
Flags: needinfo?(nicholas)
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Flags: needinfo?(nicholas)
Resolution: --- → INCOMPLETE
Hi,

It took me ages to remember about this... but it's still not fixed!

Retested on Firefox 59, and the same repro steps above illustrate the issue.

The behaviour remains different from Chrome: WebCrypto promises can resolve while blocking XHR calls are in progress.
Status: RESOLVED → UNCONFIRMED
Resolution: INCOMPLETE → ---
Version: 38 Branch → 59 Branch
Component: Untriaged → DOM: Security
Product: Firefox → Core
Tim, this one just got moved into dom:security, can you weigh in and triage please?
Flags: needinfo?(ttaubert)
I don't know that sync XHR makes any guarantees about tasks that are executed in parallel. Anyway, this shouldn't be here. Someone that knows more about the details of Promises can probably help to figure out whether this is something that should be fixed.
Component: DOM: Security → DOM
Flags: needinfo?(ttaubert)
Our implementation of sync XHR on main thread spins event loop. Sync XHR on the main thread is of course deprecated in the spec level too, so there aren't plans to change that.
We do suppress user input and pause timers and such during sync XHR.
Priority: -- → P3
Component: DOM → DOM: Core & HTML
Severity: normal → S3

Website https://cryptoday.com/en is currently not visible to the mozilla browser. Is it the same error?

You need to log in before you can comment on or make changes to this bug.