1615562 - Twitter jumps up to top of page when clicking "show more replies" in geckoview/fenix

Status: RESOLVED FIXED

(GeckoView :: General, defect, P1)

Description

[Jamie Nicol [:jnicol]]

In bug 1610952 and fenix #6176 there were reports of jumping around whilst scrolling on various different websites. In bug 1610952 I fixed an APZ-related issue present on bugzilla, but the bug is still present on twitter and appears to have a different cause.

From the original report:

Steps to reproduce:

Open https://mobile.twitter.com/jensimmons/status/1186639878169251840
Scroll down slowly

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

Actual results:

From time to time it jumps up
https://vimeo.com/367964926

Expected results:

Continuous scroll down

Comment 1

[Jamie Nicol [:jnicol]]

Wes found the following regression range (in bug 1610952 comment 12): https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e2ddce1acc62b1e1bf367a226b0cb64a8cec7e78&tochange=f94173bcd08dcb7059333c7e01ac8ab5c53de63e

I had been completely unable to reproduce, but after seeing that range I enabled talkback in the android accessibility settings, and now my twitter does jump quickly but in increments back up to the top after clicking "show more replies". (During which, the twitter icon in the top left corner is shown as focused, and the phone vibrates during each jump.)

Wes, do you have any accessibility settings enabled?

Eitan, Snorp, any ideas why this could be happening?

Comment 2

[Eitan Isaacson [:eeejay]]

I don't think the reporter is using TalkBack, at least not from the video. Jumping to the focused elements is expected behavior with TalkBack on. Can you share a video showing what you see?

Comment 3

[Wes Kocher]

I don't have accessibility services enabled (or if I do, I didn't intentionally turm them on).

I can try to get a video later today.

Comment 4

[Wes Kocher]

Oh, hrm, when I turn off Android 10's Live Transcribe feature in accessibility settings, I can't seem to reproduce this weird scrolling thing...

Comment 5

[Wes Kocher]

(Sorry for bugspam, I don't have edit permissions on this account)

I also have this issue with Tasker's accessibility access enabled, so I had to disable Tasker and Live Transcribe's accessibility services to make the problem go away.

Comment 6

[Wes Kocher]

Attachment: Video of twitter scrolling issues

Here's what I see scrolling on twitter. Everything is working as expected until I tap the "x more replies" links, then the view scrolls up, and further attempts at scrolling down will end up with the view returned to near the top of the page.

Comment 7

[Jamie Nicol [:jnicol]]

Attachment: Talback enabled

Here is a video of the behaviour with talkback enabled.

I can confirm I get the same scrolling to the top behaviour if I enable any accessibility settings in the android settings. This includes my password manager's (bitwarden) autofill service. Perhaps that could explain why a larger portion of users than expected might be affected, and they might not be aware of using accessibility services.

With talkback it shows the green border around focused elements, indicating it's trying to scroll to something at the top of the page?

Comment 8

[James Willcox (:snorp) ([e-mail]) (he/him)]

Looks like Eitan is on the case, clearing NI

Comment 9

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Emma helped me fix my 2fa issues on my main account, so I'm back using it. If you need anything from me going forward, needinfo this account, please. :)

Comment 10

[Eitan Isaacson [:eeejay]]

Thanks for all of this info! Looks like an accessibility caret change event is causing us to set accessibility focus on the top of the page.

Comment 11

[Eitan Isaacson [:eeejay]]

Attachment: Bug 1615562 - Don't move accessible focus if caret moved to an embedded char. r?Jamie!

In order to support find-in-page, we move a11y focus in Android
to the caret position. If a text container gets new children,
the doc caret will move to the offset of the new accessible.
We need to ignore these kinds of moves by detecting an embedded
char at the new position.

Comment 12

[Eitan Isaacson [:eeejay]]

Attachment: Bug 1615562 - Don't move accessible focus if caret is collapsed or not on focusable. r?Jamie!

If a keyboard-focused accessible is removed, the caret jumps to its
nearest ancestor. To avoid arbitrary accessibility focus moves, ignore
caret events that have no selection and are not focusable items.

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/429a80e396e7
Don't move accessible focus if caret is collapsed or not on focusable. r=Jamie

Comment 14

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/429a80e396e7

Comment 15

[James Willcox (:snorp) ([e-mail]) (he/him)]

Eitan, I now have a problem in Fenix where oftent the page will scroll all the way to the bottom upon load. It feels like this may be a regression from this patch. What do you think?

Comment 16

[Emily Toop (:fluffyemily)]

I will add that the behaviour :snorp is describing happens to me for every single page I load on Fenix now.

Comment 17

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

I was seeing it too yesterday, went away after I restarted Fenix.

Comment 18

[Eitan Isaacson [:eeejay]]

(In reply to James Willcox (:snorp) ([e-mail]) (he/him) from comment #15)

Eitan, I now have a problem in Fenix where oftent the page will scroll all the way to the bottom upon load. It feels like this may be a regression from this patch. What do you think?

Do you have any accessibility service enabled? What does about:support say about accessibility?

Comment 19

[Eitan Isaacson [:eeejay]]

:snorp and i chatted, and he doesn't have a11y enabled. I don't think the observed behavior is a regression from this bug. This should only affect users with a11y enabled.