Closed ylluminate closed 2 years ago
@electron had some issue before with the session.clearStorageData()
call being hung on Windows (got spotted on e2e test running environment) and it looks like the issue is back but now on macOS. The recommendation, for now, is to roll back to the version that works for you.
I the next version will consider dropping that timeout and just ignoring the function call being hung. Ideally, the issue is to be reported upstream in @electron but I'm not ready to work on preparing a minimal/isolated reproducible project which they will request to provide.
Thanks, sorry about the trouble.
Btw, if you are able to assembly your own DMG package from sources you can try downgrading "electron" dependecny to the version that worked for you (see the @electron version in the app's "about" window). So you get latest app version but with just older @electron.
Besides I could share the WIP/electron-next-16-alpha-based build here when the build gets triggered at CI env (I don't do that often). I mean, maybe the issue is sorted out in the @electron next/16.0.0-alpha version.
Also, you could try to increase the clearSessionStorageData
value in the config.json
file but I doubt it will make any difference (default 3 seconds value should normally be enough to do the session clearing stuff).
got spotted on e2e test running environment
Btw, the exclusion was only made for Windows system and only on e2e env, https://github.com/vladimiry/ElectronMail/blob/83f63e0645f47baab50a2f1ea952479467b682cb/src/electron-main/api/endpoints-builders/proton-session.ts#L144-L146
This means there was no issue spotted during e2e test being executed on the macOS system (both Catalina and High Sierra). This makes me think that the issue is specific to an environment or user data/session.
Very much appreciate the tips and suggestions. I'm in the middle of some other work that's fairly consuming, but I will try to take a look within 1-2 weeks if I can clear out some time.
FYI, I tried testing the new release to see if this is something I needed to come back to and work on or not and it appears that the problem is sorted out now. The initial start of the app after update failed with nothing in the window and then I exited the app and reopened it and then had a number of errors. I then quit the app and opened it again and the third time was the charm and it seems everything is working normally now again. Interesting and thought you would want to be aware.
The initial start of the app after update failed with nothing in the window and then I exited the app and reopened it and then had a number of errors.
It doesn't sound normal, I'd be curious to review the related log lines.
By the way, this seems to have become particularly more serious after this last update and after seeing these messages (and closing them with the upper right x
) I'm not seeing any of the accounts render, eg:
Perhaps these two issues aren't related at all, but I wanted to call out the fact that these messages were present in abundance in addition to this issue and I can generate a separate issue for this if you like to have more clarity @vladimiry.
This session.clearStorageData()
is intended to handle some edge cases. I believe I could skip this call for an initial web client page load, since the session is still fresh in this case. This should fix the issue for a regular use cases. Will share the build here when it's ready.
this seems to have become particularly more serious after this last update
Last update comes with a major @electron "v15 => v19" upgrade. So apparently the issue became more intense with @electron update.
This should fix the issue for a regular use cases. Will share the build here when it's ready.
@ylluminate, here is the fresh build for you to test.
By the way, if you have a lot of accounts to load at the same time (without delay), maybe add the "Login delay range (seconds)" value to the accounts, so they get loaded one by one but still automatically (like you set 3-3 value to the first account, 5-5 to the second, 7-7, and so on). The "Login delay range (seconds)" field is located inside the "Advanced options" block of the account edit form.
Besides, if you rarely need to check some accounts, the option is to keep it unloaded. The combination of the "unload" context menu of the account handle button plus the "Login on account selection" toggle (located in the same "Advanced options" block).
Good call @vladimiry. That build seems to have resolved both issues even without the added delay. Initially I thought it was entirely, but after a little bit I did notice another alert popping up:
Uncaught (in promise): Error: Failed to load "webclient://mail.proton.me/blank.html?loader-id=xxx" page in 15000ms
Error: Failed to load "webclient://mail.proton.me/blank.html?loader-id=xxx" page in 15000ms
at file:///Applications/ElectronMail.app/Contents/Resources/app.asar/app/web/browser-window/index.mjs:8557:19
at Generator.throw (<anonymous>)
at asyncGeneratorStep (file:///Applications/ElectronMail.app/Contents/Resources/app.asar/app/web/browser-window/index.mjs:40110:28)
at _throw (file:///Applications/ElectronMail.app/Contents/Resources/app.asar/app/web/browser-window/index.mjs:40127:13)
at _ZoneDelegate.invoke (file:///Applications/ElectronMail.app/Contents/Resources/app.asar/app/web/browser-window/index.mjs:5993:164)
at Object.onInvoke (file:///Applications/ElectronMail.app/Contents/Resources/app.asar/app/web/browser-window/index.mjs:28000:29)
at _ZoneDelegate.invoke (file:///Applications/ElectronMail.app/Contents/Resources/app.asar/app/web/browser-window/index.mjs:5993:52)
at Zone.run (file:///Applications/ElectronMail.app/Contents/Resources/app.asar/app/web/browser-window/index.mjs:5808:41)
at file:///Applications/ElectronMail.app/Contents/Resources/app.asar/app/web/browser-window/index.mjs:6639:32
at _ZoneDelegate.invokeTask (file:///Applications/ElectronMail.app/Contents/Resources/app.asar/app/web/browser-window/index.mjs:6008:177)
I've also noticed the x64 version running seemingly a little more sluggish than it was on the arm64.
This error was reported before, and it's not something I've found a reliable fix for (except for linux/flatpak case when updating flatpak helped). Maybe try to introduce the delay I mentioned before.
Just updated in macOS and got some errors, but errors resolved when I went back to v4.12.7: