1542832 - Text isn't properly selected after zooming in

Status: RESOLVED DUPLICATE of bug 1565512

(Firefox for Android Graveyard :: Text Selection, defect, P2)

Description

[csheany]

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

Comment 1

[csheany]

Would you mind taking a look?

Comment 2

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 3

[csheany]

My apologies.

Comment 4

[Botond Ballo [:botond]]

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

Comment 5

[csheany]

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

What type of environment is Reddit?

Comment 6

[Botond Ballo [:botond]]

(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.

Comment 7

[Botond Ballo [:botond]]

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.

Comment 8

[csheany]

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

Is Bug 1298218 related?

Comment 9

[Liz Henry (:lizzard) (relman/hg->git project)]

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

Comment 10

[miralobontiu]

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!

Comment 11

[Rob Wu [:robwu]]

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.

Comment 12

[miralobontiu]

Attachment: Screenshot_20190419-165316[1].png

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,

Comment 13

[Botond Ballo [:botond]]

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.

Comment 14

[Botond Ballo [:botond]]

(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?

Comment 15

[csheany]

You could :)

Se also Bug 1546222

Comment 16

[csheany]

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

Comment 17

[Botond Ballo [:botond]]

(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.

Comment 18

[Botond Ballo [:botond]]

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)

Comment 19

[Botond Ballo [:botond]]

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