Remove XMLHttpRequest from ServiceWorkerGlobalScope about xhr HOT 18 CLOSED

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?

from xhr.

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

from xhr.

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.

from xhr.

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

from xhr.

Sounds good

from xhr.

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

from xhr.

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?

from xhr.

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?

from xhr.

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.

from xhr.

Ping!

from xhr.

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

from xhr.

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

from xhr.

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.

from xhr.

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

from xhr.

Thank you folks!

from xhr.

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

from xhr.

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!

from xhr.

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

from xhr.