1544133 - Placing a cursor in a ContentEditable causes scroll position to be reset, rendering it almost unusable

Status: RESOLVED DUPLICATE of bug 1622894

(Core :: DOM: Selection, defect, P2)

Description

[ejsanders]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.103 Safari/537.36

Steps to reproduce:

Open a page with a ContentEditable area that is taller than the page, e.g. https://edg2s.github.io/content-editable-sandbox/ (fill in many lines of text in the right hand box, so there is more than one page of content), or open Wikipedia's VisualEditor before we deploy our workaround (https://gerrit.wikimedia.org/r/#/c/VisualEditor/VisualEditor/+/502851/).

Scroll down a bit and place your cursor.

Actual results:

The page scrolls back to the top of the contentEditable box.

This also happens every subsequent time you place the cursor, rendering the editor almost unusable.

Expected results:

The page should not scroll when placing a cursor (other than maybe to keep the cursor in view).

Comment 1

[ejsanders]

Bug 1490126 sounds suspiciously similar.

Comment 2

[ejsanders]

As that bug is marked a duplicate of a ticket that was resolved in 67.0a1, I tested this in beta & nightly, and it is still broken in 67.0b9 & 68.0a1.

Comment 3

[Stefan Deiac]

Hello, thanks for your report.
I can confirm that your issue is reproducible using Nexus 9 (Android 7.1.1) and Huawei P9 Lite (Android 6).
Builds:

• Nightly 68.0a1 (2019-04-14);
• Beta 67.0b9;
• Release 66.0.2.

Notes:

• Not reproducible on Chrome.

Comment 4

[Marcia Knous [:marcia]]

Moving this to Core | Selection with the hope that is a better place for it to be triaged.

Comment 5

[Hsin-Yi Tsai (she/her) (REO Fx 129) [:hsinyi]]

Resetting the priority to let it be on our normal triage radar.

Is this Android only issue? I didn't manage to reproduce it on Windows.

Comment 6

[Hsin-Yi Tsai (she/her) (REO Fx 129) [:hsinyi]]

Emilio, could you please help me understand if Layout: Scrolling and Overfolow a better component for this? Thanks!

Comment 7

[Emilio Cobos Álvarez (:emilio)]

Maybe Ting-Yu is better at judging that. Ting-Yu, do you know of some android-specific code that could cause this?

It's likely that the right component is either Editor or Layout, but probably the first.

I indeed cannot reproduce this at all on Desktop.

Comment 8

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

I don't know anything related to that off the top of my head without further debugging. It looks like some kind of mechanism trying to scrolling the selection into the viewport. FWIW, the bug is still reproducible even if I turn off layout.accessiblecaret.enabled_on_touch.

I'm going to cc masayuki and botond since they're likely to know more.

Comment 9

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

AFAIK, editor does not have Android specific code. Looks like that the scroll occurs after a while of changing selection/focus. APZC?

Comment 10

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Even if I try to reproduce this with mouse on Android, I can reproduce this too. When I click with mouse, there are no touch events, nor accessible caret. Additionally, moving caret with arrow keys on VKB and swiping accessible caret does not cause this bug. So, somebody handles click and tap events specially on contentediable elements.

Comment 11

[Botond Ballo [:botond] [away until Aug 12]]

This is a regression.

Comment 12

[Botond Ballo [:botond] [away until Aug 12]]

This is the regression window I get:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5c48b5edfc4ca945a2eaa5896454f3f4efa9052a&tochange=72ee4800d4156931c89b58bd807af4a3083702bb

Does anything from that window seem relevant? (We don't have inbound builds going back that far to get a more accurate window.)

Comment 13

[Emilio Cobos Álvarez (:emilio)]

https://hg.mozilla.org/mozilla-central/rev/946c1489acdddfd0f83fb790e9d082fcf4921b23 looks potentially related.

Comment 14

[Hsin-Yi Tsai (she/her) (REO Fx 129) [:hsinyi]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #13)

https://hg.mozilla.org/mozilla-central/rev/946c1489acdddfd0f83fb790e9d082fcf4921b23 looks potentially related.

Thanks for the window.

Hey Randall, do you know what's up here? Thanks!

Comment 15

[Randall Barker [:rbarker]]

It's been a long time since I looked at this but that particular patch should just be changing the dispatcher used.

Comment 16

[Botond Ballo [:botond] [away until Aug 12]]

ejsanders, would you be able to re-test this with a recent Fenix release or nightly? I suspect it was fixed by bug 1622894.

Comment 17

[ejsanders]

Confirmed working in FF 82. Thanks!

Comment 18

[Botond Ballo [:botond] [away until Aug 12]]

Great, thanks for confirming! I'll close this as a dupe.