Protonmail 4.0 support

[vladimiry]

v4 is currently in early beta and as far as I understant there are no new features enabled yet but only the partial visual redesign and complete code rewrite have been conducted. So I'm going to wait for a while until v4 gets stabilized. The plan is to keep both v3 and v4 webclients available here in the app until v3 gets deprecated by the service provider.

[vladimiry]

The clarification point is that there is no goal of getting back the https://beta.protonmail.com / live / online entry point but having v4 webclient code prepackaged with the app.

[ylluminate]

How soon are we looking at seeing a 4 beta usage release? I'm very much looking forward to their apparent commitment to a native dark theme.

[vladimiry]

I'd like them to add something new to functionality, like calendar thing. Right now it seems to be only the theming stuff.

Besides supporting https://beta.protonmail.com/ involves maintenance burden increasing as I prefer not to support live/https://beta.protonmail.com web client but only prepackaged/embedded in the app. So I hope at the time they add new functionality to v4 they will have moved it to the primary domain. This would allow me to focus on supporting only the primary domains/version.

The next app release will be 4.0.0, possibly today. The major version since Tutanota support gets dropped.

[vladimiry]

The calendar went live today in beta mode but the respective client-side code is not available yet, see ProtonMail/WebClients#166 (comment). So I can't start experimenting yet.

[vladimiry]

I'm considering to enable offline access to Calendar events feature in a similar way to how it's already implemented for the email messages (see local store topic in the FAQ for details). As far as I know, ProtonMail is not planning to provide such capability in the near future even for paid users, so it might be a unique feature if it gets implemented.

[vladimiry]

If someone wants to try the first version with prepackaged ProtonMail v4 web interface, you can take here the pre-4.1.0 packages assembled from the protonmail-webclient-v4 branch (or compile it yourself, c9c715f is a key change on top of master branch). It feels stable to me, so going to publish it as a release in a few days if no serious issues detected.

[joshirio]

That's great this was fast, I'm happy to give it a try and I'm looking forward to using the new calendar.
One issue though: the download link (windows installer) isn't working, it says "temporary download error", never had an issue with MEGA, I'm using it myself every day but there seems to be an issue with the server, anyone was able to download it successfully?

[vladimiry]

Just tested the link, seems to be downloadable. When downloaded check the sha1sum, should be:

electron-mail-4.1.0-windows-nsis-installer.exe [sha1]: 43013cd12610d665706671c44fd416d379d927be

https://ci.appveyor.com/project/vladimiry/electronmail/build/job/15ryvpx78ala5ek0#L1529 (line 1529)

[ylluminate]

