Not able to auto login

[doraeric]

I have configured Electron Mail to start automatically on boot with a persistent session. However, several months ago, it stopped maintaining the login status. Every time I boot up, I have to log in again, and I also have to go through a graphical captcha. I've tried deleting the config folder, but even after logging in, it still doesn't retain the login status the next time.

electron mail version: v5.2.2 (c5f76ec)

I found the error message in .config/electron-mail/log.log:

[2023-11-25 12:32:35.972] [error] src/electron-main/web-contents.ts {"type":"console-message","level":3,"message":"Unleash: unable to fetch feature toggles InactiveSession: Inactive session","line":171700,"sourceId":"webclient://mail.proton.me/assets/index.767a7dc1.js?v=5.0.31.1"}
[2023-11-25 12:32:35.974] [error] src/web/browser-window/app/_accounts/account-view.component.ts AccountViewComponent webview event {"type":"console-message","level":3,"message":"Unleash: unable to fetch feature toggles InactiveSession: Inactive session","line":171700,"sourceId":"webclient://mail.proton.me/assets/index.767a7dc1.js?v=5.0.31.1"}
[2023-11-25 12:32:35.977] [error] src/electron-main/web-contents.ts {"type":"console-message","level":3,"message":"Uncaught (in promise) InactiveSession: Inactive session","line":46056,"sourceId":"webclient://mail.proton.me/assets/index.767a7dc1.js?v=5.0.31.1"}
[2023-11-25 12:32:35.977] [error] src/electron-main/web-contents.ts {"type":"console-message","level":3,"message":"Uncaught (in promise) InactiveSession: Inactive session","line":46056,"sourceId":"webclient://mail.proton.me/assets/index.767a7dc1.js?v=5.0.31.1"}
[2023-11-25 12:32:35.978] [error] src/electron-main/web-contents.ts {"type":"console-message","level":3,"message":"Uncaught (in promise) InactiveSession: Inactive session","line":46056,"sourceId":"webclient://mail.proton.me/assets/index.767a7dc1.js?v=5.0.31.1"}
[2023-11-25 12:32:35.978] [error] src/electron-main/web-contents.ts {"type":"console-message","level":3,"message":"Uncaught (in promise) InactiveSession: Inactive session","line":46056,"sourceId":"webclient://mail.proton.me/assets/index.767a7dc1.js?v=5.0.31.1"}
[2023-11-25 12:32:35.978] [error] src/web/browser-window/app/_accounts/account-view.component.ts AccountViewComponent webview event {"type":"console-message","level":3,"message":"Uncaught (in promise) InactiveSession: Inactive session","line":46056,"sourceId":"webclient://mail.proton.me/assets/index.767a7dc1.js?v=5.0.31.1"}
[2023-11-25 12:32:35.982] [error] src/web/browser-window/app/_accounts/account-view.component.ts AccountViewComponent webview event {"type":"console-message","level":3,"message":"Uncaught (in promise) InactiveSession: Inactive session","line":46056,"sourceId":"webclient://mail.proton.me/assets/index.767a7dc1.js?v=5.0.31.1"}
[2023-11-25 12:32:35.983] [error] src/web/browser-window/app/_accounts/account-view.component.ts AccountViewComponent webview event {"type":"console-message","level":3,"message":"Uncaught (in promise) InactiveSession: Inactive session","line":46056,"sourceId":"webclient://mail.proton.me/assets/index.767a7dc1.js?v=5.0.31.1"}
[2023-11-25 12:32:35.983] [error] src/web/browser-window/app/_accounts/account-view.component.ts AccountViewComponent webview event {"type":"console-message","level":3,"message":"Uncaught (in promise) InactiveSession: Inactive session","line":46056,"sourceId":"webclient://mail.proton.me/assets/index.767a7dc1.js?v=5.0.31.1"}
[2023-11-25 12:32:47.655] [error] src/electron-main/web-contents.ts {"type":"console-message","level":3,"message":"[object Object]","line":8680,"sourceId":"file:///opt/ElectronMail/resources/app.asar/app/web/browser-window/index.mjs"}
[2023-11-25 12:32:47.705] [error] src/web/browser-window/app/app.error-handler.service.ts {
  name: 'Error',
  message: 'Invocation timeout of calling "notification" method on "electron-mail:webview-api:primary" channel with 25000ms timeout',
  stack: 'Error: Invocation timeout of calling "notification" method on "electron-mail:webview-api:primary" channel with 25000ms timeout\n' +
    '    at <anonymous>:965:24\n' +
    '    at Observable.init [as _subscribe] (<anonymous>:5216:35)\n' +
    '    at Observable._trySubscribe (<anonymous>:3231:25)\n' +
    '    at <anonymous>:3225:121\n' +
    '    at Object.errorContext (<anonymous>:10349:16)\n' +
    '    at Observable.subscribe (<anonymous>:3223:26)\n' +
    '    at doInnerSub (<anonymous>:6939:58)\n' +
    '    at outerNext (<anonymous>:6933:40)\n' +
    '    at OperatorSubscriber._this._next (<anonymous>:5391:15)\n' +
    '    at Subscriber.next (<anonymous>:3637:123)'
}

