678070 - Run the same XHR tests on Workers and main thread?

Status: NEW

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

Description

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Bug 678057 is fairly annoying because we removed a spec'd API from Worker XHR while leaving it for main-thread XHR.  We also landed proposed binary XHR extensions for main-thread only without a Worker impl.  This is quite unkind to web developers, although I 100% understand why our Worker XHR impl is difficult to maintain.

Can we all agree at least that having the same XHR API across worker/main thread is a goal?  That's what the spec says we should have, at least.

As a first step, how about we move to a system where we run the exact same XHR tests on both Workers and main thread, that is, literally the same code.  That makes adding tests easier, and would have brought things like bug 678057 to attention (test running on Worker would have failed).

There are two remaining issues
 (1) bent says there are known bugs in the worker code with race conditions in event delivery, so lots of tests we run on the main thread would fail on Workers right now.  I understand why these things can happen with our current, ah, suboptimal architecture.   My concern is that, either (i) the tests that would fail are overly corner-case-y, testing things that aren't really that important for developers, or (ii) they *are* testing important things, and it's just not possible for us to implement a spec-compliant Worker XHR.  That would be bad, and a big problem we should start fixing.

 (2) Should we be adding new features to main thread without a worker impl?  This is the binary XHR issue.  From the web-dev side of things, for pdf.js, having binary XHR available was fantastic, but not having it on Workers was a source of major consternation and will likely increase code complexity.  Maybe the decision of whether to block on a Worker impl of new feature X depends on X, but if the tests added for X failed from the beginning on Workers, there would be more motivation to add the Worker backend.  But also, to be fair, a higher barrier to implementing X in the first place.

What are we going to do with streaming XHR?

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

We can't run the same tests, since workers don't have DOM, so
xhr.responseBody is always null.

But in other cases, yes, we should try to get worker XHR to work like
normal XHR, and to ensure that, the tests should be the same.

Comment 2

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.