ts-odd
ts-odd copied to clipboard
Long or Infinite Spinner on Page Load
Summary
Problem
Under certain circumstances, the load time for WebNative initialization is very long. We've observed this take 80-350 seconds, or simply never load. A manual page refresh (regular, not hard refresh) resolves this issue.
After a manual refresh, typically things are very fast, which is great. The first load appears to be the issue.
Impact
Unable to load content; presented with a bare spinner in apps like Drive. End users are confused, frustrated, and report that the site is "broken". While it does work eventually (or with manual intervention), it's generally not sufficient for production use cases.
Solution
- Isolate the issue (libp2p/webnative bug/browser issue)
- Solve the issue
- Failing that, implement one or both of:
- On a timeout waiting for load, automatically start the loading process again
- Load IPFS lazily in the background, while grabbing first files / indexes over HTTP
Detail
This issues does not appear to happen with older versions of WebNative (e.g. quotes.fission.app), including being fine across devices with the older SDK. We have reports that others noticed this problem begin 4-6 weeks ago.
In all of these scenarios, we do not see the "🚀 Started IPFS node" message in the console, but it does seem to show consistently when the page loads. We always see either the "📓 DNSLink is newer" or "creating filesystem" messages when this problem occurs.
This doesn't happen every time, but I can replicate it ~80% of the time on my machine. Boris has also been able to replicate this without problem.
The scenarios that appear to create this issue are:
1. Sign In
Signing in to (e.g.) Drive, including signing out and back in.
2. Data Update
Updating data in a second app (e.g. Quotes), and refreshing another one (e.g. Drive) on the same or across devices.
To Reproduce Steps to reproduce the behavior:
New Account
- Go to drive.fission.codes
- Sign in
- Infinite or long spinner until manual intervention
Existing Account
Sign Out & In
- Go to drive.fission.codes
- Click on
sign out
- Navigate back to drive.fission.codes
- Sign back in
- Infinite or long spinner until manual intervention
New Data
- Go to drive.fission.codes
- In a separate tab, open quotes.fission.app
- Add a new quote
- Switch back to Drive, and refresh the page
- Infinite or long spinner until manual intervention
Expected behavior A clear and concise description of what you expected to happen.
Screenshots

Desktop (please complete the following information):
- OS: macOS 11.1 (Big Sur)
- Machine: MacBook Air (M1, 2020)
- Browser: Safari 14.0.2, Firefox 85
Smartphone (please complete the following information):
- Device: iPhone 11
- OS: iOS 14.3
- Browser: Safari

js-ipfs on iOS seems to, sometimes, want to try to connect to the insecure websocket instead of the secure one 🤔 Causing a connection error and crashing the js-ipfs boot. This seems to be on 127.0.0.1, which is weird as well.
@icidasset I saw this in desktop safari as well (both insecure & 127.0.0.1 attempt)
Potentially resolved by removing our node from the bootstrap list, and adding after startup. Waiting to see if this bears out. One report of it "feeling long so I refreshed" since, but I haven't been able to reproduce that yet.
Narrator: It did not solve it
...at least not on its own. We're trying a few other things we're trying with the IPFS cluster.