Improve UI when user tries to open missing file

[lidel]

(found this while working on unbundling webui from companion)

"Not Found" error for Files tab could be better :-)

1. Open http://127.0.0.1:8080/ipfs/QmXc9raDM1M5G5fpBnVyQ71vR4gbnskwnB9iMEzBuLgvoZ/#/files/I_AM_NOT_HERE.jpg (or any other filename that is not present in your MFS)

2. See this odd state with no buttons and bogus error about adding:

This may happen if someone bookmarks or copies URL to another machine without pointing webui at the same IPFS node.

We should either display a meaningful message or just silently redirect to the nearest MFS root.

### Tasks
- [ ] Display meaningful error message when file cannot be loaded
- [ ] Allow user to navigate back to paret files page easily

[olizilla]

I think a 404-like page, tailoured for the files page would be useful. An individual user may bookmark a location and then move things around.

TODO:

• [ ] Catch ipfs error where mfs file path is missing
• [ ] Offer an action to navigate back to the MFS root.
• [ ] Show a helpful message that explains what happened.

The path /example/cats.png doesn't exist in your local IPFS repository. Did you bookmark it or follow a link that someone else sent you?

Bonus points

what if we include the CID info in the url? This would allow us to:

• navigate the user to the new path if it exists in the repo (we'd have to walk all of MFS to figure out the new path, if it exists, but we could show the content straight away)
• Try and fetch the content where a user shares the location from the url bar.

[hklcf]

GET https://webui.ipfs.io/locales/zh-TW/welcome.json 404 GET https://webui.ipfs.io/locales/zh-TW/status.json 404 GET https://webui.ipfs.io/locales/zh-TW/explore.json 404 GET https://webui.ipfs.io/locales/zh/files.json 404 GET https://webui.ipfs.io/locales/zh-TW/notify.json 404

[lidel]

@hklcf those errors are not related to this issue: those are just missing translation for zh-TW locale. If you want to contribute translations, join project at https://www.transifex.com/ipfs/public/

---

@jessicaschilling thoughts on improving the 404 "Not found" state of Files screen?

It should be more prominent, and also more explicit:

• should not look like "ok" state, should be red and error-ish
• should show what resource was not found (with full content path)

As a data point, currentversion of "404" screen from a user report copied from https://github.com/ipfs/go-ipfs/issues/7604:

Hello, at first my ipfs can import, but after some uploads it turns to /404 and no import button anymore, anyone experiencing the problem?

Right now user is unable to tell what went wrong and why "404" is displayed. If a full content path (either MFS, /ipfs/ or /ipns that was not found was displayed, then it would be much easier to self-service.

[jessicaschilling]

For reference, current state of 404 on master branch (updated first comment in this issue with this, too):

[jessicaschilling]

@lidel Rough first pass at what this might look like if we used the same visual language as the "not connected" errors that will ship in 2.11. Suggesting we use those visuals for consistency, but would appreciate advice for improving the text.

[lidel]

@rafaelramalho19 raised the problem of having two types of "not found" errors:

1. opening /files/not/in/mfs or /ipfs/<cid>/nope (a path that does not exist in parent directory)
2. opening /invalid-route that is not supported by webui

I believe if we implement separate screens for each, then (1) should have super breadcrumbs, so it's easy for user to go up in MFS until an existing item works. For additional :sparkles: each "missing" crumb would be in red.

This may be additional work, so if its easier to do a quick fix by showing the same page for (1) and (2), I would do that (just a plain error without Files-specific UI).

[jessicaschilling]

@lidel That all makes sense - are you OK with the proposed text in the mockup? If so I think this is ready to build.

[rafaelramalho19]

Having a separate page handler for both the errors is the simplest and cleanest solution, here's my points:

Pros:

• 💚 We don't need to hack the files state (FILES_FINISHED, FILES_STARTED actions + adding flags that show/hide errors)
• 💚 The error handling is separated from the normal flow, not polluting the main workflow

Cons:

• 💔 Breadcrumbs needs to be replicated in the error page and could lead to desync between features/bug fixing in breadcrumbs

[jessicaschilling]

If we remove the Files-specific UI elements per https://github.com/ipfs-shipyard/ipfs-webui/issues/961#issuecomment-694930636 (image), then we don't include breadcrumbs at all.

[lidel]

If breadcrumbs can't be reused easily, then I'd go with Jessica's sugegstion from the comment above and remove files-specific UI.

[jessicaschilling]

@rafaelramalho19 Text follows, including edits discussed out-of-band:

IPFS can't find this item

These common troubleshooting steps might help:

• Are there typos in the path you entered?
• Was the file move, renamed, or deleted?
• Did you copy a URL or bookmark from another computer? If so, you'll need to {link to Peers screen}connect to that computer's node{/link>}.

{button}Back to Files{/button}

[wuniversales]

I do not know if it is related to this but on my website I have a problem of that style. https://buscatope.eu.org/ My website works with ipfs, but if I load an address that doesn't exist it returns this ... https://buscatope.eu.org/invented Shouldn't it load the 404 file? https://buscatope.eu.org/404.html

[lidel]

@wuniversales this is unrelated, but you should use ipfs-404.html for IPFS gateway to pick it up as your 404 page, as noted in release notes

[SgtPooki]

Test dir CID with 10k images: bafybeiggvykl7skb2ndlmacg2k5modvudocffxjesexlod2pfvg5yhwrqm fast dir listing (skips size resolution: ipfs ls -s --size=false --resolve-type=false $CID

[ef3n9r98]

@lidel @olizilla same for this one - would you pay a dev to fix it?