Upload video.

Deleted: demo.mp4 6.9 MB

	demo.mp4 6.9 MB View Download

I can't spot the problem in the video - it looks like the user is double-tapping on, or just below the email link, nowhere near the phone number. What's the expected selection? 

I guess the video is a bit awkward, but the problem is that if the user wants to select something in a vicinity of a linkified text (url/email), then it's impossible because the click always triggers the url/email link

i.e. the word under the url, in this example

gsennton@, sorry about the confusing, the issue is when we are trying to long press to select "Dddddddddddfdfd" and triggers selection menu in Gmail, however, the link above, i.e., "www.google.com" got recognized.

Another way to repro:

1) Open WebView Shell
2) Go to www.wikipedia.com, find any article contains a lot of links.
3) Try to select any text which has a link below.

Expect: text get selected.
Actual: text is not selected, and HitTestResult triggered and it's vibrating.

Note that this is also reproducing in Chrome.
In Chrome Actual: text is not selected, and a modal related to the link shows up.

Yeah, I think this is working as intended since it's more likely that you want to click on / select the link than the neighbouring text.

Imagine text like

1600 Amphitheater Way
Mountain View
www.google.com

Both selections are valid - text and the link. And IMO it's not clear that clicking the link can justify making the address selection exceptionally hard. That's certainly been my experience. Sometimes I just want to copy something from an email to a chat, but can't because the click is snapped to the link so much.

Maybe a solution would be not to snap to the link on long-tap only on a tap/click?

I think our code is working as intended. I think the desired behavior is a matter of opinion--while zilka@ feels that selection is overly difficult, others might not and find it to be reasonable. In my personal experience, the wikipedia example is very usable.

Given that, I'm removing this from the webview bug queue and opening this up to any clank/webview engineer. I don't expect many engineers will actually have the motivation/time to work on this, as this isn't strictly a bug.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This happens in Chrome as well, so removing WebView component.

As stated in #c12, this doesn't seem like a real issue right now, I'll just close this one since no action could be taken.

Shimi, I must say I'm surprised that you find the GMail problem a matter of opinion. Literally everybody I spoke to about Smart Selection also asked if we are fixing the gmail text selection as well - referring to the behavior on the video in comment #1. Could you help me understand your thoughts please? How is overtriggering a click on a link a desired behavior?

Change the components to Blink>HitTesting since this is not very related to selection.

Lukas: Thanks for raising your concern. I would say people uses Smart Selection has a little bias here since it doesn't do what that user expected. But for majority of Android users, they still don't have Smart Selection available as O and above are only 21% for now. The slightly over triggering has it's usage as I understand. For a touch screen, especially a low resolution one, it is hard to touch the correct place. The current behavior is a relief for users.

I would admit that your point still has it's value as we need to accommodate new features such as Smart Selection. I was closing this since I feel if a user doesn't know Smart Selection feature or they don't have Smart Selection feature on that device (which is the major case), the highest priority of that touch is still to tap that link, so this is an intended behavior.

I'll defer the decision to Blink>HitTesting, it might need a UX study as this is more Human Computer Interaction problem.

I actually find this quite annoying, on desktop as well.
Although it may be useful and may help web accessible, it makes certain selection impossible.

I'm not sure if the trade-off here is well-balanced. I remember we didn't have this behavior a long time ago. Could we run a bisect and try to understand the rationale first?

Sorry, nvm about desktop case. This seems to be specific to android.

Shimi, thanks! It's not uncommon that people want to select some text that is adjacent to a link in text, and due to the current behavior they simply can't. Like Changwan suggested, is there a doc, discussion or analysis about this to understand the considerations back then?

Also, I don't think this is so much Smart Selection-related, but rather generally text-selection related.

This is fundamentally a UX question right now. The behavior could be changed. We need a compelling reason to change it, and I agree that some kind of usage analysis is needed.