Open kleshas opened 3 years ago
Do you have some sort of system-wide proxy configured (http_proxy/https_proxy/socks_proxy environment variables)?
If you use proxy you can try to set the updateCheck.proxyRules
value in the config.json
file (like value socks5://127.0.0.1:1087
for default Tor settings, the prop was named updateCheck.proxy
in previous app versions) and also explicitly apply the proxy config to the email accounts (see Proxy rules
input in the collapsed by default Advanced Settings
block on the account edit form).
I have no proxy
More logs:
[2021-07-15 23:01:01.297] [error] src/electron-main/api/index.ts init "keytar" module is unsupported by the system: The name org.freedesktop.secrets was not provided by any .service files
[2021-07-15 23:01:11.584] [error] src/electron-main/api/index.ts [pubsub-to-rpc-api] [provider] notification.error {"name":"updateCheck","channel":"electron-mail:ipcMain-api","payloadType":"request","uid":"474f7a34-6f5a-45e0-9075-a589da02788f"} FetchError: request to https://api.github.com/repos/vladimiry/ElectronMail/releases failed, reason: net::ERR_FAILED
at ClientRequest.
I have no strong guess as to why the issue started to occur for you.
You say it started to happen a few week ago. The only reason I could guess at the moment is @electron update (or its @chromium part). I can suggest to use the version that doesn't demonstrate the problem, probably v4.12.2. You can download the specific version from https://github.com/vladimiry/ElectronMail/releases and install it the sudo pacman -U electron-mail-4.12.2-linux-x64.pacman
way (uninstall the electronmail-bin
package first and clean/better-backup the ~/.config/electron-mail
app config folder).
An object could not be cloned
This error is going to be ignored in the next app release as it's likely the case of AbortError (inherited from the DOMException) can't be serialized for passing between the processes (the case of sending log lines from the web/renderer to main process for writing to the log file). So this is irrelevant to the current issue stuff.
4.12.2 does work.
If it's not a huge burden for you I'd ask you to also test the v4.12.3 so the issue scope gets narrowed down. There was just minor 13.0.1 => 13.1.2 @electron update in v4.12.2 => v4.12.3 changelog so unlikely it broke things. If it doesn't work wipe the config folder again before rolling back to 4.12.2.
4.12.3 also works.
Thanks. Then the issue likely caused by @electron 13.1.2 => 14.0.0-beta.11 upgrade. Hope it will get self resolved by next @electron update in the next app release. I've not explored yet the https://github.com/electron/electron/issues tracker for relevant issue.
Ok, fair enough. I thought I'd quickly check the latest via the github's .pacman rather than using the AUR's -bin. Still the same error on running the application, but I did get this error on install:
Error in file "/usr/share/applications/krita_jpeg.desktop": "jpeg/jfif" is an invalid MIME type ("jpeg" is an unregistered media type)
that file was installed by Krita on day 1 of the OS install and nothing to do with this. nevermind - I get that on .3 too.
I'd quickly check the latest via the github's .pacman rather than using the AUR's -bin
There should be no difference since AUR fetches the pacman file from https://github.com/vladimiry/ElectronMail/releases.
By the way, does the recent app release work well in general if you just disable the "Check for update and notify" toggle on the "General" app settings (or manually via editing config.json
file, the checkUpdateAndNotify
property)? Asking since in the recent release the module that fetches the https://api.github.com/repos/vladimiry/ElectronMail/releases URL was changed the node-fetch => electron-fetch
way. So that's an addition change to the @electron 13.1.2 => 14.0.0-beta.11 upgrade. The bad thing is that the issue is not reproducible on my side nor on some other systems (I've asked a few app users).
No, it times out when authenticating the first email address it tries.
Ok, then only @electron upgrade is a remaining possible issue cause. Btw, consider trying "flatpak" (I normally prefer it to snap) and "snap" packages (links to both posted on the project's front-page/readme).
I've found the issue when suddenly Puppeteer stopped working for me as well.
If you open your /etc/nsswitch.conf
you'll see a line like this:
hosts: files mymachines myhostname resolve [!UNAVAIL=return] dns
If I remove the part resolve [!UNAVAIL=return]
then ElectronMail (and Puppeteer) work again. I'm not sure what it does but other applications don't seem to be affected by the change.
My questions: Why are only Chromium based application affected by it? And why only some of them and not all of them? The normal Chromium browser work fine.
`[2021-07-15 22:41:47.417] [error] src/electron-main/web-contents.ts {"level":3,"message":"[object Object]","line":71868,"sourceId":"file:///opt/ElectronMail/resources/app.asar/app/web/browser-window/index.js"} [2021-07-15 22:41:47.430] [error] src/web/browser-window/app/app.error-handler.service.ts { name: 'FetchError', message: 'request to https://api.github.com/repos/vladimiry/ElectronMail/releases failed, reason: net::ERR_FAILED', stack: 'FetchError: request to https://api.github.com/repos/vladimiry/ElectronMail/releases failed, reason: net::ERR_FAILED\n' + ' at ClientRequest. (/opt/ElectronMail/resources/app.asar/app/electron-main.js:25134:20)\n' +
' at ClientRequest.emit (events.js:376:20)\n' +
' at ClientRequest._die (electron/js2c/browser_init.js:105:8391)\n' +
' at SimpleURLLoaderWrapper. (electron/js2c/browser_init.js:105:7128)\n' +
' at SimpleURLLoaderWrapper.emit (events.js:376:20)'
}
'
For a couple of weeks now, I haven't been able to connect. Timesout when checking for mail, mailbox not even shown, and as you can see from the log above, the version checks times out too. This is across two OS installs (arch linux), and having removed all configs and reinstalled electronmail-bin from the AUR.