1683747 - [Bug] When tapping the cursor in a comment box to the right of the last piece of text, it defaults to putting the cursor UP, to the nearest text above where you tap, rather than to the left at the end of the comment

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Emily Kager [:ekager]]

From github: https://github.com/mozilla-mobile/fenix/issues/14925.

Steps to reproduce

1. Set Firefox Day to default settings.
2. Go to Reddit.com and log in to your account. Twitter.com or any site with comments works, but for the sake of simplicity, we'll use Reddit.com for this demonstration.
3. Go to one of your lengthier comments that you have written in the past (needs to have at least two rows of text for the demonstration to work).
4. Select "edit" on the comment.
5. At the very end of the comment, select your cursor to the right of the last piece of text.

Expected behavior

In Chrome-based browsers, the cursor defaults to going to the left of where you tapped, to the end of the text, as you would expect. Here are two screenshots of what happens when you tap to the right of the last piece of text. Note: The red circle is where I tapped:
Chrome-based browser 1 screenshot:

Chrome-based browser 2 screenshot:

Actual behavior

In Firefox Day, when you tap to the right of the last piece of text, the cursor defaults to going UP, above wherever you tapped, instead of left. This is extremely disorienting, and not logical at all. You are constantly having to drag and drop the cursor to the end of the text from where you tapped, if you want to add something to the end of the comment. Here is a screenshot of what happens in Firefox 80. Note: the red circle is where I tapped:
Firefox Day screenshot:

Device information

• Android device: Samsung S8 (SM-G950FD Smartphone, latest version of Android operating system as of 2020/Dec/18)
• Fenix version: Firefox Day 84.1.1 (Build number 2015781795)

This issue has existed ever since the first version of Fenix Firefox.

Change performed by the Move to Bugzilla add-on.

Comment 1

[[ex-Mozilla] Agi Sferro | :agi]

Makoto do you know if this is still an issue?

Comment 2

[Makoto Kato [:m_kato]]

One of accessible caret issue. I will check this on Windows tablet too

Comment 3

[William]

(In reply to Agi Sferro | :agi | ni? for questions | ⏰ PST | he/him from comment #1)

Makoto do you know if this is still an issue?

Yes, this is still a major issue and has been ever since Firefox switched to Fenix on Android. Anyone who uses Firefox on Android will experience this flaw. If you want to see pictures of it, click the github link. All the photos of it are there.

https://github.com/mozilla-mobile/fenix/issues/14925

Comment 4

[Makoto Kato [:m_kato]]

(In reply to William from comment #3)

(In reply to Agi Sferro | :agi | ni? for questions | ⏰ PST | he/him from comment #1)

Makoto do you know if this is still an issue?

Yes, this is still a major issue and has been ever since Firefox switched to Fenix on Android. Anyone who uses Firefox on Android will experience this flaw. If you want to see pictures of it, click the github link. All the photos of it are there.

https://github.com/mozilla-mobile/fenix/issues/14925

Well, so I say that I think that this depends on "text frame" of above line. I guess that you tap decent/bottom space of font glyph of previous line. So we may need something adjustment of this situation for text frame or tap area coordinate.

Comment 5

[Makoto Kato [:m_kato]]

Moving this to Layout due to accessible caret issue. (or DOM's event issue?)

Comment 6

[Daniel Holbert [:dholbert]]

I can reproduce at https://paste.mozilla.org/ - if I enter a few lines of text, and then tap directly to the right of my last line of entered text, then it instead focuses that horizontal position in the previous line.

(If I tap somewhere further down, to the bottom-right, then it does what I expect and shifts the cursor to the very end.)

Theory: I would guessing this is due to us looking within some radius of your tap-location to guess the thing that you might've intended to tap; and in this situation where you're tapping in "dead space" directly to the right of the last line of text, then we do find a candidate tappable frame, on the previous line (since it falls within the radius that we search).

ni=TYLin who's worked on Accessible Caret stuff & might have more insight here.

Comment 7

[Ting-Yu Lin [:TYLin] (PST, UTC-8)]

This is a DOM event targeting issue. AccessibleCaret doesn't manipulate the click event, it simply shows the blue teardrop caret below the blinking carets after the clicking.

It's the pref ui.mouse.radius.enabled=true that makes the behavior difference on Android. If the pref is enabled on desktop, the same behavior can be reproduced in "Responsive Design Mode" (with touch simulation enabled).

ni=Botond who might know more about it.

Comment 8

[Botond Ballo [:botond]]

Suggested next steps to investigate:

• Turn on event retargeting logging (MOZ_LOG=event.retarget:5)
• Look at what frame is the initial target (as logged here)
• If possible, adjust heuristics to avoid re-targeting away from the initial target. I note that we already include textareas in this condition, so maybe the initial target is not the textarea, or something else goes wrong to cause re-targeting away from that?

Comment 9

[Makoto Kato [:m_kato]]

Thank you, Botond.

Comment 10

[Makoto Kato [:m_kato]]

Ah, I see. when using retarget, hit test area is expanded. So this area includes previous line in <textarea>, we will select previous line.

Comment 11

[Makoto Kato [:m_kato]]

https://treeherder.mozilla.org/jobs?repo=try&revision=7280b4fbdf1b40eadcad11e916bf4367cf8b66fb

Comment 12

[Makoto Kato [:m_kato]]

Attachment: Bug 1683747 - Don't use retarget when target is in <textarea>. r=botond

When using apz-retarget, hit test area is expanded. So if this area includes
previous line in <textarea>, we will select previous line. But when hit test
area is empty area of <textarea>, we should set caret to last character.

So I think that we should be disable apz-retarget if target is in <textarea>.

Comment 13

[Hiroyuki Ikezoe (:hiro)]

Makoto, would you mind updating the patch you posted before? Or do you want us to finish it up? It seems to me it just needs addressing one of Emilio's review comments. Thanks!

Comment 14

[Makoto Kato [:m_kato]]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #13)

Makoto, would you mind updating the patch you posted before? Or do you want us to finish it up? It seems to me it just needs addressing one of Emilio's review comments. Thanks!

Actually, I am busy. So I don't finish up this this cycle.

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9dc3a3190f37
Don't use retarget when target is in <textarea>. r=botond,emilio

Comment 16

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/9dc3a3190f37