458320 - Workers: Support synchronous events from within XHR methods

Status: RESOLVED FIXED

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

Description

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Attachment: Patch, v1

Some method calls (like Abort) cause events to be generated that, according to spec, should run before returning from the method.

Comment 1

[Anne (:annevk)]

Well, they should run immediately after the method is returned.

x = 1
client.abort()
x = 2

While the events are processed x should be 1, basically. I should really update XMLHttpRequest and XMLHttpRequest Level 2 to be described in terms of the "event loop" as defined by HTML5. I haven't had time to do that yet though.

Comment 2

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

That is not true in the mozilla implementation. We don't fire them all at the end, they fire at various points during the execution of the method.

This matters in what the state of the XHR object is when the event fires. For example when the Abort method is called we do the following (among other things)

1. Set readystate to 4
2. Fire readystatechange
3. Set readystate to 0
4. return

This means that the readystatechange event handler sees readystate 4, whereas when the function returns the readystate is 0.

Not sure if this is different from what the spec states though.

Comment 3

[Johnny Stenback (:jst)]

Comment on attachment 341548 [details] [diff] [review]
Patch, v1

+  RUN_PROXIED_FUNCTION(GetAllResponseHeaders, (this, &queue, _retval));

The &queue argument is a bit out there :). Maybe you could make the macro do that internally by making the runnable hold that pointer as a member (and |this| too, maybe) rather than having to pass that in all the time?

Separate bug material, probably.

r+sr=jst

Comment 4

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Fixed.