1587557 - After dismissing the keyboard once, it cannot be brought up again for the same input with TalkBack, in both Fennec and Fenix

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect, P1)

Description

[Chris Peterson [:cpeterson]]

+++ This bug was initially created as a clone of Bug #1558289 +++

Bug 1558289 was fixed in GeckoView 69, but QA can still reproduce this screen reader bug in Fenix with GeckoView 70 Beta. Are they seeing a different problem?

Steps to reproduce

1. Open Fenix with a screen reader on.
2. Go to any page with a text input.
3. Focus the text input and activate it.
4. Close the keyboard.
5. Explore via touch the screen.

Expected behavior

It's possible to land on the text input.

Actual behavior

It's not possible to land on the text input, although it is when using navigation gestures.

This also applies to links; easy to verify in a page in which links are used to perform actions, like the column headers in Bugzilla. Tested with both ShinePlus and TalkBack.

This bug was originally reported in the Fenix issue tracker, but the bug is also reproducible on Fennec:
https://github.com/mozilla-mobile/fenix/issues/3197

Device information

Android device: TP-Link Neffos C5 Max (Android 5.1)
Fenix version: Build #11561807

Comment 1

[Chris Peterson [:cpeterson]]

Jamie, Eitan fixed similar bug 1558289 in GeckoView 69, but QA can still reproduce this screen reader bug in Fenix with GeckoView 70 Beta. Eitan is out on leave until December 23. Is there another Accessibility engineer that can investigate this GeckoView bug?

Comment 2

[James Teh [:Jamie]]

Chris, was the fix ever confirmed by QA in GeckoView 69? I'm trying to figure out whether we somehow regressed it in 70 or whether there's another bug here. What build of Fenix should we be testing here?

Marco, once Chris replies with the build we need to test, can you please test this?

To make things more interesting, all of the affected code was refactored in bug 1564549 for Firefox 71. Chris, I assume there'll be a Fenix release for Firefox 70, so we'll need to fix this for the old 70 code? (I'm somewhat unclear as to what builds of Fenix use what builds of GeckoView.)

I believe Fenix nightly is using GeckoView nightly now? if so, Marco, it'd be great to test this with nightly as well to see if the refactoring deals with this. That doesn't help us for 70, since uplifting the refactor is far too risky, but it'd be good to know regardless.

Comment 3

[Chris Peterson [:cpeterson]]

(In reply to James Teh [:Jamie] from comment #2)

Chris, was the fix ever confirmed by QA in GeckoView 69? I'm trying to figure out whether we somehow regressed it in 70 or whether there's another bug here. What build of Fenix should we be testing here?

Unfortunately, I don't think QA verified the fix in Fennec or GeckoView. I don't see any comments (in the original bug 1558289 or the Fenix bug report) from QA saying they verified the fix (in GeckoView 69 or 70).

To make things more interesting, all of the affected code was refactored in bug 1564549 for Firefox 71. Chris, I assume there'll be a Fenix release for Firefox 70, so we'll need to fix this for the old 70 code? (I'm somewhat unclear as to what builds of Fenix use what builds of GeckoView.)

The Fenix Release channel ships GeckoView Beta builds. (When Fenix eventually drops the "Preview" label, the Fenix team will switch to GeckoView Release channel builds. In the meantime, using Beta builds allows us to uplift GeckoView fixes to Fenix faster.) The current Fenix release already ships GeckoView 70 Beta. Fenix will ship GeckoView 71 Beta on November 12.

I believe Fenix nightly is using GeckoView nightly now? if so, Marco, it'd be great to test this with nightly as well to see if the refactoring deals with this. That doesn't help us for 70, since uplifting the refactor is far too risky, but it'd be good to know regardless.

The Fenix Nightly channel always ships GeckoView Nightly builds.

Comment 4

[Marco Zehe (:MarcoZ)]

I cannot reproduce the issue in Firefox Preview 2.1 (based on Gecko 70, built on 2019-09-23 according to the build ID). I can also not reproduce the issue in Firefox Preview Nightly, based on GeckoView 71, which contains the refactor from bug 1564549. For a breakdown of which versions exhibit the problem, and which don't, at least on my Google Pixel 3 running Android Q, see bug 1558289 comment #30.

Comment 5

[Chris Peterson [:cpeterson]]

Thanks for testing, Marco. Since you were able to reproduce the problem in Fennec Beta and Nightly (Gecko 68.2) but not Firefox Preview 2.1 or Nightly, I will ask Fenix QA to re-test.

Comment 6

[Marco Zehe (:MarcoZ)]

After bug 1558289 was uplifted to beta and nightly 68.2, and is fixed on both versions in that the item can now be explored and touched, I suggest to deal with the remaining bug here, which is:

1. Load https://google.com.
2. Touch, then double-tap the text field.
3. Find the Back button on the keyboard and dismiss it.
4. Touch the Entry field again and double-tap.
   • Expected: Keyboard should reappear.
   • Actual: It does not.

I can reproduce this on both Fennec 68.2b7 and Nightly 68.2a1, as well as Firefox Preview 2.1 based on GeckoView 70.0, and Preview Nightly, based on 71.0a1, which contains the refactor from bug 1564549, but still exhibits the bug.

Comment 7

[athomas]

Hey Chris, is this strictly a geckoview bug or is there anything needed on Fennec?

Comment 8

[James Teh [:Jamie]]

This affects both Fennec and GeckoView.

Comment 9

[Kevin Brosnan [Ex-Mozilla]]

We should not be fixing Fennec behavior. It is on ESR and Gecko changes can have unintended desktop effects.

Comment 10

[James Teh [:Jamie]]

Respectfully, there's not much choice if we want our Android users with disabilities to have a good experience. Fenix is coming, but it's not here yet as far as most users are concerned; it's still a "preview". If Fenix were out of preview next month, we wouldn't be even considering this. As far as I'm aware, that isn't the case.

FWIW, the part of the code which handles this is Android specific (i.e. it isn't used on desktop), so any fix we make here will almost certainly not have any impact on desktop.

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:Jamie, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 12

[James Teh [:Jamie]]

Contrary to my comment 1, it turns out this fix is not in Android specific code after all, which means it could theoretically have desktop impact unless we ifdef it.

Comment 13

[James Teh [:Jamie]]

Attachment: Bug 1587557: When activating an HTML text field via a11y APIs, if it already has focus, simulate a click.

Previously, HTMLTextFieldAccessible::DoAction just called TakeFocus().
When the field already has focus, TakeFocus() will do nothing.
However, the user might be activating this element because they dismissed a touch keyboard and want to bring it back.
Therefore, we must simulate a click so Gecko will bring up the keyboard.

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/59f1602fabd8
When activating an HTML text field via a11y APIs, if it already has focus, simulate a click. r=MarcoZ

Comment 15

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/59f1602fabd8