Accessible focus not fired after dismissing OS print dialog
Categories
(Core :: Disability Access APIs, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox74 | --- | verified |
People
(Reporter: Jamie, Assigned: markosborne, Mentored)
References
(Blocks 1 open bug)
Details
Attachments
(3 files)
12.76 KB,
patch
|
jimm
:
review+
surkov
:
feedback+
|
Details | Diff | Splinter Review |
5.97 KB,
patch
|
Details | Diff | Splinter Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review |
When a file chooser dialog is closed and focus returns to the main application, an accessible focus event is not fired for the focused object. As far as accessibility clients are concerned, focus is stuck on the top level frame. Str: 1. Open and focus a document in Firefox. 2. Press control+o to display the Open dialog. 3. Press escape to close it. Expected: Focus should be fired on the document focused in step 1. Actual: The last focus event fired is on the top level frame. In chronological order, here is some event info from AccProbe: 1. When I alt+tab into Firefox, focus is fired correctly. These first two events are probably fired by Windows: EVENT_SYSTEM_FOREGROUND Event Time: 16:23:28:419, Accessible Name: Audio Description Trial | ABC Television - Nightly, Accessible Role: window, Accessible State: [focusable, moveable, focused, sizeable], Event Data: hwnd=12704D8 ;objectId=0; childId=0; threadId=3048; windowClass=MozillaWindowCl EVENT_OBJECT_FOCUS Event Time: 16:23:28:419, Accessible Name: Audio Description Trial | ABC Television - Nightly, Accessible Role: frame, Accessible State: [focusable, readOnly, opaque, moveable, active, sizeable], Event Data: hwnd=12704D8 ;objectId=-4; childId=0; threadId=3048; windowClass=MozillaWindowC This one is then fired by Firefox: EVENT_OBJECT_FOCUS Event Time: 16:23:28:497, Accessible Name: Audio Description Trial | ABC Television, Accessible Role: document, Accessible State: [focusable, readOnly, opaque, focused], Event Data: hwnd=12704D8 ;objectId=-4; childId=-169846016; threadId=3048; windowClass=Mozil 2. When I press control+o, I get the following: EVENT_SYSTEM_FOREGROUND Event Time: 16:23:29:636, Accessible Name: Open File, Accessible Role: window, Accessible State: [focusable, moveable, sizeable], Event Data: hwnd=F000F2 ;objectId=0; childId=0; threadId=3048; windowClass=#32770; EVENT_OBJECT_FOCUS Event Time: 16:23:29:651, Accessible Name: File name:, Accessible Role: text, Accessible State: [focusable, focused], Event Data: hwnd=1DB0116 ;objectId=-4; childId=0; threadId=3048; windowClass=Edit; ... 3. When I press escape, I get these two (again probably fired by Windows): EVENT_SYSTEM_FOREGROUND Event Time: 16:23:31:118, Accessible Name: Audio Description Trial | ABC Television - Nightly, Accessible Role: window, Accessible State: [focusable, moveable, focused, sizeable], Event Data: hwnd=12704D8 ;objectId=0; childId=0; threadId=3048; windowClass=MozillaWindowCl EVENT_OBJECT_FOCUS Event Time: 16:23:31:118, Accessible Name: Audio Description Trial | ABC Television - Nightly, Accessible Role: frame, Accessible State: [focusable, readOnly, opaque, moveable, active, sizeable], Event Data: hwnd=12704D8 ;objectId=-4; childId=0; threadId=3048; windowClass=MozillaWindowC However, no further focus events are fired unless I move the focus. This is particularly annoying after specifying a location for a file being downloaded/saved.
Reporter | ||
Comment 1•12 years ago
|
||
This also applies to the Print dialog.
Updated•12 years ago
|
Comment 2•12 years ago
|
||
Enn, I see neither DOM focus nor DOM blur events when system dialogs like Print dialog are open. Is it a bug?
Comment 3•12 years ago
|
||
Looks like WM_KILLFOCUS is sent before WM_ACTIVATE when the dialog opens so we don't receive a lowered event. Then, when the dialog is closed again, we get the right raise messages, but no events are fired because the focus manager thinks the window is already focused.
Comment 4•12 years ago
|
||
Enn, can you fix it or perhaps cc somebody who knows the area enough to get a fix?
Comment 5•12 years ago
|
||
This patch handles the windows messages in either order. In addition, it removes the blur suppression code, since I don't think it is needed any more (It was added to fix crash bug 68454 which I can no longer reproduce).
Comment 6•12 years ago
|
||
Try builds are at https://tbpl.mozilla.org/?tree=Try&rev=d7787295961e
Comment 7•12 years ago
|
||
Comment on attachment 673382 [details] [diff] [review] patch bug is fixed, mochitest passes. thank you!
Comment 8•12 years ago
|
||
Comment on attachment 673382 [details] [diff] [review] patch This patch allows WM_KILLFOCUS and WM_ACTIVATE to be sent in any order. It also removes the blur suppression since I can no longer reproduce the crash that warranted adding that code. I assume it applies only to the old focus code.
Comment 9•12 years ago
|
||
Doesn't appear to have any negative side effects. I'd suggest ample bake time if possible.
Updated•12 years ago
|
Comment 10•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/b6089a8b78d3
Comment 11•12 years ago
|
||
Apparently this has destabilized flash on youtube for some reason.
Comment 12•12 years ago
|
||
I've pushed a backout of this patch to m-c. It should be in the next nightly. https://hg.mozilla.org/mozilla-central/rev/3621795c03e1
Updated•12 years ago
|
Comment 13•12 years ago
|
||
(In reply to Jim Mathies [:jimm] from comment #11) > Apparently this has destabilized flash on youtube for some reason. The flash on youtube hangs disappeared for me on latest nightly, so this was likely culprit.
Comment 15•11 years ago
|
||
Neil, it continues to hit AT. Do you have a chance to get back to this in foreseeable future?
Comment 17•11 years ago
|
||
Nomination to 2013q3a11y bug since focus lost is major problem for users (I get continued asked about this by AT vendors). We need somebody to finish the patch. Thoughts/ideas are welcome.
Updated•11 years ago
|
Updated•11 years ago
|
Comment 18•11 years ago
|
||
(In reply to Marco Bonardo [:mak] from comment #13) > (In reply to Jim Mathies [:jimm] from comment #11) > > Apparently this has destabilized flash on youtube for some reason. > > The flash on youtube hangs disappeared for me on latest nightly, so this was > likely culprit. If no ideas how the patch could breaks things then does it make sense to give the patch another try just to check if those mystical flash problems were gone?
Comment 19•11 years ago
|
||
I guess this has to do with windowed flash right?
Comment 20•10 years ago
|
||
it keeps hitting us and we get more and more reports
Comment 21•9 years ago
|
||
Comment 3 and the patch describe more about the issues here if someone else wants to look at this.
Comment 23•5 years ago
|
||
This has been reported again on NVDA bug tracker here). Is there any chance for a fix? From an end user perspective this is quite annoying. Additionally previous patch got reverted due to the problems with Flash and it is now think of the past.
Comment 24•5 years ago
|
||
Any update?
This has yet again been reported on NVDA bug tracker (here).
Reporter | ||
Comment 25•5 years ago
|
||
Unfortunately, while no longer widespread, Flash is still supported and will be until 2020/2021. Regardless, we should try to fix this again or hack around it in the accessibility module if we can't; I agree it's super annoying.
Assignee | ||
Comment 26•5 years ago
|
||
Hi there. I'm new to Firefox dev, but do you mind if I have a look at this problem?
Comment 27•5 years ago
|
||
Not at all, go right ahead! :) Thank you for volunteering!
Assignee | ||
Comment 28•5 years ago
|
||
I've had a look (using VS2017 Enterprise) and the behaviour of the focus when coming back from an external dialogue is odd compared to Edge and Chrome. I am trying to identify specifically when focus goes to an external dialogue so that the element that last had the focus can be specially returned to rather than returning focus to the top layer, but not having too much luck yet. I'll keep tinkering.
Reporter | ||
Comment 29•5 years ago
|
||
Note that the patch in the attachments section above is worth looking at. While it probably won't apply cleanly now (code style changes among other bit-rot), I imagine the required fix will be pretty similar.
Assignee | ||
Comment 30•5 years ago
|
||
I think we might have addressed this bug. The patch from earlier was very helpful.
I tested successfully using NVDA and opening and closing a print dialog with https://codepen.io/antonpalinau/pen/MWWOoBJ
The focus returned to the print button after the dialog closed, and the down arrow then read out the next line.
The attached patch is based against the nightly build from 13 November. Is that going to be a problem?
Reporter | ||
Comment 31•5 years ago
|
||
Thanks very much. This looks pretty good. However the process for submitting code changed some time ago. We now use Phabricator for patch submission and code review. See this page for instructions:
https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html
You can set me (Jamie) as a reviewer. I'll need to add someone else from a different team for final review, as I don't have authority in this module of the code, but I will do an initial pass.
I noticed there are some code format issues here. Before you submit to Phabricator, you can automatically fix those with:
mach clang-format -c HEAD
Then amend the commit with any changes made.
Thanks again!
Assignee | ||
Comment 32•5 years ago
|
||
Interesting. I ran the following but no code was changed.
marko@mopc /c/mozilla-source/mozilla-central
$ ./mach clang-format -c HEAD
abort: unknown revision 'HEAD'!
marko@mopc /c/mozilla-source/mozilla-central
$ hg heads
changeset: 501607:b7641b3fb45e
tag: tip
parent: 501605:48a708577712
user: Mark Osborne <markosborne@pcblues.com>
date: Fri Nov 22 04:36:01 2019 +1100
summary: Focus on last focussed control after dialog closed.
marko@mopc /c/mozilla-source/mozilla-central
$ ./mach clang-format -c tip
marko@mopc /c/mozilla-source/mozilla-central
$ hg status
marko@mopc /c/mozilla-source/mozilla-central
$ ./mach clang-format -p widget/windows/nsWindow*
Processing 9 file(s)...
marko@mopc /c/mozilla-source/mozilla-central
$ hg status
marko@mopc /c/mozilla-source/mozilla-central
$
Reporter | ||
Comment 33•5 years ago
|
||
Ah, sorry about the HEAD thing; I use git here instead of hg, but that's obviously not the officially recommended config. :)
That's strange. You might also want to try:
mach lint --outgoing --fix
Failing that, the code review bot will pick up any issues when you submit to Phabricator, so no need for concern.
Assignee | ||
Comment 34•5 years ago
|
||
Assignee | ||
Comment 35•5 years ago
|
||
Hi there. Is my reply to your comment in the review visible to you?
Reporter | ||
Comment 36•5 years ago
|
||
The only comment I see from you is:
Hi there. Still trying to get lint and clang-format working. I think I have addressed the issues in the meantime, though :) Noticed a revision mentioned: 504148 - back out changes that broke eslint
Am I missing something?
Note that if you're making inline comments, you need to hit save draft on the inline comment, then submit to publish changes.
Comment 37•4 years ago
|
||
Pushed by mzehe@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/f55c0e5d9cdc Focus on last focussed control after dialog closed; r=Jamie,NeilDeakin
Comment 38•4 years ago
|
||
bugherder |
Reporter | ||
Comment 39•4 years ago
|
||
For some reason, this fixes the Print dialog but not the file chooser (Save As or Open) dialogs. I'm not sure why.
Assignee | ||
Comment 40•4 years ago
|
||
Should we open a new bug for the Save As and Open dialogs or re-open this one?
Reporter | ||
Comment 42•4 years ago
|
||
Adjusting summary because this only fixed the print dialog. Save and open dialogs now covered by bug 1606932.
Updated•4 years ago
|
Comment 43•4 years ago
|
||
Reproduced the initial issue using NVDA 2019.1 and Fx 70.0 (buildID 20191016161957) on Windows 10 x64.
Confirming the fix using Fx 74.0b5, build ID 20200218224219 under the same circumstances.
Description
•