Remove XMLHttpRequest from ServiceWorkerGlobalScope

[foolip]

I noticed a discrepancy between the spec IDL and Blink, that comes down to this bug:
https://code.google.com/p/chromium/issues/detail?id=395931

If this makes sense, I suggest replacing Exposed=(Window,Worker) with Exposed=(Window,DedicatedWorker,SharedWorker) in the spec too.

CC @coonsta and @jakearchibald

[annevk]

So the idea is to not expose XMLHttpRequest in new contexts in order to encourage usage of fetch()... Seems okay I guess.

[tyoshino]

Sounds good

[foolip]

I was half expecting push back on this. Won't it be annoying that you can't reuse some existing library code because it uses XHR? From https://code.google.com/p/chromium/issues/detail?id=395931 it sounds like part of the motivation was to get rid of the sync mode, but is that a bigger problem for service workers than other kinds of workers?

[tyoshino]

The pain in implementation would be small if we're to keep only async XHR, I guess. Not sure if there're works such that:

• it makes sense to get the works done in SW, and
• (part of) the works don't require the Fetch API's functionality, and
• complicated so that use of library makes sense

[annevk]

I was actually expecting us to simply forbid synchronous XMLHttpRequest in SW, but leave it working otherwise. However, since fetch() shipped relatively quickly I guess I do not really care either way. If there is some kind of win in not exposing it (or maybe there is one down the line) I would be cool with that.

What about ProgressEvent?

[foolip]

Actually ProgressEvent is exposed only on Window in Blink, but I believe that's an oversight. I think the spec should expose all the interfaces in the same contexts and Blink should change.

To me, throwing InvalidAccessError when sync XHR is attempted in any non-whitelisted context sounds pretty good. Which kinds of workers already depend on sync XHR I don't know, but we could measure it.

@coonsta and @jakearchibald, thoughts?

[dominiccooney]

I'm sorry that we didn't file a spec bug and link to it from that patch; we should always do that. @slightlyoff is a better person to ask about exposing XHR; @kinu is a better person to ask for implementer feedback from Chromium/Blink.

[annevk]

Ping!

[foolip]

Ping again @coonsta, what do you think we should do here?

[kinu]

Only shipping async XHR in SW makes sense to me and I don't feel it's too difficult to implement in Chromium/Blink. I'm not really sure if exposing XHR is still awaited since SW was shipped without XHR sometime ago and now we have fetch, but having it may make it easier to use JS libraries in SW I guess.
/cc @mattto

[mfalken]

I haven't heard users complain about lack of XHR in Chrome's SW implementation yet, so maybe there's no need to add async XHR now. We can always add it later if needed.

[foolip]

OK, so I guess let's change the spec instead.

[annevk]

Thank you folks!

[vandys]

With cancellation and timeouts (still) missing from fetch, would it be appropriate to revisit
access to XMLHttpRequest in Service Workers?

[wanderview]

With cancellation and timeouts (still) missing from fetch, would it be appropriate to revisit
access to XMLHttpRequest in Service Workers?

Cancellation is making progress. We have experimental support for it in FF55 if you set dom.fetchController.enabled to true.

https://twitter.com/wanderview/status/844924163634679808

[CyrilCommando]

Let me get this straight - The option to use XHR in service workers was removed because one guy thinks it's "redundant", and is partial to fetch?

Options be damned!

[annevk]

Well, we also want folks to move to fetch(). That started in 2015 and is especially true today.

[vandys]

Well, we also want folks to move to fetch(). That started in 2015 and is especially true today.

fetch() eventually added an abort, but you still have to cobble together your own timeout. And the abort is quite a bit clunkier than what it takes for an XHR. I hope in the future you'll make sure your API's are a superset (and preferably cleaner) before forcing the sunset of old API's.