Custom protocol handlers do not work with first request on an empty browser session

[lidel]

TL;DR: just read #33 (comment)

---

I noticed that protocol handlers (ipfs:// etc) do not work under FF 44.

I thought it is related to #28 and this error from lib/child-main.js:

console.error: 
  Message: Module `@test/options` is not found at resource://gre/modules/commonjs/@test/options.js
  Stack:
    @resource://gre/modules/commonjs/sdk/test/options.js:10:17
@resource://gre/modules/commonjs/sdk/addon/window.js:15:17
@resource://gre/modules/commonjs/sdk/net/xhr.js:12:24
@resource://gre/modules/commonjs/sdk/request.js:17:56
@resource://ipfs-firefox-addon-at-lidel-dot-org/lib/gateways.js:41:17
@resource://ipfs-firefox-addon-at-lidel-dot-org/lib/protocols.js:8:10
@resource://ipfs-firefox-addon-at-lidel-dot-org/lib/child-main.js:3:15
@resource://gre/modules/commonjs/sdk/remote/child.js:81:3
emitOnObject@resource://gre/modules/commonjs/sdk/event/core.js:112:9
emit@resource://gre/modules/commonjs/sdk/event/core.js:89:38
messageReceived@resource://gre/modules/commonjs/sdk/remote/child.js:67:37

BUT:

I reverted to v1.3.1 and the same code does not work with unsigned add-on under Developer's FF 44, but does work with signed one and Official FF 42 (the one from Mozilla addon store). It also works fine with unsigned add-on and older FF 40.

I see three options:

• there is no bug, there is something wrong with my local setup
• custom protocol handlers do not work / require some additional code in FF > 42
• custom protocol handlers do not work when extension is unsigned

I would appreciate if someone try to replicate this issue by running against specific Firefox versions:

jpm -b /path/to/firefox-45.0a2/firefox run

and checking if ipfs://QmTAsnXoWmLZQEpvyZscrReFzqxP3pvULfGVgpJuayrp1w redirects to local gateway (for me, it redirects to Google search instead).

[the8472]

are you testing with e10s on or off?

[lidel]

Firefox Developer Edition 45 in about:support shows Multiprocess Windows 1/1 (default: true)

[lidel]

Loose idea: IPFS Gateways are de-facto web apps, so perhaps we should just move to External Protocol Handlers?

It should be easier to maintain and test, at least until WebExtensions provide all required APIs.

[the8472]

31abddd + nightly

e10s on: works
e10s off: works

31abddd + dev edition

e10s off: works
e10s on: works

1.3.1 + dev edition

e10s on: fails (opens google)
e10s off: works

-> this is why I did #28

1.3.1 + ff42

e10s off: works

---

So everything to works as expected for me.

[the8472]

About External Protocol Handlers, idk whether they provide the fine-grained control to interact with everything, i.e. loading any resources, overriding CORS, substituting stuff in the URL bar etc.

I'm currently cooking up a solution that can replace practically everything with fs:/ipfs/... and then do the proper handling internally.

[the8472]

note that I tested without redirect since I currently have no local gateway running (it fries my firewall). so I used rewriting the ipfs:// url to http://ips.io as success criterion.

[lidel]

Redirect should not impact this test (I get same result for ON and OFF).
That is really weird. Perhaps we just test different things?

Which exact versions you mean by 'nightly' (46.0a1?) and 'dev edition' (45.0a2)?
How do you enable/disable e10s?

I manually enter ipfs:QmTAsnXoWmLZQEpvyZscrReFzqxP3pvULfGVgpJuayrp1w in the address bar and pres Enter -- are you doing the same?

[the8472]

dev edition: Firefox 45.0a2 20151220004007
nightly: Firefox 46.0a1 20151219030215

i toggle e10s in about:preferences "enable multi-process firefox"

and yes, I paste the link into the url bar and press enter.

That is really weird. Perhaps we just test different things?

possible, i'm not using jpm run, I do extension auto installer/jpm post to an existing profile.

[the8472]

@resource://gre/modules/commonjs/sdk/request.js:17:56
@resource://ipfs-firefox-addon-at-lidel-dot-org/lib/gateways.js:41:17

I don't see anything on gateways.js:41 that would require sdk/request

Maybe you have a modified file locally?

[the8472]

Ah, c48470a introduces that, i.e. it's caused by #30

The problem is that it uses a module that should not be used in the client process

[the8472]

pinning logic probably should be moved into a separate module.

[lidel]

Yup, moving it to ./lib/pin.js fixed console.error from my first comment. Thanks!

As for the problem with protocol handlers, I finally managed to understand why it works for you and not for me: on a new browser session, only the first attempt fails.

I use the same dev edition as you, but run it via jpm -b ./ventor/firefox-45.0a2/firefox run

When browser starts, I enter ipfs:hash and it redirects me to Google.
But if I open any regular page first (eg. http://google.com) and then enter ipfs:hash. it works as expected. It even works fine if I enter it twice (first one redirects to Google, but second works as expected).

I think we have a lazy eval somewhere and that is why first attempt fails.

[lidel]

Closing as it is no longer relevant:
"native fs: mode" is no longer possible due to missing WebExtension API.

See #164 for more details