1535325 - a11y: Orca gets control character strings in key events

Status: VERIFIED FIXED

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

Description

[Samuel Thibault]

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)

Comment 1

[Marco Zehe (:MarcoZ)]

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

Comment 2

[Samuel Thibault]

Attachment: proposed fix

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

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

Comment 3

[Samuel Thibault]

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

Comment 4

[Samuel Thibault]

Attachment: Bug 1535325 atk: Always convert control character events into key names r=Jamie

Comment 5

[Samuel Thibault]

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

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a67a1d54f699
atk: Always convert control character events into key names r=Jamie

Comment 7

[Oana Pop-Rus]

https://hg.mozilla.org/mozilla-central/rev/a67a1d54f699

Comment 8

[Marcela (Please NI request to Brindusa Tot)]

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?

Comment 9

[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)

Comment 10

[Adrian Florinescu [:aflorinescu]]

Attachment: 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?

Comment 11

[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'.

Comment 12

[Adrian Florinescu [:aflorinescu]]

Attachment: 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

Comment 13

[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".

Comment 14

[Adrian Florinescu [:aflorinescu]]

(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.