Mega download worked fine for macOS. pre-4.1.0 worked great, interface loads up. Sidebar is dark (but the foregrounds are still blindingly white 😖 :

[vladimiry]

I think I've noticed the issue with calendar if running the above-provided app package. When you create/edit the event it requires the page reload to see the update (changing the page to mail/settings/contacts and getting back to calendar then) but the change should be displayed on the page without the page refresh like I can see it running https://beta.protonmail.com in a browser (it should process the events reduced from https://domain/api/events/*).

I've debugged the stuff a little and noticed that protonmail api doesn't put the calendar-related events to https://domain/api/events/* response if calendar is used from inside the app, so the calendar, if used from the app, doesn't see the on-the-fly update which is a bad thing. So far it's unclear what causes those events being missed. I better enable https://beta.protonmail.com/ domain in the app which I didn't do yet and then I should try the calendar on beta API entry point since protonmail, for now, supports the calendar on beta domain only (though it works on primary domains too, at least partially).

[ylluminate]

BTW, you might want to link users up to some nice full dark themes that have been made for version 4 (found on reddit):
https://github.com/csalmeida/protonmail-themes/tree/themes-v4/themes

[vladimiry]

Thanks for the link, theming is a low priority at the moment.

[ylluminate]

I understand - just saying a link on github itself might be useful or such. It appears that PM themselves are working on a dark theme: https://www.reddit.com/r/ProtonMail/comments/edes53/protonmail_themes_fixes_to_dark_mode_and_full/fbqhqws/

Just a tweak on the left side accounts white bars to bring it into the neutral zone could help this release markedly. I don't think there's a reason to have them at such high contrast levels.

[vladimiry]

I just tried using https://beta.protonmail.com in the app and the issue with the calendar is still there. So it's either I missed something building the calendar package and putting it in the app as a static resource or we build it from different code sources.

[vladimiry]

we build it from different code sources

Yep they currently run 4.0.0-beta7 / 01557780595cd492e42ade9a388059c59b13fc42 on https://beta.protonmail.com/ which they didn't publish yet https://github.com/ProtonMail/WebClient/commits/v4 So we use 4.0.0-beta6 / ProtonMail/WebClients@45cd0e4 in the app:

ElectronMail/src/shared/constants.ts

Lines 65 to 66 in d1c6c2b

	commit: "45cd0e44230dfaf7ebc180149a17a438b979ca08",
	version: "4.0.0-beta6",

So I will need to test the 4.0.0-beta7 in the app when they publish the update in the repository. Although it's a mail client version but the calendar is a different app.

[vladimiry]

I just tried to run a regular webserver (like python -m http.server 8000) on the same web client folder I packed into the app as a static resource and I see the same problem there, the calendar still lacks live updates. So it looks like it's about the calendar build/code itself but not about it's being run packed in the app/electron. Another guess is that maybe Protonmail's calendar-related API at least for now treats local and deployed on their domain clients differently.

[vladimiry]

Ok, I figured what was causing the no live calendar updates issue if the build I posted above was used. I missed putting proper proton app-specific clientId parameter into the appConfig.json file before triggering the build (this parameter then used in application runtime to form x-pm-appversion request header). Going to prepare a new app build today.

[vladimiry]

I'm considering to enable offline access to Calendar events feature in a similar way to how it's already implemented for the email messages

Just opened a respective issue #229.

[vladimiry]

Updated build with the calendar issue fixed has been uploaded here. I think we got closer to v4.1.0 release with this build.

@ylluminate, you will notice that the account handle buttons became less contrasted with that build, hope you like it more this time.

Regarding theming change, I missed to handle the following minor items but it's now in my internal TODO list so won't be missed when release is ready:

• Make green syncing indiction icon blink in yellow if the button is not-active/gray (since the green icon is hardly noticing on gray background). Maybe I keep the gree color but will make it lighter/brighter.
• Make the text color of hovering link highlighting block a little lighter (the block is located at the bottom-left corner when any link on the page is being hovered).

Besides that, I moved assembling the macOS package from Travis CI to Appveyor. Using Appveyor is more convenient for me and the ultimate goal is to completely get rid of Travis CI use. But anyway this should not affect the end-users.

If someone needs checksums and build logs for the above-referenced work-in-progress packages

• line 1297 (mac): https://ci.appveyor.com/project/vladimiry/electronmail/build/job/bdx5t6dklpo5q3uy#L1297
• line 1523 (win): https://ci.appveyor.com/project/vladimiry/electronmail/build/job/rlh88b7whhsk8bgs#L1523
• line 5412 (linux): https://travis-ci.org/vladimiry/ElectronMail/jobs/634789009#L5412

[vladimiry]

A new build has been uploaded here. Changes on top of the posted in the previous message build:

• Handle those stying issues: make syncing indiction icon brighter (still green) and fixing text color of the hovered link highlighting block.
• Upgrade @electron 6.1.7 => 7.1.8.

Build logs

• mac: https://ci.appveyor.com/project/vladimiry/electronmail/build/job/1vtlv96avsi9ecll#L1292
• win: https://ci.appveyor.com/project/vladimiry/electronmail/build/job/o1m8wxbwjs7gg435#L1498
• linux: https://travis-ci.org/vladimiry/ElectronMail/jobs/635153236#L5415

[vladimiry]

If someone has not noticed yet ProtonMail Web Interface/Client v4 consists of 4 individual single-page applications (SPA), read it like 4 HTML pages instead of one. Settings/Contacts/Calendar are React-based SPAs but Mail one is still based on AngularJS. It's clear though that they have been working on React-based Mail SPA, see some progress here. So when they replace the currently used Mail app with a new one even just to keep the current ElectronMail functionality some work will be required like rewriting the integration layer from interacting with AngularJS to React.

So it's 4 HTML pages now. In my opinion, it badly affects the UX but I understand splitting functionality to the individual projects was a simpler way to move forward with rewriting the old stuff to a somewhat new/better-scalable stack and also I guess to a model of maintaining the projects in parallel by different teams. Besides they probably aim to ship some of these projects as individual offers, so you get a Calendar app for the instance but not the Mail one. The thing is when you leave the Mail page you literally switch to another application with its own functionality, ie you lose the "mail" context. This is how they designed it. But I think since we are not limited by browser capabilities on the desktop I could load a second/hidden page and use it as a bridge for communication with the app (maybe the Calendar page itself for a start or minimal compiled proton-APIs-aware-like page designed for integration purposes only). So then even when for the instance you leave the Mail page, the app still would be able to sync the message events, sync the calendar events (not there yet), provide in-time/live notifications and do other needed stuff in the background regardless of which page of 4/Settings/Contacts/Calendar/Mail you have open at the current moment. That would enable a more consistent UX on the desktop than you get using v4 interface in the browser. But it also means complicating the implementation. Maybe this kind of work will be started as a part of #229, even before they switch the currently deployed AngularJS-based Mail app to a new one.

[vladimiry]

ProtonMail Version 4.0-beta Web UI support released in https://github.com/vladimiry/ElectronMail/releases/tag/v4.2.0.