IPFS Desktop/WebUI stop loading when turn wifi off

[momack2]

• OS: macOS
• Version of IPFS Desktop [e.g. 0.20.0]

Describe the bug
When I try to load the IPFS Desktop webui when I turn wifi off, the files I have stored on my local IPFS node no longer load (but load fine again when wifi is re-enabled)

• I also briefly saw the "total files" go to -1 B, instead of the correct 17GiB listed here.

To Reproduce
Steps to reproduce the behavior:

1. Go to IPFS Desktop and add some local data
2. Click on files and browse the data
3. Turn off wifi - continue trying to browse the data
4. screen might intermittently go all white, or stop loading files and show the loading screen forever

Expected behavior
I should be able to fully browse my local IPFS files even when I'm offline

[whizzzkid]

Thanks for submitting this issue @momack2, I tried reproducing the issue but that does not happen, I am able to browse the content of my local node just as I would when connected to wifi. I wonder if this issue related to a specific file or size of the storage.

To be able to reproduce this, can you please:

• Confirm the macOS version you're on.
• Confirm the ipfs-desktop version you're using.
• Also, after you encounter the issue, can you please attach additional log-files and configs that can be found here

Thanks!

[github-actions]

Oops, seems like we needed more information for this issue, please comment with more details or this issue will be closed in 7 days.

[SgtPooki]

There are some cases where data in MFS is a shallow reference (the bottom of wikipedia mirror wiki references how to do this).

There are other issues in this repo that have discussed whether we should fully resolve CIDSs locally or not, and that we should provide a UI indicator showing users whether content is actually downloaded or not.

Self Todo: update this comment with appropriate links Info provided in #2492 (comment)

[github-actions]

Oops, seems like we needed more information for this issue, please comment with more details or this issue will be closed in 7 days.

[github-actions]

This issue was closed because it is missing author input.

[SgtPooki]

I was unable to reproduce this just by disabling wifi. I was able to reproduce this by following the steps in ipfs/ipfs-webui#1691

Steps I followed:

1. Import XKCD archive (CID containing more than a single block) in IPFS-desktop using CID QmdmQXB2mzChmMeKY47C43LxUdg1NDJ5MWcKMKxDu7RgQm
2. Note that the file is listed in the Files screen of IPFS-desktop
3. Shut off wifi
4. Click the QmdmQXB2mzChmMeKY47C43LxUdg1NDJ5MWcKMKxDu7RgQm entry in the files screen
5. Note that the files screen never finishes loading

Closing this in favor of ipfs/ipfs-webui#1691 & ipfs/ipfs-webui#961

Other related issues:

• feat: improve repo size labels and explanation ipfs-webui#1248

[lidel]

@SgtPooki another thing one could try here is to check if macOS wifi status is reflected on navigator.onLine and/or addEventListener APIs.

If so, webui could register listener to online/offline state change, and modify behavior around items which are not 100% local (e.g. grey them out, set shorter timeout + more meaningful message etc).

Checking what % of data is local could be expensive, but the result can be cached per CID until the online/offline status changes.

> ipfs files stat --with-local /ipfs/QmTyS43Vbwht5LE8bvPP4nZmWYyc7iafweD6zJhJhGmAJa
QmTyS43Vbwht5LE8bvPP4nZmWYyc7iafweD6zJhJhGmAJa
Size: 0
CumulativeSize: 27932070
ChildBlocks: 29
Type: directory
Local: 980 kB of 28 MB (3.51%)

[whizzzkid]

@lidel that sounds like a 🩹 band-aid fix, I wonder if this should be handled by kubo, i.e. the client (in this case webui) should not be figuring this out. If the network is an issue, the status should be reported as such?

[lidel]

Maybe? But doing this desktop-specific thing in Kubo (which is used outside of desktop use cases too) is tricky.

From the Kubo perspective, there are other network interfaces than Wifi still working (loopback, VPNs, overlay networks). User could be running more than one node on the same machine, and they would still work and exchange data with each other. Kubo would need to maintain some code that tests/decides what is "online" and what is "offline", and if this is slightly different for macOS and Windows, we run into a lot of maintenance cost for something that is already implemented and tested by web browser.

What Kubo could do, tho, is to do very simple thing: detect when request for new data (that is not cached locally) occurs when no peers are available, and return some canonical error instead of waiting for new peers to appear.

[SgtPooki]

@lidel this issue is still closed, because a lot of the work for resolving this will be in ipfs-webui, but I created ipfs/ipfs-webui#2135 to consolidate work for addressing all of the issues affecting the experience that caused the filing of this issue.

let's continue any further discussion there.