Closed momack2 closed 10 months ago
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
Happened again:
har file attached: broken-webui.har.zip
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
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:
Expected behavior IPFS Desktop should never show a weird, white, empty screen
Screenshots
Desktop (please complete the following information):
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?