open dialog does not show up in accessibility tree
Categories
(Firefox :: Disability Access, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox68 | --- | fixed |
People
(Reporter: samuel.thibault, Assigned: samuel.thibault)
Details
Attachments
(2 files)
While running firefox on Linux with the gtk front-end, selecting "File"->"Open File..." opens the standard "Open File" gtk dialog box.
This dialog box however does not show up in the AT-SPI tree: accerciser does not show it, and iterating over the tree with at-spi does not find it. For instance, the attached list.py script does not find it: it prints
Firefox
'frame' 'Enter Bug: Firefox - Mozilla Firefox'
while it should print
Firefox
'frame' 'Enter Bug: Firefox - Mozilla Firefox'
'file chooser' 'Open File'
AIUI, this is because when nsFilePicker::Open() creates the dialog box with gtk_file_chooser_dialog_new, it does not register it as a toplevel window for Accessible::EmbeddedChildCount() and alike to see it.
|
Assignee | |
Comment 1•5 years ago
|
||
Jamie, do you get the same issue on Windows?
(this poses problem for e.g. accessibility regression testing to be able to find the window)
|
||
Comment 2•5 years ago
|
||
No, I don't see this issue on Windows. However, in Windows, at the top level, accessibility is inherently linked to the Windows "HWND" (native widget) tree. That essentially means that any OS dialog will always show up in the tree; it's impossible for an app to prevent this.
Do you know how to fix this? Is registering this as a top level window some accessibility specific thing or could this have broader implications on GTK? Otherwise, I can try to figure out who we can ask at Mozilla re (non-a11y) GTK platform stuff.
|
|
Assignee | |
Comment 3•5 years ago
|
||
Ok, I see.
AIUI it is a question at the top-level "application" accessible level, which is currently not listing the dialog box as a child, and then gtk will properly do the rest.
I guess it would be a matter of making the nsFilePicker properly call nsINode:doInsertChildAt(), I however don't know how nsFilePicker plugs with the nsINode structure.
|
|
Assignee | |
Comment 4•5 years ago
|
||
Looking more into what is there, AIUI the file chooser accessibility is completely handled by gtk, not by firefox. That is noticeable because the widgets in it have the "toolkit" attribute set to "gtk", which firefox' atk glue does not do.
Put another way, AIUI what we'd need to fix this issue is to make the ApplicationAccessible managed by firefox have as additional child the FileChooserAccessible managed by gtk. While looking through the implementation, I found that toplevel_event_watcher catches gtk new windows, and makes the AddNativeRootAccessible call that does the AppendChild. What is special about the open file dialog is that its role is ATK_ROLE_FILE_CHOOSER, not ATK_ROLE_DIALOG, and only the latter is tested. I'll make & test a patch to add other roles which are dialog boxes (color chooser, etc.).
|
|
Assignee | |
Comment 5•5 years ago
|
||
(yes, adding ATK_ROLE_FILE_CHOOSER there fixes the issue)
|
|
Assignee | |
Comment 6•5 years ago
|
||
|
|
Assignee | |
Comment 7•5 years ago
|
||
The proposed patch is being tested on
https://treeherder.mozilla.org/#/jobs?repo=try&revision=fe5ec10248f22c8759c2301123482a5823d633e4
(though I really doubt there can be anything showing up as broken since it's really inside the atk glue which AFAIK is not tested by the firefox testsuite)
|
||
Updated•5 years ago
|
Pushed by jteh@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/ec885e52de73 atk: When watching for toplevel windows to manage as native root accessibles, Also look for refined roles of dialog boxes. r=Jamie
|
||
Comment 9•5 years ago
|
||
| bugherder | ||
|
||
Updated•5 years ago
|
Description
•