Emoji panel and clipboard history: locate actual items when traversing the elements for element selected event#11485
Conversation
… for consistency with other files)
… and input panel Automation Id to react to various parts of modern input facility. A dedicated input panel element will be used as a starting point for traversing modern keyboard interface. Along with this, rename childAutomationID to input panel Automation Id to better communicate the fact that window open event will be using Automation Id to detect different modern input features and react accordingly.
…clipboard history to account for changes in Version 1903 on some systems. Re nvaccess#10377. Refined element traversal in window open event: * Emoji panel: in Version 1903 (and on some systems), something other than emoji items are selected, particularly when People emoji group opens and skin tone modifier is somehow selected. * Clipboard history: if clipboard is empty, clipboard status text isn't announced due to moving to a different element.
…elves rather than parent lists. Re nvaccess#10377. Rather than calling element selected event on emojis list or clipboard history list, descend one more level (or in case of People emoji group, actual emojis list) so the event can deal with items themselves. This also means element selected event won't have to worry about traversing the elements tree one more time.
…executeEvent. Rather than executing UIA element selected event directly, use event handler's execute event function to schedule this event. This allows event handling features from NVDA to respond to this event.
…separate list, along with using isWin10 function. Rather than using a build number, use winVersion.isWin10 function to check Windows 10 releases. Also, separate 1709 and 1803 emoji panel Automation Id's to a separate list.
|
Blocked by #11562 due to edits to window open event handler. Thanks. |
|
Does this also fix the emoji panel on 21H1 builds? |
|
Hi, the new design? Can’t verify that, as I didn’t get the new design yet (it is rolling out to a subset of dev Insiders). Thanks.
|
… UIA IME candidate panel check. Re nvaccess#10377. IME candidate panel check already assigns a dedicated variable to obj.firstChild, making input panel variable assignment redundant. Also, rename input panel Automation Id back to childAutomationId.
|
Hi, Thanks. |
|
I'm asking @LeonarddeR for a review because he was also reviewing #10378 |
LeonarddeR
left a comment
There was a problem hiding this comment.
Could you please especially consider cases where you're traversing objects without checking whether the objects exist?
| and config.conf["inputComposition"]["autoReportAllCandidates"] | ||
| ): | ||
| try: | ||
| self.event_UIA_elementSelected(obj.firstChild.firstChild.firstChild, nextHandler) |
There was a problem hiding this comment.
I rather see checking every child's boolean value rather than doing a try/except here. That's just my personal preference.
|
Hi, try/except was done for compactness and for readability. I admit that the code under review came from my add-on, so I’ll do something about these from both sides. Thanks.
|
…omment clarification. Re nvaccess#10377. Reviewed by Leonard de Ruijter: split lines with multiple statements, clarify that 'some systems' refer to non-English builds of Version 1903 (May 2019 Update) and later.
…esent. Re nvaccess#10377. Suggested by Leonard de Ruijter: when assigning emoji item, check each emoji panel level (emoji list header, grouping, emoji items/skin tone modifier list) to make sure child objects are present (not None). In case skin tone modifiers list is selected, before moving to the next object (emoji item), make sure it is even present. This avoids a try/except statement and is used to force NVDA to announce something rather than staying silent of attribute error is raised in the future due to modern keyboard UI changes.
…ncy with UIA IME candidates window.
|
Hi, It was pointed out a few days ago that the emoji panel was redesigned in a dev channel WIP build. I'm sorry to inform everyone that the redesigned emoji panel cannot be used with NVDA at all - no announcements with both Narrator and NVDA when the panel opens, so for the purposes of this PR, the redesigned emoji panel is out of scope. Thanks. |
|
@josephsl I'm on the most recent insider preview build, and the panel seems to work correct again. Does this pr needs to be revised for this? At least, I think I'd prefer it if you check the current changes against an insider build before continuing with this. |
|
Hi, nope. There is an issue with dev channel build that has to do with categories firing element selected event but that can be handed by Windows 10 App Essentials add-on and is beyond the PR scope. Thanks.
|
|
Hi all, Ready for another review if needed. Thanks. |
|
Hi, Update: build 21277 (rs_prerelease, released December 10) brought back modern emoji panel. As for my assessment on it, see the above comment (brought screen readers to their knees again). Therefore for the purposes of this PR, the new emoji panel will not be supported in this PR. Thanks. |
|
Hi, One more change: to prepare for Python 3.10's pattern matching syntax and readability, when checking for 1709 and 1803 emoji panel, Automation Id will be checked before build range; no changes to semantics whatsoever. Thanks. |
…ore build range for consistency with the rest of UIA window open event.
|
closing/reopening to trigger a build |
|
Thanks @josephsl, Would you be able to add system tests to smoke test the emoji panel and clipboard history? I understand your capacity is changing right now (congratulations!) so let us know if the work needs to be passed over. Some simple tests as mentioned in the manual testing would be good to start with and we can add more later as needed. |
|
Hi, I might not be able to add system tests to smoke this. The biggest concern is the fact that emoji panel UI is changing in Cobalt releases (build 21300 and later) which will cause tests to fail unless winVersion.getWinVer().build is checked first. The test procedure should be:
NOtes on Cobalt emoji panel:
Making matters even more complicated is a possibility that Version 21H2 client and server code might be different - currently latest Server 2022 preview (Version 21H2) code is based on work done last year (iron/fe_release/build 203xx), whereas client is based on work being done this year (cobalt/co_release/build 213xx). If it turns out Version 21H2 code between client and server are different, and if Server 2022 will be based on Iron (build 203xx), then it might be a bit easier to smoke test emoji panel (although this means dealing with an extra UIA element selected event being fired somehow); all this is thrown out the window if Server 2022 will be based on Cobalt and Appveyor decides to use Server 2022 VM, in which case smoke test cannot be added. I know how complicated the picture is (this is one of the personal gripes with what's happening at Microsoft build labs, but such things are expected; this is one of those perks and stresses of being a Windows Insider and trying to guess what Microsoft will do in the short term). Hope this helps. Thanks. |
|
Hi @josephsl, Thanks for the detailed notes. I think for now we can just write a system that passes for Iron (assuming that it would currently work for AppVeyor and personal machines). If the system test starts to fail we can exclude it from builds so that AppVeyor continues to pass, and prioritise work to support Cobalt if it hasn't been done yet. |
|
Hi, I expect Cobalt won’t be finalized until mid-June, so perhaps it would be best to defer support for Cobalt emoji panel until fall (2021.2) at the earliest, with system tests planned for summer (I think I might not be able to write tests, but would be able to help plan things a bit before starting graduate studies). Thanks.
|
|
Blocked by #12487. Thanks. |
|
Hi, agreed about system tests – let’s get the testing party started with alpha builds!!! Thanks (this will lessen the burden on Windows App Essentials add-on significantly).
|
Hi,
A reboot of #10378 with updated assumptions and lessons learned:
Link to issue number:
Fixes #10377
Summary of the issue:
In Version 1903 and later, on some systems, when emoji panel and clipboard history opens, wrong items are announced.
Description of how this pull request fixes the issue:
Refined element traversal strategies when emoji panel and clipboard history opens. Also performed lints and changed cachedAutomationID to UIAAutomationId, along with using dedicated input panel and input panel Automation Id variables to react to window open event.
Testing performed:
Tested via Windows 10 App Essentials for several months:
Known issues with pull request:
There is no way of telling NVDA that modern input elements are shown on screen (that's reserved for a future pull request; see #11454 for details).
Change log entry:
Same as #10378.
Thanks.