Conversation
See test results for failed build of commit e8e80b203d |
|
I'm not sure this would be a complete fix for #12624 - its original STR mentioned context menu in Outlook which depending on the version (unfortunately @CyrilleB79 forgot to mention version of his Outlook) can be UIA not IAccessible. Were you able to reproduce the Outlook issue? |
I could not reproduce this in my version of Outlook, I realised I mistakenly deleted a comment on the issue which mentioned that, so I've reposted it on the issue (see #12624 (comment)). @CyrilleB79 - could you confirm this PR build works to fix the issue on your version of Outlook, as well list the Outlook version info? |
feerrenrut
left a comment
There was a problem hiding this comment.
Looks good, can you confirm this fixes the Thunderbird case?
This may be overzealous and lead to less unwanted speech being cancelled.
I'm struggling to parse this, is the concern it will lead to more unwanted speech?
|
Yep, the Thunderbird case it what I tested with and I can confirm this fixes it. This is just noting that if any other scenario matches the check, speech won't be cancelled. I've rephrased the comment to
Because I updated the changes, this will need reapproval. |
Unfortunately NVDA 2021.2beta1 does not fix the Outlook issue. The version of Outlook is Outlook 2016 version 16.0.5182.1000. More details in #12624 (comment). |
Link to issue number:
Fixes #12624
Summary of the issue:
When opening a submenu in certain applications (like Thunderbird 78.12),
NVDA can process a menu start event after the first item in the menu is focused.
The menu start event causes a focus event on the menu, taking NVDA's focus from the menu item.
Additionally, the "menu" parent of the submenu item is not keyboard focusable, and is separate from
the menu item which triggered the submenu.
The object tree in this case (menu item > submenu (not keyboard focusable) > submenu item).
The focus event order after activating the menu item's sub menu is (submenu item, submenu).
Description of how this pull request fixes the issue:
Before cancelling speech, check that the focus is now on the parent menu.
Testing strategy:
Manual testing (note that this does not always occur and is hard to consistently reproduce):
On this PR: Confirm that this case has extensive logging when it occurs. When this event occurs confirm that the menu item is spoken, followed by the submenu. If you want to hear a beep on this event, change the logging to an error beep.
On 2021.1: Confirm that only menu item is spoken, as the seubmenu item is cancelled.
Known issues with pull request:
This may be an overzealous check. Speech in similar contexts that should be cancelled may continue to be spoken.
As such, debug logs are added to make handling new cases easier until the root problem of event processing is addressed.
Change log entries:
Bug Fixes
Code Review Checklist: