"Some parts of the email failed due to a lost connection." error message in android app

[d8f6]

• [x] This is not a feature request (existing functionality does not work, not missing functionality).
• [x] I've searched and did not find a similar issue.

Bug in mobile app

Describe the bug When attempting to view an email an error appears which displays: "Some parts of the email failed due to a lost connection." and there is a link which shows "Try again" which immediately fails. This is specifically for the android application installed through f-droid. Phone is lineageos + microg. Tested using current and previous version of mobile application at the time of this writing (3.118.30 and 3.118.27 respectively).

To Reproduce Steps to reproduce the behavior:

1. Open android app, then open email.

Expected behavior I should be able to read my emails.

Screenshots Not Applicable

Smartphone (please complete the following information):

• Device: [Pixel 3a]
• OS: [android 11 - lineageos 18.1]
• Version [3.118.30] //assuming app version?

Additional context Seems like this may be a known issue as I say some reddit threads about this, but did not see a bug report here so decided to file one. Tried with/without vpn, US and Germany vpn servers, and with/without wifi. Also tried uninstallion and reinstallation of application. When I look at the emails from the web and desktop clients I see the emails so I am assuming they went through. Also, I can still see the subject of the messages, just not the body.

[nutpantz]

I also have this issue. on every new email since i updated to latest today on fdroid 3.118.30

[Mession77]

