ipfs-desktop
ipfs-desktop copied to clipboard
ipfs
IPFS Desktop electron UI randomly breaks after visiting webUI in the browser
Describe the bug IPFS Desktop webUI keeps breaking - showing an all-white screen (while interacting with the IPFS node via http://127.0.0.1:5001/ipfs/bafybeihcyruaeza7uyjd6ugicbcrqumejf6uf353e5etdkhotqffwtguva/#/ works fine)
To Reproduce Steps to reproduce the behavior:
- Open IPFS Desktop and browse menus - everything working fine
- Also view desktop UI by visiting http://127.0.0.1:5001/ipfs/bafybeihcyruaeza7uyjd6ugicbcrqumejf6uf353e5etdkhotqffwtguva/#/
- Go to drop down IPFS Desktop menu
- Click on any of the status / files / etc pages
- See all white IPFS desktop electron app UI - with no contents
- Have to fully quit IPFS Desktop (not restart the node) to start working again
Expected behavior IPFS Desktop should never show a weird, white, empty screen
Screenshots
Desktop (please complete the following information):
- OS: mac
- Browser: chrome
- Version: 96.0.4664.93 (Official Build) (x86_64)
Note - I'm also having a problem with https://github.com/ipfs/ipfs-webui/issues/1880 -- so while I haven't changed any of my default IPFS config - this may be related?
I wasn't able to reproduce the error. Could you please try to reproduce it i your machine and check if there's errors in the Developers Console inside the Electron UI (Command + Option + I)?
yes - I do see a number of errors:
The locales issues seem to show up as soon as the application loads (and while it is operating correctly) -- but the two uncaught type errors seems to be related to the entire UI breaking
Error comes from edge/race condition case around doUpdateUrl (built in part of redux-bundler), but I suspect the underlying reason is the way we switch URL after clicking on menu item.
iirc when IPFS Desktop window is hidden, we switch to a /blank (BlankPage) to save CPU from rendering UI when not visible. Perhaps sometime Desktop does not switch back from it correctly? Hard to say which is the cause and which is the side-effect.
@hacdias my understanding is that this could go away if we remove background window (https://github.com/ipfs/ipfs-desktop/pull/1929), but maybe you see an easier fix?
When using the links on the tray area, IPFS Desktop updates the window URL via window.webContents.loadURL. In our case, since it's simply an hash update, I think Electron is smart enough to not reload the page directly. We have some hooks on the preload file for Web UI to take care of this.
The blank page is a page within Web UI. In that page, the navigation menus on the left should've been visible. Thus, if the problem was getting stuck on the blank page, we would still have the menus visible:
I agree that it feels like some edge case around doUpdateUrl but I don't think it is triggered by the moving back and forth from the BlankPage.
@lidel Since we are not 100% sure about the root cause of the problem, but it seems to be something new, I wonder if it's related to this: https://github.com/ipfs/ipfs-desktop/blob/main/src/webui/index.js#L122-L123
Since we're loading it twice in a row, maybe it's triggering some weird race condition? How is that line reducing jitter?
Indeed, I think the underlying issue is that we are not awaiting on window.webContents.loadURL (it returns a promise).
The entire launchWebUI should be async and if we await on it where it is called that should remove the surface for racy bugs.
@hacdias mind refactoring it?
-ctx.launchWebUI = (
+ctx.launchWebUI = async (
- window.webContents.loadURL(url.toString())
+ await window.webContents.loadURL(url.toString())
- window.loadURL(url.toString())
+ return window.loadURL(url.toString())
etc
Note to self: awaiting for window.loadURL fails with "ERR_FAILED (-2)" which is not very descriptive. I have to investigate (check preload and other scripts, see issue https://github.com/electron/electron/issues/18857).
Cannot reproduce this at this stage, I believe this is resolved in the latest version
