I assume we are talking about "native" fs: mode.
To clarify, does it happen only when local gateway is used?

Update @ 2017-02-21: see #87 (comment)

Yes it does.

Also in this case using fs:/ breaks angular. I will open new issue about maybe meta tag for requesting for not being under fs:/.

Quick repro:

• open fs:/ipns/ipfs.io/ and hover over "Examples" link.
  Note that
  <a href="./docs/examples">Examples</a>
  points to fs:/ipns/ipfs.io/docs/examples
• click on it
• http://127.0.0.1:8080/ipns/ipfs.io/docs/examples/ is loaded

In short, there is a bug – directory paths must end with / :

• fs:/ipns/ipfs.io/docs/examples redirects to http:
• fs:/ipns/ipfs.io/docs/examples/ stays in fs:

Turns out the gateway normalizes root URIs. If it does not end with /, a redirect is returned:

Due to the way our current protocol handler works redirect sent by gateway breaks out from fs: namespace.

Sadly, we don't know if URL points to a directory or a file.
For example, fs:/ipns/ipfs.io/foo.bar can be a file (no redirect)
or a directory (redirect to fs:/ipns/ipfs.io/foo.bar/).

To solve this, we need to handle unexpected HTTP 302 from gateway somehow.

At first I thought maybe this old snippet by @the8472 will solve it, but the error was present in that code base too.

I did some diagnostics of channel.loadFlags in http-on-modify-request when channel.originalURI.scheme === 'fs'. I used ipfs.git.sexy because it does not fetch any additional artifacts.

Opening fs:/ipns/ipfs.git.sexy/ works as expected, and only one http-on-modify-request is logged:

console.info: newChannel routed to HTTP gateway:  http://127.0.0.1:8080/ipns/ipfs.git.sexy/
console.log: ipfs-firefox-addon:  -----> uri:http://127.0.0.1:8080/ipns/ipfs.git.sexy/, origUri: fs:/ipns/ipfs.git.sexy/
console.log: ipfs-firefox-addon: channel.loadFlags:  10011010010000000000000000
console.log: ipfs-firefox-addon: LOAD_REPLACE   :  false

Opening fs:/ipns/ipfs.git.sexy yields two requests (second being the redirect target):

console.info: newChannel routed to HTTP gateway:  http://127.0.0.1:8080/ipns/ipfs.git.sexy
console.log: ipfs-firefox-addon:  -----> uri:http://127.0.0.1:8080/ipns/ipfs.git.sexy, origUri: fs:/ipns/ipfs.git.sexy
console.log: ipfs-firefox-addon: channel.loadFlags:  10011010010000000000000000
console.log: ipfs-firefox-addon: LOAD_REPLACE   :  false
console.log: ipfs-firefox-addon:  -----> uri:http://127.0.0.1:8080/ipns/ipfs.git.sexy/, origUri: fs:/ipns/ipfs.git.sexy
console.log: ipfs-firefox-addon: channel.loadFlags:  11011010000000000000000
console.log: ipfs-firefox-addon: LOAD_REPLACE   :  true

I tried to set the same loadFlags for the second request but it did not help -- flags were the same but final URL was http: (http-on-modify-request may be too late).

I'll look into this in spare time, but if anyone has any idea, feedback is appreciated.

There is an upstream ticket about this behavior at ipfs/in-web-browsers#8

Closing as it is no longer relevant.

Sadly "native fs: mode" is no longer possible due to missing WebExtension API.
Until such API is created, only basic handler will be present and it will always default to "http" in address bar.

See #164 for more details