Respect UIA Notification processing flag#9466
Conversation
|
Hi, Note that in order to properly test this, a binary version must be built. Thanks. |
|
I was able to test this from source, at least when NVDA is running with admin privileges. i admit, it's not the best way to work, but for these cases it helps a lot.
|
|
Hi, true. I used a launcher build to test this, and it works as advertised (with all add-ons turned off, of course). Also, note that volume announcement won’t work if File Explorer is not the foreground app – you also need to modify the app module for Explorer to let this work, too. Thanks.
From: Leonard de Ruijter <notifications@github.com>
Sent: Monday, April 8, 2019 10:27 PM
To: nvaccess/nvda <nvda@noreply.github.com>
Cc: Joseph Lee <joseph.lee22590@gmail.com>; Comment <comment@noreply.github.com>
Subject: Re: [nvaccess/nvda] Respect UIA Notification processing flag (#9466)
I was able to test this from source, at least when NVDA is running with admin privileges. i admit, it's not the best way to work, but for these cases it helps a lot.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub <#9466 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AHgLkN1X52tgdog-lWPFxKmdlNJG2WCQks5vfCSVgaJpZM4chwmj> .
|
|
Actually, I like it that the Explorer notifications are limited to Explorer only, so I have no intensions to change this behavior.
|
feerrenrut
left a comment
There was a problem hiding this comment.
Ok, I think it will be important to look for regressions in older versions of windows, and earlier windows 10 builds. Can you watch for this?
In the Windows 10 May 2019 update, NVDA no longer speaks many volume notifications if changing the volume with hardware buttons when Windows Explorer has focus. (#9466)
|
I think we should only watch for possible regressions from WINDOWS 10 FCU and above. Older versions don't implement this. |
|
NVDA is broken by obturating notion. |
| if displayString: | ||
| if notificationProcessing in (UIAHandler.NotificationProcessing_ImportantMostRecent, UIAHandler.NotificationProcessing_MostRecent): | ||
| # These notifications superseed earlier notifications. | ||
| # Note that no distinction is made between important and non-important. |
There was a problem hiding this comment.
With the merging of #7599 we should now be able to distinguish between important and non-important notifications (possibly with speech priorities) instead of cancelling speech outright. Is this worth doing?
|
Hi, one potential user experience issue is announcement of outdated notifications. Consider a real-time notification that’s being announced, then preempted by a more important notification. Once the latter finishes, the old notification announcement resumes, and this may contain information that is actually outdated (at least based on brief testing I did with priorities). Thanks.
|
Maybe fixable with cancellable speech? Or is this actually intended behaviour? |
Link to issue number:
None
Summary of the issue:
IN the Windows 10 may 2019 update, Microsoft decided to announce volume changes using UIA notifications. This means that these volume notifications are announced when the keyboard focus is in Explorer. However, due to the way NVDA handled UIA notifications before this pr, these volume change notifications were queued one after another, resulting into lots of notifications being announced, including duplicates.
Description of how this pull request fixes the issue:
UIA notifications have a notificationProcessing parameter. When this parameter is set to one of the most recent NotificationProcessing constants, speech is cancelled before announcing the new notification.
Testing performed:
Tested witth volume changes in Windows 10 1903. Only the last notification is now spoken.
Known issues with pull request:
None
Change log entry: