Closed Bug 1535325 Opened 1 year ago Closed 1 year ago

a11y: Orca gets control character strings in key events

Categories

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

65 Branch
All
Linux
defect

Tracking

()

VERIFIED FIXED
mozilla68
Tracking Status
firefox68 --- verified

People

(Reporter: samuel.thibault, Assigned: samuel.thibault)

Details

Attachments

(3 files, 1 obsolete file)

When typing e.g. control-tab, the string part of the key event sent to at-spi by firefox contains "\t" instead of "Tab", while pressing tab alone brings "Tab". The "\t" behavior is not useful to a screen reader (see https://mail.gnome.org/archives/orca-list/2019-February/msg00315.html), firefox should just consistently pass "Tab". I will submit a patch for this, which has already been applied to gtk for the same reason (see issue https://gitlab.gnome.org/GNOME/gtk/issues/1743 and MR https://gitlab.gnome.org/GNOME/gtk/merge_requests/630)

Assignee: nobody → samuel.thibault
Status: UNCONFIRMED → ASSIGNED
Component: Disability Access → Disability Access APIs
Ever confirmed: true
Priority: -- → P1
Product: Firefox → Core

P1 because Samuel announced an upcoming patch in comment #0. Thanks!

Attached patch proposed fix (obsolete) — Splinter Review

Here is the patch, as applied to upstream gtk2/3. It is being tested on

https://treeherder.mozilla.org/#/jobs?repo=try&revision=bbce60cd85d2345b6f39506918bd95627c59f1df

Mmm, I'm surprised, bugzilla doesn't let me add a ?Jamie for review, the combobox only shows '+' and '-' choices. Other comboboxes (data-review, superreview, a11y-review etc.) do propose the '?' choice

Flags: needinfo?(jteh)

Ok, I managed to create an account on phabricator, and could thus submit there.

Flags: needinfo?(jteh)
Attachment #9050977 - Attachment is obsolete: true
Pushed by jteh@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/a67a1d54f699
atk: Always convert control character events into key names r=Jamie
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
Flags: qe-verify+

Hi Samuel Thibault
I am trying to verify this issue and to be able to do that can you please help me with the steps that I need to follow in order to be able to reproduce it and also to see the issue is fixed?

Flags: needinfo?(samuel.thibault)

Hello,
This can be seen on the accessibility dbus. Use

dbus-send --session --dest=org.a11y.Bus --print-reply /org/a11y/bus org.a11y.Bus.GetAddress

to get the accessibility dbus address, e.g.

method return time=1561745300.028940 sender=:1.6 -> destination=:1.5 serial=3 reply_serial=2

string "unix:abstract=/tmp/dbus-Vz35Vk96nf,guid=9ddd4c5f0309be9e8916a7f15d165794"

then use dbus-monitor on that address:

dbus-monitor --address unix:abstract=/tmp/dbus-Vz35Vk96nf,guid=9ddd4c5f0309be9e8916a7f15d165794

Make sure to run firefox with export GNOME_ACCESSIBILITY=1 to get sure that firefox enables accessibility, and type control-tab, the event string should contain "Tab" (good behavior), and not "\t" (bad behavior)

Flags: needinfo?(samuel.thibault)
Attached file fx67Nightly.txt

(In reply to Samuel Thibault from comment #9)

the event string should contain "Tab" (good behavior), and not "\t" (bad behavior)

Environment:

    Ubuntu 16.04 x64
    orca --version 3.18.2
    Firefox 67.0a1 20190317213820 (affected)

I've first attempted to reproduce the issue on an affected version (67.0a1 20190317213820), didn't see anything that would resemble "\t"(attaching the full log for further debugging), I see the Tab event. Is there something missing in the STR or something amiss in my setup to be able to reproduce the issue on the affected version?

Flags: needinfo?(samuel.thibault)

Sorry, I should have mentioned that dbus might not be converting the control characters into printf-like strings. In your attached file, one can indeed find

string "\t"

where by \t I mean the tab character, not '' and 't'.

Flags: needinfo?(samuel.thibault)
Attached file logs.zip

Sorry Samuel for still pinging you on this, I still haven't figured out what to look for in the logs (before and after). I can hear the difference though :), but I still want to make sure we're wittingly tagging the verify status. Could you please take a look over the attached output dbus logs before and after the fix.

before fix build: 67.0a1 20190315135105
after fix build: 68.0 20190705220548

Flags: needinfo?(samuel.thibault)

Sure, no problem :)

In the "old" file, we can find device events containing

string "	"

(where ' ' above is a tab character), while in the "new" file we can not find it, so the bug is indeed fixed between "old" and "new".

Flags: needinfo?(samuel.thibault)

(In reply to Samuel Thibault from comment #13)

Sure, no problem :)

In the "old" file, we can find device events containing

string "	"

(where ' ' above is a tab character), while in the "new" file we can not find it, so the bug is indeed fixed between "old" and "new".

Cool, now makes sense. It was staring at me all along. Tanks for the help.

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.