Exactly same issue here. Very annoying, have to use laptop to read mails now. :-(

[nutpantz]

[nutpantz]

Google apis to determine if Android is connected to the internet obviously has a lot of bugs. I always have to force close this and other apps when they think they Android can't connect. But now this app is failing everytime since the last update.

[Greenactivist]

I am having the same problem using a Fairphone 3 with a de-googled version of Android 9. I have never had any problems until the update to Fdroid 3.118.30

[d8f6]

Okay, so I decided to test 3.118.25 and the issue still persists which makes me suspect this bug may not be client side.

[Mession77]

Okay, so I decided to test 3.118.25 and the issue still persists which makes me suspect this bug may not be client side.

Same here. Went back to 3.118.25 same results. Did no other updates of OS or anything. Mails from 29 November and older load ok, can't load any mail from 30 November and later.

[Greenactivist]

Okay, so I decided to test 3.118.25 and the issue still persists which makes me suspect this bug may not be client side.

That seems likely but it might be more complicated than that. I can read my emails using the web client on my desktop. However the web client fails in exactly the same way on my phone. In the past when there has been a problem with the app, I have always been able to use the web client on the phone. Not as convenient as the app but had the advantage of actually working.

[Greenactivist]

This could be a side effect of DDOS attacks on tuta or a side effect of attempts to mitigate such attacks. It would be nice if someone from tutanota could tell us what is going on.

[d8f6]

@Greenactivist

I can login and read email from a browser on my phone no problem. If the issue was ddos, then it would not be client specific as far as I know. I do agree though that a developer should look at and/or be contacted for this issue though since being able to read email is a pretty important function of an email client. This issue, in my opinion, should be elevated to a critical level bug since it completely breaks the basic functionalty of the service.

[Dim-Mal]

Same problem here!!!! Please solve it!!! I cannot work!!!

[d8f6]

@charlag and @ganthern

Hey, you two seem like the main devs (based on recent commits), so I wanted to ping you and let you know of this issue in case you were not aware/haven't had a chance to read newest bug reports yet. Thank you in advance.

[Greenactivist]

@d8f6 As I understand it, whether a DDOS attack effects every client equally depends on a lot of things such as different timeouts in different network routes. As you will appreciate all attempts at TCP/IP timeout some time. It is also common to try to mitigate the effects of an attack by blacklisting, some servers. This would potentially effect different clients differently.

Incidentally, the web client has stopped working in Firefox on my laptop. So I would have to go to my local library to send/receive email. (perhaps}

[nutpantz]

There is one device on the wifi in this household where it works (Android 9) and another device on the wifi where it does not work (Android 12). So...... I don't think it's from black listed ip addresses.

[d8f6]

@nutpantz Yeah, I tested network issues as written previously, so I don't think that is related to this issue. Does the Android 9 device you are using use gapps (stock rom / google service daemons) or is it a libre software stack (microg/lineageos/etc..)? Besides Android versions are the system roms different in any way?

[nutpantz]

@nutpantz Yeah, I tested network issues as written previously, so I don't think that is related to this issue. Does the Android 9 device you are using use gapps (stock rom / google service daemons) or is it a libre software stack (microg/lineageos/etc..)? Besides Android versions are the system roms different in any way?

the A9, it has gapps, but they are blocked by firewall. FWIW it is a blackview device.
the A12 is ProtonAOSP pixel6 no gapps or microg and not totally libre software stack AFAIK

[d8f6]

@nutpantz Sounds like we've identified the issue. Something related to google cloud service or push notifications, etc... probably. Now we just need a fix from the devs here. If this turns into a service that requires google apps to function, I'm definitely going to use something else, as it would be pointless for me. I can't imagine it going that way, since "We Love Open Source" is literally on their home page, but we'll still have to wait on a fix. Not sure what to do in the meantime. Just have to wait I guess.

[nutpantz]

@nutpantz Sounds like we've identified the issue. Something related to google cloud service or push notifications, etc... probably. Now we just need a fix from the devs here. If this turns into a service that requires google apps to function, I'm definitely going to use something else, as it would be pointless for me. I can't imagine it going that way, since "We Love Open Source" is literally on their home page, but we'll still have to wait on a fix. Not sure what to do in the meantime. Just have to wait I guess.

Personally I suspect it's not Google services related, but a Android api that defines if the internet is available. Which has always been an issue on and off for this app. If Android can't connect to Google (or some other location) when it's checks connectivity the app fails,and since that api has more bugs, it always causes issues. I'm sure it will be fixed and be broken every other release.

Android is hardly aosp compatible anymore. And Google is working hard to get developers to use Googlesv easy api's

[nutpantz]

If i try to view email headers the app thinks i am offline and fails.

I hope this is not the "premium" pay to view emails offline bug again thinking the apps always offline. That caused me issues for 3 months when it was first released.

[nutpantz]

[nutpantz]

Btw i can still get and read my old emails from last month, it's just new emails i can't read. Maybe they did not replace all the tutanota.com with tuta.com addresses in the app.

[Mession77]

Could this be a WebView issue? Support often refers to WebView as the first culprit for issues.

[charlag]

We've seen this reported, thanks everyone for providing more info.

This is genuinely 99.999% not caused by Play Services. We do not do anything with play services whatsoever.

It also shouldn't be offline detection, that does not affect normal requests, maybe reconnects but since it looks like everyone is online in these screenshots it shouldn't matter.

Did anyone here take a look at the logs? (settings -> about -> send logs)? Did you see any errors or did you send them to support?

[Mession77]

Did anyone here take a look at the logs? (settings -> about -> send logs)? Did you see any errors or did you send them to support?

Lots of these errors in the log (xxxxxx is my anonymization): 2023-12-05T08:54:53.673Z I "[RestClient]","failed request","GET","https://w16.api.tuta.com/rest/tutanota/maildetailsblob/xxxxx----9?accessToken=....&cv=3.118.30",0,"",["Accept"],"no body" 2023-12-05T08:54:53.673Z I "can't load instances from server https://w16.api.tuta.com",ConnectionError Error message: 0: | GET /rest/tutanota/maildetailsblob/xxxxxx----9

[charlag]

We still strongly suspect it is WebView related (you should see it in UserAgent if you do the logs dialog again). Could you please check that?

[Mession77]

We still strongly suspect it is WebView related (you should see it in UserAgent if you do the logs dialog again). Could you please check that?

User agent: Mozilla/5.0 (Linux; Android 10; xxxxxxxx; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/88.0.4324.93 Mobile Safari/537.36

[charlag]

Chrome 88

yeah that would do it

[Mession77]

Chrome 88

yeah that would do it

Manually updated my system with more recent WebView (using apk, may not be safe!). Had to do it that way because no system updates were available for my device. Tried Chrome/92.xxxxx nu luck. Now running Chrome/99.0.4844.88 and all is working again.

[nutpantz]

They need to stop using webview. No updates listed for my device either.

[d8f6]

@charlag Yes, this was indeed the issue. All fixed now on my end. Thanks for getting back so quick. I did not realize bromite/bromite webview was so depreciated.

Edit: Apprently webview has to be installed to /system, so I removed the instructions for instaling it as regular user. Follow the instructions here instead if you do not use magisk:

https://github.com/A4Alpha/mulch-webview-overlay

Since this is not a bug with the client/server, (but rather a consequence of using an up to date android toolchain to build the app?) I am not sure whether or not to close this issue.

[nutpantz]

This will always be an issue sooner or later for older devices and for any device not on goggles eco system. I don't know if my fire hd tablet has any method to update the webview on it, short of registering with Amazon and giving up all hope of any privacy. And there is also a huge number of devices in China and elsewhere that don't pay for goggles ecosystem.

The real fix is to stop using webview (and the questionable providers it could come from) and have the app completely self contained. I expect that is not on the list to do for whatever reason.

I would not close this, it will make it harder for anyone else to find. And there should be built in version checker as this is a app breaking issue if nothing else is done.

I would also like to know why after this update webview is trying to access the internet (sea09s35-in-f3.1e100.net owned by Google) all by it self when it is not being used at the time. Not a good thing for privacy advocates. But not part of this project.

[charlag]

Thanks everyone for getting back to us.

We have built-in checks but mostly for features as we try to not hardcode certain browsers/versions. In this case I am still unsure what the issue is and we will probably have to bump the minimum Chrome version. For implementers: this is here

https://github.com/tutao/tutanota/blob/ce7bc4172d3d70c590d4ef150b5a9c340251c087/src/misc/ClientDetector.ts#L360-L362

WebView situation is pretty annoying for literally everyone. We would love to not confuse people with WebView updates and such and just maybe embed one but the last time I checked there were no available implementaions (aside from GeckoView which has its own issues). For majority of people who have stock ROMs it's not an issue but with some vendors and with some custom ROMs this is an issue. On modern Android you can always just select a WebView implementation in Developer settings as long as it is installed. It is outside of our scope to solve this issue for all ROMs. If you have outdated WebView on your device you are generally in trouble as some app somewhere will use it and it means you probably have a ticking 0-day on your device.

[Mession77]

On modern Android you can always just select a WebView implementation in Developer settings as long as it is installed.

That's the thing, many phones simple lock the stock WebView and won't allow selecting another one. I am on a Huawei, Android 10 mobile. Maybe 2 years old and already having this issue. Can't imagine having to buy a new phone every time some part of the vendor's software is deemed too old to work and no updates are available from vendor.

In that case I'll be using my mobile browser to access the Tuta mail. Is this as secure as using the app btw?

[Greenactivist]

@d8f6 Thanks for pointing me to the magisk module. I first tried the version on Aurora which worked, even though it was allegedly exactly the same version of the one already installed. However I don’t like relying on Aurora, if I can help it, and was pleased to switch to the magisk version.

[d8f6]

@Greenactivist Happy to help. Glad it's working now for you.

So, this issue got me thinking: Why can we not get emails in plain text? This has always been my preference anyways. I see options in the client to send emails in plaintext, but no options to receive them in plain text. I remember back when I used an email client with smtp etc... I would always just use plain text mode. I really just need the message and hyperlinks (if applicable, nevermind I don't actually need this either), and don't really care about pictures and formatting etc... Is there already a way to do this that I am unaware of or does it only work for outgoing mail? Most of the time the html emails are just extra junk anyways in my case (company logos headings, etc...). It also throws off my whole theme (white text on dark backround to black text on white backround throws me off). I looked and didn't see an issue that directly references this, but I may have missed it. Does a new feature request need to be started for this?

[Greenactivist]

@d8f6 I agree with you about plain text emails. I don’t think there is a RFC anywhere referring to html emails. I think it’s something Microsoft started doing in the mid 90’s and everyone else followed suit. It doesn’t add any useful functionality as if you can always use attachments to send people images etc. On the other hand it introduces extra security risks. I don’t like the way it messes with my theme either.

I haven’t seen any options to receive emails in plain text either. I think it would be great to open an issue in it.

[d8f6]

@Greenactivist Hmm... well it seems like we can not request new features here, it is only for bug reports according to the new issue template. It says to request new features on reddit, but I have no intention of using reddit for anything (I would actually prefer gitlab over github too, but that is another topic). Hopefully it gets added in the future.

[Greenactivist]

@charlag I suppose the real issue is why are we force to use WebView at all. I spent years dealing with text-only emails and can do without this extra html garbage. If there had been an option to receive emails in plain text I would have never noticed the problem. Incidentally, like @d8f6, I have no intention of requesting this on reddit.

[charlag]

Please don't go off-topic. There is also https://github.com/tutao/tutanota/discussions/ if you want to suggest something.

Plain-text emails are nice and would be good to support them better but also it won't help the WebView issue because the app is a hybrid native-web app with overwhelming majority of the code being the web part.

[nutpantz]

The problem is that the issue has been defined as "it's webview and not our problem buy a new phone if you can't update it", everyone uses webview and so do we.

Webview is a 200mb meglo monstrosity with who knows what issues as it grows in complexity every other week.

Why would it only get part of the emails?

Webview, which never tried to connect to the internet before on it's own, now is everyday.

[d8f6]

So, for anyone having this issue, but does not use magisk/root etc.. It seems the mulch webview can also be installed with f-droid by adding the divestos repo and refreshing your f-droid repositories. The repo is here: https://divestos.org/fdroid/official/ After that you can just search for and install mulch webview and then change it in the system settings by searching for webview after enabling developer options depending on your rom. To enable developer options on android you can follow the instructions here if you do not know how to do so: https://developer.android.com/studio/debug/dev-options (basically you just tap build number 7 times in settings and it shows advanced options for your phone). Hopefully this helps anyone still having issues.

@charlag Thanks again. I have found and posted there.

If anyone else is interested in this feature request I have submitted it can be found here: https://github.com/tutao/tutanota/discussions/6272

With that I am going to unsubscribe from this thread. Technically speaking it is not a bug with tuta code itself anyway as far as I can tell. If any of the instructions to use an alternate webview I posted are unclear and you want me to help then ping me here or shoot me a message. I was going to close this bug, but I will let the mods do that as there seems to be some discussion still taking place and the issue has been pinned (I am not sure if closing the bug would effect the pin). Okay, thanks charlang and everyone else who helped and take care.

[SkewedZeppelin]

Android only allows using a WebView if it is either installed into /system OR it has its signature allowlisted: https://chromium.googlesource.com/chromium/src/+/HEAD/android_webview/docs/aosp-system-integration.md#why-are-there-security-restrictions-on-which-apps-can-be-used-as-a-webview-implementation

Most systems should allow use of the Google WebView provider, but it has the same telemetry as Chrome, however it may be worth it as opposed to being 30 major Chromium versions behind. (Current is 120, and some of you are on 92!? :frowning: )

@nutpantz

Webview, which never tried to connect to the internet before on it's own, now is everyday.

If you're talking about my Mulch, it is open source: https://gitlab.com/divested-mobile/mulch And the connections are documented here: https://divestos.org/pages/network_connections#mulch I also track update history for Chromium forks here: https://divestos.org/misc/ch-dates.txt Mulch System WebView is pre-installed on systems by MSe1969, syphyr, Tomoms, and steadfasterX and it can also be used on CalyxOS and iodéOS without any modifications.

@d8f6

Device: [Pixel 3a] OS: [android 11 - lineageos 18.1]

LineageOS and my DivestOS both offer Android 13 (20.0) based builds for this device, you're missing two years of security updates by staying on 18.1

[d8f6]

@SkewedZeppelin Thanks for the clarification. I have edited my previous post. As to updating, I would have to just reinstall the whole system (lineageos requires a custom kernel for SmartPack-Kernel Manager to be able to change sound headphone gain settings which I need to make things louder (using elementalx, but I didn't backup the original kernel and am worried an update will break everything), I am not sure if DivestOS requies a custom kernel for this or not, if it is anything like GrapheneOS it definitely will not work), which I will get around too eventually. My phone setup is pretty basic/hacked together.

[charlag]

Thank you for posting additional info on FAQ. It mirrors and compliments our Support entry on WebViews: https://tuta.com/support/#web

We will close the thread once we raise the minimum Chromium version.

It is extremely naive to ask for a Mail app without any kind of browser engine as almost all emails at this point are HTML formatted, whether you like it or not.

I will lock the discussion now as it's clearly going off-topic.