Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Loading screen for non-local and redirected content #727

Open
lidel opened this issue Jun 4, 2019 · 1 comment
Open

Loading screen for non-local and redirected content #727

lidel opened this issue Jun 4, 2019 · 1 comment
Assignees
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

Comments

@lidel
Copy link
Member

lidel commented Jun 4, 2019

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:

  • 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.

showing what is happening

cc #710

@lidel lidel added the UX label Jun 4, 2019
@lidel lidel changed the title Display loading screen for non-local content Display loading screen Dec 21, 2019
@lidel lidel changed the title Display loading screen Loading screen for non-local and redirected content Dec 21, 2019
@lidel lidel added the topic/design-ux UX strategy, research, not solely visual design label Dec 21, 2019
@jessicaschilling jessicaschilling added topic/design-visual Visual design ONLY, not part of a larger UX effort and removed UX labels Mar 30, 2020
@jessicaschilling jessicaschilling added exp/intermediate Prior experience is likely helpful effort/days Estimated to take multiple days, but less than a week help wanted Seeking public contribution on this issue kind/bug A bug in existing code (including security flaws) P1 High: Likely tackled by core team if no one steps up status/ready Ready to be worked labels Apr 8, 2020
@lidel lidel mentioned this issue Jun 5, 2020
@lidel lidel added exp/expert Having worked on the specific codebase is important kind/enhancement A net-new feature or improvement to an existing feature P2 Medium: Good to have, but can wait until someone steps up topic/design-front-end Front-end implementation of UX/UI work and removed P1 High: Likely tackled by core team if no one steps up exp/intermediate Prior experience is likely helpful kind/bug A bug in existing code (including security flaws) labels Jun 5, 2020
@rafaelramalho19
Copy link

Relevant HTML for the loading indicator: https://ipfs.io/ipfs/QmPc2hMUgyUisvx2VyzLB4C3A17S1QUUUa6NQ6jMmdM8Jw?filename=loader.html

@lidel lidel modified the milestones: v2.16, v2.17 Sep 9, 2020
@lidel lidel modified the milestones: v2.17, v2.18 Jan 11, 2021
@galargh galargh moved this to To do in IPFS-GUI (PL EngRes) Sep 22, 2022
@lidel lidel modified the milestones: v2.18, v2.21 Nov 22, 2022
@lidel lidel added P1 High: Likely tackled by core team if no one steps up and removed P2 Medium: Good to have, but can wait until someone steps up labels Apr 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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
Projects
No open projects
Status: Needs Grooming
Development

No branches or pull requests

3 participants