Loading screen for non-local and redirected content #727
Labels
effort/days
Estimated to take multiple days, but less than a week
exp/expert
Having worked on the specific codebase is important
help wanted
Seeking public contribution on this issue
kind/enhancement
A net-new feature or improvement to an existing feature
P1
High: Likely tackled by core team if no one steps up
status/ready
Ready to be worked
topic/design-front-end
Front-end implementation of UX/UI work
topic/design-ux
UX strategy, research, not solely visual design
topic/design-visual
Visual design ONLY, not part of a larger UX effort
Milestone
Important!
The solution implemented under this issue should be implemented with identical UX for WebUI, too: see issue ipfs/ipfs-webui#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 #710
The text was updated successfully, but these errors were encountered: