IPFS Companion should improve experience of loading CID in main_frame, namely situations when:
waiting for content routing/discovery
redirecting to a different (local, public) gateway for the first time
this includes recoveringfrom dead HTTP links
Current UX
Slow content routing
An empty, white page displayed until bytes start arriving from IPFS.
Fast for local content, but slow for remote, especially if content is only at a single node, no peer hints (#722) are available, and we need to query DHT for providers.
Redirect
No warning, no info what is happening, we just redirect. This is a problem when content takes some time to be found. User is redirected and stares at a white screen. Browser vendors often don't update address in location bar until first byte starts arriving, which looks like "IPFS Companion broke the website".
Proposed Change
Detect IPFS request for root document (request.type === 'main_frame') and display educational "loading screen" until data is available in local datastore of IPFS node. It should inform user that location of data is being discovered using [methods].
We should do similar thing when redirecting DNSLink website or gateway for the first time: tell user what is about to happen, give option to skip the redirect info in the future for this DNSLink website/gateway (see uBlock below).
To make it easier to test, it should be an opt-out Preference.
Prior Art
browser.tabs.update
I've been thinking about use of DataURLs (blocked by this bug), but received suggestion to reuse a technique from uBlockOrigin:
Have you entertained just opening an extension page instead of redirecting outright?
That is, block the network request and instead load your extension page using browser.tabs.update(...) with whatever query parameters needed to
configure the rendering of the page.
An example of such technique is used in uBlock Origin to warn a user before loading a navigated-to web page.
Important!
The solution implemented under this issue should be implemented with identical UX for WebUI, too: see issue https://github.com/ipfs-shipyard/ipfs-webui/issues/991.
IPFS Companion should improve experience of loading CID in
main_frame
, namely situations when:Current UX
Slow content routing
An empty, white page displayed until bytes start arriving from IPFS.
Fast for local content, but slow for remote, especially if content is only at a single node, no peer hints (#722) are available, and we need to query DHT for providers.
Redirect
No warning, no info what is happening, we just redirect. This is a problem when content takes some time to be found. User is redirected and stares at a white screen. Browser vendors often don't update address in location bar until first byte starts arriving, which looks like "IPFS Companion broke the website".
Proposed Change
Detect IPFS request for root document (
request.type === 'main_frame'
) and display educational "loading screen" until data is available in local datastore of IPFS node. It should inform user that location of data is being discovered using [methods].We should do similar thing when redirecting DNSLink website or gateway for the first time: tell user what is about to happen, give option to skip the redirect info in the future for this DNSLink website/gateway (see uBlock below).
To make it easier to test, it should be an opt-out Preference.
Prior Art
browser.tabs.update
I've been thinking about use of DataURLs (blocked by this bug), but received suggestion to reuse a technique from uBlockOrigin:
showing what is happening
cc https://github.com/ipfs-shipyard/ipfs-companion/issues/710