Unable to choose and copy two words

[StR]

I am not sure if this is a bug of Aquamail, or Android's library component or an unfortunate combination of various factors:
Phone: Android Razr M, running 4.1.2.
In Aquamail, when I am using a long touch to select text, it goes into selection mode, highligting first a single word. If I am trying to select more text, say two words, I cannot do, as the pointers jump randomly, mostly to a differently line. Frequently, the left pointer jumps down or above while I am trying to move the right pointer. It looks like something doesn't allow me to move the pointer continuously along the word. Rather, it jumps to some weird sort of "predifined" positions. (I am thinking this could be due to the selection function trying to choose complete words, but malfunctioning, e.g. by misjudging where the full words are, not noticing the white space between the words.)
Essentially, the lack of control of the pointers is somewhat similar to how the mouse pointer behaves with a dirty mechanical mouse.
Ultimately, I might be able to select (highlight) and copy about a line and a half or more, but unable to do that with only two or three words, or at least those wouldn't be the words I am trying to select.
I don't seem to have the same problem, say, in Opera, stock e-mail app or any other app that I remember.

[Kostya Vasilyev]

AquaMail uses the so called WebView to display message content.

This WebView is built into the system and is based on Chrome (WebKit / Blink, to be more precise, but that's nitpicking).

As such, text selection in message bodies is handled by this WebView / Chrome / WebKit / Blink, not my app.

I can confirm that I have also seen weirdness with text selection in Aqua -- but to be fair, I've ran into them in Chrome (the browser, with web sites) and also in Chrome on the desktop.

Sorry if this does not seem like a good response ("our engineers are going to look into the problem....") but I'm trying to give a technically accurate answer, not some BS.

[StR]

Kostya,

Don't worry, I know that your answer is not BS.

And I had remembered from reading some previous threads that you were relying on WebView to display the text. That's why I wrote that it might be one of the system libraries (I couldn't recall "WebView" name while writing the previous message). And that's why I mentioned that I haven't seen this quirky behavior in other text-ready apps, which include both Opera and Chrome, which, I believe, are also using WebView (aren't they?) Also, I don't see this problem in the stock e-mail client (I don't know if it's using WebView or not).

However, your message gave me some thoughts, and I did some checking.
It turns out that only some message are subject to this quirky behavior.
I was trying to figure out which ones are and which ones aren't.

Here are those that are "problematic":
1) e-mails sent from Gmail accounts (via Thunderbird for sure, and possibly via Gmail web interface) that are using UTF-8 encoding, and come with two parts: "text/plain" and "text/html"
2) e-mails in text only sent from non-Gmail accounts from Thunderbird: text-only (UTF-8)
3) e-mails in HTML sent from non-Gmail accounts from Thunderbird: "text/plain" + "text/html" (UTF-8)
4) e-mail in text only sent from alpine and elm (text-only) with US-ASCII charset or some 8-bit charsets.

Here are those that are NOT problematic:
1) e-mails that are designed as HTML (typically from various companies and banks).

I am not sure what exactly is important here (as I see that Thunderbird produces valid HTML).
At first I was suspecting UTF-8, but if even us-ascii is a problem, then it isn't the case.
The only difference I see between the HTMLs is that the "good" messages contain CSS in them (and I am not 100% sure if that's the case for all of them).

So, I suspect that WebView somehow has problems if there is now CSS.
I don't know WebView and its API. I am sharing my findings in hopes that there are some options in calling WebView that can be tweaked so that it would process non-CSS html and plain text properly.
Alternatively, maybe you can think of a workaround.

Thanks for taking your time to think about it!

[Kostya Vasilyev]

The WebView API is (more or less, actually less): "here is some HTML, show it".

There might be some embedded CSS in there (<style> tags), obviously HTML messages use it quite often, and for plain text messages, I use CSS to help the formatting...

But then CSS is, you know, not something unusual.

For a text/html + text/plain message, Aqua will use the text/html part.

[Kostya Vasilyev]

As luck would have it, I made a change to some HTML "stuff", how message content is processed before being shoved into WebView for display.

Details and actual build posted here:

http://www.aqua-mail.com/forum/index.php?topic=3317.0

No idea if that's going to help (I wasn't able to reproduce with plain text messages, tried somewhere between three to five), but maybe it's worth trying out?

[StR]

Kostya,

Thank you for the followup.
I tried that build and saw no difference, unfortunately.

Just a few thoughts (in case you are interested in reproducing this behavior):
1. It is Android 4.1.2 here. I don't know if you have that among your test environments, but I wonder if it is specific to that (and some other?) version.

2. What is the difference between treating messages that are text/html compared to those consisting of text/plain+text/html?

3. You wrote you provide some CSS for the plain-text messages. Do you also provide one for the text/html?
(a) Could the CSS you provide be the culprit somehow? (E.g. some unstable tags [with respect to WebView], or some typo? )

(b) If it is not a trade secret, would you mind showing that CSS? (You can do that via a PM).
I am wondering if I could spot something that makes it different from those CSS' that I see in the messages that "work".

4. Finally,- I will send sent you a message via PM on this forum e-mail. This message has the following strangeness:
The text "Earn miles from the comfort of your hotel room" is displayed wrapped onto the second line.
If I start selecting the text from the second line, I can continuously move the right-side marker, as long as I move within that line or going below. If I try to move the left marker to the 1st line, it becomes erratic.
If I start selecting the text from the first line, the markers jump erratically.

The same happens with the next line, "Earn 2,500 bonus miles on every other stay with Marriott &mdash;=  Up to 50,000 miles"