Doesn't work inside a service-worker on Firefox

[koalalorenzo]

By playing around with js-ipfs-api inside a service worker, I have noticed that it works perfectly on Safari and Chrome, but apparently not on Firefox.

The error reported is related to the usage of XMLHTTPRequest.

I guess this is the cause: https://www.fxsitecompat.com/en-CA/docs/2015/xmlhttprequest-is-no-longer-available-in-service-workers/

Any guess how to solve/fix this to support also Firefox service workers?

[vasco-santos]

That is correct, XMLHTTPRequest is not supported anymore on service workers.

Accordingly, XMLHTTPRequest needs to be changed and the fetch API seems like the best option.

We fixed a XMLHTTPRequest in js-ipfs js-ipfs#1478. Would you like to create a PR for solving this here?

[koalalorenzo]

I will try to find the time for it 👍

Should I update it for all the requests? I was diving a little and I found this line:
https://github.com/ipfs/js-ipfs-api/blob/231c4d78723d41152e6a695a5f171feae2274c19/src/utils/send-request.js#L174

That connects to:
https://github.com/ipfs/js-ipfs-api/blob/231c4d78723d41152e6a695a5f171feae2274c19/src/utils/request.js#L1-L12
https://github.com/ipfs/js-ipfs-api/blob/master/src/utils/request.js

I see from the code that there is a lot of dependency on how we are using this module. I guess I need to change that... but my bet is that would complicate a lot of things since changing it would mean to change the way we set up headers, the requests etc etc etc.

In any case can you guide a little bit me to find what would be the best solution? Maybe also @alanshaw can give me some suggestion a la planning 😃

[vasco-santos]

Nice research!

I believe that we should have fetch for every single request, since each api call should be accessible through a service worker as well.

Yes, I suppose it will not be an immediate and easy change, as you say, some of the request's building blocks have to be implemented according to the fetch API. Let's wait for @alanshaw input here.

[hugomrdias]

In the browser we use stream-http package that is suppose to use fetch if it's available we should report this problem to them

[shunkino]

HI @koalalorenzo, I think this is because ReadableStream() is disabled in Firefox by default.
This function should be available for stream-http to work as a fetch() mode.

Could you test your code after enabling ReadableStream() by procedure below?

https://developer.mozilla.org/en-US/docs/Web/API/ReadableStream

From version 57: this feature is behind the dom.streams.enabled preference (needs to be set to true) and the javascript.options.streams preference (needs to be set to true). To change preferences in Firefox, visit about:config.

[koalalorenzo]

The error that I am getting when I am doing a simple list of pinned elements is reporting a XMLHTTPRequest so I am not sure how much that is related to ReadableStream, but I could be wrong.

https://www.fxsitecompat.com/en-CA/docs/2015/xmlhttprequest-is-no-longer-available-in-service-workers/

[koalalorenzo]

Enabling ReadableStream on Firefox it doesn't fix the problem. I think it is more related to the code that I was reporting, but again I am not 100% sure.

[hugomrdias]

I'm looking into stream-http for other stuff I'll check this out.

[jhiesey]

@hugomrdias let me know if you need help with stream-http. I'm the maintainer of that module and also working for Protocol Labs.

[koalalorenzo]

Can anybody explain to me why it is stream-http the cause of this?

[shunkino]

@koalalorenzo
It's because js-ipfs-api uses stream-http as an alternative of http in browser environment.
https://github.com/ipfs/js-ipfs-api/blob/master/package.json#L11

[shunkino]

@koalalorenzo
Hi again, sorry for sending comments frequently. Thank you for testing my previous post. Sorry to hear that it didn't worked out for you. 😢

I just tested ServiceWorker inside Firefox and was able to call ipfs.pin.ls() from it. My environment: Firefox (Quantum 61.0.2 on MacOS). Only change I did is enabling ReadableStreaming()

This is the screenshot of my console.

Sorry for random logs, I was in hurry...

From the result, I think if stream-http run in the fetch mode, ipfs.pin.ls() functions can be called from ServiceWorker. Could you set break point here and check what mode stream-http is running in your Firefox?

https://github.com/jhiesey/stream-http/blob/718f5127ec970e91ea4c323c2491efdffb22a1c9/lib/request.js#L10

Hope this helps. 😄

[koalalorenzo]

Well, I can't ask the users to enable ReadableStreaming :(
@jhiesey maybe you can help here

[lidel]

FYSA Streaming API is very close to be enabled by default in Firefox:

[..] the only blocker (or at least the main one I know of) is bug 1385890 and Jason's working on it. Hoping to ship soon.
– [meta] enable streams API by default

cc ipfs/in-web-browsers#55

[alanshaw]

@koalalorenzo this should now be fixed in ipfs-api@25.0.0 by ipfs-inactive/js-ipfs-http-client#868 please open a new issue if the problem persists

[hugomrdias]

@alanshaw this is related to stream-http going xhr mode instead fetch mode when it doesn't detect web stream support, and sw doesn't have xhr. I'm gonna reopen and assign it to me.

[alanshaw]

argh, yes sorry, thanks @hugomrdias

[koalalorenzo]

Any update?

[lidel]

FYSA streams just got enabled in Firefox Nightly 👀 🎉 :

Refs.

• https://hg.mozilla.org/integration/autoland/rev/b3ccdaea275b
• https://bugzilla.mozilla.org/show_bug.cgi?id=1389628

[lidel]

aaaand Firefox 65 just landed in stable channel with support for ReadableStream 🎉

@koalalorenzo are you able to re-check with Firefox 65?

[koalalorenzo]

I am not able to test again as we decided to implement it in a different way in order to unlock what we were doing on Orion. Sorry :(

[whizzzkid]

js-ipfs is being deprecated in favor of Helia. You can follow the migration plan here #4336 and read the migration guide.

This issue has been resolved in Helia! if this does not address your concern please let us know by reopening this issue before 2023-06-05!