[vladimiry]

The notification channels has to be setup, so the further "app <=> @electron webview" interaction logic works as designed, including secure persisting the active session for reuse it on the next app start. The log error indicates the issue with notification channel establishing, the timeout error.

Why this happens is unclear at the moment, as there is no error cause in the log, so the request for notification channel setup just hangs somewhere in the @electron/@chromium internals. Some other users experience similar issues, see #648 for example.

I guess I could disable the background throttling for webview's "webContents", and we see then if it increases the "app <=> @electron webview" interaction stability.

For now, if you run Linux, consider other package types, like for example flatpak-based one. Writing this because the issue like this might be potentially related to environment specifics (it stopped working for you a few months ago, for some reason, like for example update on your environment), and "flathub" comes with some environment isolation capabilities.

[lxgr-linux]

This is happening to me since the last update.

[doraeric]

I tried flatpak-based version, and it works fine. There is no longer a need for a captcha, and the session remains valid the next time the app starts.
Maybe it's caused by the environment like you said.

[lxgr-linux]

For me this is back working on my arch system.

[vladimiry]

@lxgr-linux thanks for the update.

Based on this issue, and other cases too, I could say that "app <=> @electron webview" interaction, on some systems and for so far unclear reason, is a sensitive area of @electron. As pointed before, for the next release, I'm going to disable background throttling for webview's "webContents" guessing that this might increase named interaction stability.

Another option is replacing "app <=> @electron webview" interaction with communication via the main @electron channel, used as a simple events/signals redirection thing. So instead of direct "app <=> @electron webview" interaction, the main process would be in the middle "app <=> main <=> @electron webview". Besides, this approach would likely benefit the "context isolation" enabling need as when I tried it before, the direct "app <=> @electron webview" interaction had some issue in relation to "context isolation". But this would increase the code complexity and would require some refactoring, so this approach is undesirable.

[vladimiry]

I'm going to disable background throttling for webview's "webContents" guessing that this might increase named interaction stability.

The backgroundThrottling: false flag is already there for at least 3 years,

ElectronMail/src/electron-main/window/constants.ts

Line 18 in c5f76ec

backgroundThrottling: false,

[sbstn87]

Hello,

any chances this will be fixed?

I also have this issue since November 2023 (Windows 10).

By the way, when I use Ferdium to login into ProtonMail, autologin works perfectly fine:

https://github.com/ferdium/ferdium-app

[vladimiry]

The updated version sits in the wip branch, so you could assemble app build from that branch.

By the way, when I use Ferdium to login into ProtonMail, autologin works perfectly fine:

This is just a wrapper of a regular proton's webclient without any addition features, so it obviously uses proton's auto login approach (saved sessions). Totally different approach used here (addition features, custom sessions saving, etc).