User Agent: Mozilla/5.0 (Android 7.1.1; Tablet; rv:68.0) Gecko/68.0 Firefox/68.0

Steps to reproduce:

1. Open reddit.com/r/firefox
2. Resquest desktop site
3. Tap on a link
4. Zoom in
5. Long press on a word

Actual results:

A different word is selected

Expected results:

The proper word is selected

Would you mind taking a look?

I would mind, actually. Please let the module triage owner triage the bug normally instead of needinfo'ing people unless there's some exceptional circumstance requiring this bug to prioritized ahead of everything else.

My apologies.

I can reproduce the issue. I suspect a relation to bug 1540545.

It's worth noting that I am not able to reproduce this on Bugzilla.

What type of environment is Reddit?

(In reply to Botond Ballo [:botond] from comment #4)

I suspect a relation to bug 1540545.

Nope. The problem there is specific to dragging the caret. Here, the long-press already produces incorrect results.

This is not easy to debug due to the complexity of the page. Having a reduced testcase would help. Having desktop zooming would also help, both for debugging and for preparing a reduced testcase.

I'm noticing a backward L element overlapping...

Is Bug 1298218 related?

Sorina, can you try looking for a regression range? A reduced test case would also be great if possible

Hi all,

I found a regressions range:
Last good revision: e52f3a7ece193bdf93ac2c87796cad693bb1e882
First bad revision: 07cdc29645eeffc12a018f5d4a89e61be6ed9529

Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=e52f3a7ece193bdf93ac2c87796cad693bb1e882&tochange=07cdc29645eeffc12a018f5d4a89e61be6ed9529

Liz, if a single step is missed, the issue no longer reproduces.
The device tested with was Samsung Galaxy Tab S3 (Android 8.0).

Thank you!

The identified regression range is wrong, because the change is in desktop-only code (and even on desktop the code change is more like a comment change - no behavioral difference).

mirabela: Please try to find a new regression range.

Hi,

We found another regression range:
Last good revision: c6e7b65bf8b02a32a6c1d583eb1d79e3116d692d
First bad revision: bac4139e4ff9b3071e1ce17113ac65ed1d8e8598

Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=c6e7b65bf8b02a32a6c1d583eb1d79e3116d692d&tochange=bac4139e4ff9b3071e1ce17113ac65ed1d8e8598

So, apparently, before 19th of August 2018, the long-tapped word was selected, but the selection handles were displayed in a different area (please see attached screenshot). After this date, the long-tapped word was not selected at all, as the reporter described.

Thank you,

Thanks for the regression window. The fact that bug 1465616 was the regressing bug might give me some ideas for how to construct a small test case that reproduces this, without having to try to reduce the Reddit page.

(In reply to csheany from comment #8)

I'm noticing a backward L element overlapping...

I noticed this as well. Could I ask you file a separate bug about this?

You could :)

Se also Bug 1546222

Will fixing this in the current state address the previous behavior or should that be a seperate bug as well?

(In reply to csheany from comment #16)

Will fixing this in the current state address the previous behavior

I hope so. In the event it doesn't, I'll file a follow-up a bug for the remaining issue.

This may have been fixed by bug 1565512. Unfortunately, it's hard to confirm this, since:

• We don't build build Fennec nightlies from trunk any more
• Firefox Preview nightlies currently use GeckoView builds from the 69 branch, not trunk
• GeckoView Example nightlies are built from trunk, but they don't support switching to desktop mode (bug 1573207)

Confirmed via a local Fennec build. I'm going to dupe this over.