-
-
Notifications
You must be signed in to change notification settings - Fork 659
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
2020.2beta2 does not read Windows 10-2004 Open With dialogs automatically #11335
Comments
Hi, confirmed, caused by the fact that NVDA does not notice the dialog right away (it is the child of the “pane” that shows up). I’ll come up with something via Windows 10 App Essentials add-on (might not be trivial to fix), then post a PR based on additional findings. Thanks.
From: Luke Davis <notifications@github.com>
Sent: Saturday, July 4, 2020 9:32 PM
To: nvaccess/nvda <nvda@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Subject: [nvaccess/nvda] 2020.2beta2 does not read Windows 10-2004 Open With dialogs automatically (#11335)
Background
I had a URL shortcut on my desktop for some time. After upgrading Windows from 1909 to 2004, I found that the URL shortcut no longer seemed to work. Not surprising--my network shares no longer work either, for some reason. But rather than giving an error, it appeared that nothing happened when opening it. Alt+tab wouldn't recognize that any new windows were open.
I finally thought to try a title command after opening the URL shortcut, and found out that I was in an "Open with" pane.
Steps to reproduce:
Because you may not actually have this problem, it will be difficult to reproduce exactly.
Running assoc .url=, in an administrative command prompt, no longer effectively works to remove existing associations, even though it claims to.
To reproduce the result, however, you can:
1. Press Windows+r
2. Type notepad c:\users\your_user_name\testfile.fakeextension, and press enter.
3. Save the file and exit notepad.
4. Press Windows+R.
5. Type c:\users\your_user_name, and press enter.
6. Navigate to the file you just created, and press enter.
Actual behavior:
NVDA will say "pane".
Additionally, pressing the arrow keys while at this stage, will result in nothing being spoken, which I consider a related bug (even though that behavior existed in the former "How do you want to open this file?" dialog in 1909 and earlier). It should place focus in the application selector.
Expected behavior:
1. NVDA indicates more obviously, for example by actually reading the window, that you are in a dialog requesting action. That was the result in earlier versions of Win 10.
2. Focus should be set to the application chooser without manual interaction to get it there.
System configuration
Windows 10, Version 2004 (OS Build 19041.329).
NVDA 2020.2beta2 installed. Didn't test other versions on W10 2004.
Rebooted, and tried Com Reg Fix.
Tried with no add-ons, and with latest stable Win 10 App Essentials loaded.
Additional information
I tested NVDA 2020.1 on Windows 10 version 1909. I confirmed the working case of "How do you want to open this file?". Since Windows 10 version 2004 has changed the nature of the window here, I saw no point in testing further on 2004 with older NVDA versions.
Anyone should be able to replicate this, but if you want a log, here it is <https://github.com/nvaccess/nvda/files/4874423/nvda-old.log> .
Developer info for the Window, upon initial open, is as expected:
INFO - globalCommands.GlobalCommands.script_navigatorObject_devInfo (23:28:57.855) - MainThread (2788):
Developer info for navigator object:
name: None
role: ROLE_PANE
roleText: None
states: STATE_FOCUSABLE, STATE_FOCUSED
isFocusable: True
hasFocus: True
Python object: <NVDAObjects.IAccessible.IAccessible object at 0x07652630>
Python class mro: (<class 'NVDAObjects.IAccessible.IAccessible'>, <class 'NVDAObjects.window.Window'>, <class 'NVDAObjects.NVDAObject'>, <class 'documentBase.TextContainerObject'>, <class 'baseObject.ScriptableObject'>, <class 'baseObject.AutoPropertyObject'>, <class 'object'>)
description: None
location: RectLTWH(left=760, top=270, width=392, height=326)
value: None
appModule: <'openwith' (appName 'openwith', process ID 13464) at address 12f53d0>
appModule.productName: 'Microsoft® Windows® Operating System'
appModule.productVersion: '10.0.19041.1'
TextInfo: <class 'NVDAObjects.NVDAObjectTextInfo'>
windowHandle: 394708
windowClassName: 'Shell_Flyout'
windowControlID: 0
windowStyle: -1778384896
extendedWindowStyle: 8
windowThreadID: 8812
windowText: ''
displayText: ''
IAccessibleObject: <POINTER(IAccessible) ptr=0x5c32708 at 13043f0>
IAccessibleChildID: 0
IAccessible event parameters: windowHandle=394708, objectID=-4, childID=0
IAccessible accName: None
IAccessible accRole: ROLE_SYSTEM_CLIENT
IAccessible accState: STATE_SYSTEM_FOCUSED, STATE_SYSTEM_FOCUSABLE, STATE_SYSTEM_VALID (1048580)
IAccessible accDescription: None
IAccessible accValue: None
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub <#11335> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB4AXEFKMMAPLJK3O2I5HZDRZ765NANCNFSM4OQWF6WA> .
|
@josephsl wrote:
Hi, confirmed, caused by the fact that NVDA does not notice the dialog right away (it is the child of the “pane” that shows up). I’ll come up with something
via Windows 10 App Essentials add-on (might not be trivial to fix), then post a PR based on additional findings. Thanks.
It notices the pane though, as evidenced by the internal appModule for the
dialog being launched (according to the dev info, anyway).
The immediate cluge idea that came to my mind, therefore, was in that appModule,
to simulate a tab key press. That both moves into the dialog, and speaks it, as
should have happened first.
That is inelegant in the extreme, but it would solve the immediate problem I
believe.
|
Hi, Ah, turns out this is another one of those cases where we do need to tell NVDA that we are indeed dealing with a UIA window. Technical: the window that gets "focused" when Open With dialog opens is actually a UIA element in disguise. Therefore the app module must tell NVDA that the window class name of "Shell_Flyout" is a good UIA window (another side effect is that NVDA will no longer say "pane" when Open With dialog opens). Note that this must be tested in older Windows 10 releases, and if it doesn't work, we need to set minimum Windows 10 version for this routine to 2004 (good thing Version 2004 is now included in Windows 10 build map). I'll provide a Windows 10 App Essentials update that fixes this problem. Thanks. |
Hi, Resolved via Windows 10 App Essentials add-on July 5th development snapshot, and will be resolved via both a pull request and WinTenApps 20.07.1 stable version. Thanks. |
Well, I can test 1909 and one of the middle of the road 16-17 releases.
|
Hi, I recommend testing on 1709 and later, as 1703 and earlier is no longer supported for consumers and businesses. Note that the fix I wrote will work with Version 2004 and later (this is intentional based on the initial report). Thanks.
From: Luke Davis <notifications@github.com>
Sent: Saturday, July 4, 2020 11:08 PM
To: nvaccess/nvda <nvda@noreply.github.com>
Cc: Joseph Lee <joseph.lee22590@gmail.com>; Mention <mention@noreply.github.com>
Subject: Re: [nvaccess/nvda] 2020.2beta2 does not read Windows 10-2004 Open With dialogs automatically (#11335)
Well, I can test 1909 and one of the middle of the road 16-17 releases.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#11335 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB4AXEHCK7U3EK4MVOFIOA3R2AKD7ANCNFSM4OQWF6WA> .
|
…s first added in 2011 as a temporary workaround for Open With issue in Windows 8 preview. Re nvaccess#11335
…ccess#11335. ON some systems running Windows 10 May 2020 UPdate (Version 2004), Open With dialog was not read, although NVDA will say 'pane'. Turns out this is a UIA element that is seen as an IAccessible by NVDA. Thus classify Sheell_Flyout window as a good UIA window. NOt only does this let NVDA announce Open With dialog in May 2020 Update, it also lets nVDA not announce 'pane' when Open With opens.
* appModules/Open With: copyright header update (note that this file was first added in 2011 as a temporary workaround for Open With issue in Windows 8 preview. Re #11335 * appModules/open with: treat Shell_Flyout as a good UIA window. Re #11335. ON some systems running Windows 10 May 2020 UPdate (Version 2004), Open With dialog was not read, although NVDA will say 'pane'. Turns out this is a UIA element that is seen as an IAccessible by NVDA. Thus classify Sheell_Flyout window as a good UIA window. NOt only does this let NVDA announce Open With dialog in May 2020 Update, it also lets nVDA not announce 'pane' when Open With opens. * Update what's new for pr #11336 Co-authored-by: Michael Curran <mick@nvaccess.org>
Test results on the machines I have available (all with 2020.2beta2, and dev
version of W10AE):
1511: works perfectly. (Which was expected given that wouldn't have changed)
1909: worked after a COM Types Fix, and says:
"unknown. Dialog how do you want to open this file? how do you want to open this
file? How do you want to open this file? Dialog How do you want to open this
file?".
After that multiple repetition, I can press tab and get to the selector (I.E. it
is still unfocused initially, but does identify itself most verbosely).
2004: says "How do you want to open this file? dialog How do you want to open
this file?", I can then press tab, and use the selector.
|
Hi, the fix for this made it to latest alpha snapshots, so I recommend testing with that also. Thanks.
From: Luke Davis <notifications@github.com>
Sent: Sunday, July 5, 2020 6:34 PM
To: nvaccess/nvda <nvda@noreply.github.com>
Cc: Joseph Lee <joseph.lee22590@gmail.com>; Mention <mention@noreply.github.com>
Subject: Re: [nvaccess/nvda] 2020.2beta2 does not read Windows 10-2004 Open With dialogs automatically (#11335)
Test results on the machines I have available (all with 2020.2beta2, and dev
version of W10AE):
1511: works perfectly. (Which was expected given that wouldn't have changed)
1909: worked after a COM Types Fix, and says:
"unknown. Dialog how do you want to open this file? how do you want to open this
file? How do you want to open this file? Dialog How do you want to open this
file?".
After that multiple repetition, I can press tab and get to the selector (I.E. it
is still unfocused initially, but does identify itself most verbosely).
2004: says "How do you want to open this file? dialog How do you want to open
this file?", I can then press tab, and use the selector.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#11335 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB4AXEC3EAHNWX3CAYE5FDTR2ESX3ANCNFSM4OQWF6WA> .
|
I just wanted to thank you, @josephsl, for your very rapid fixes on this.
I've been testing the PR, and haven't found any cases where it fails or does
anything strange. In general it seems to work better than the fix deployed
in W10AE, although that, too, works.
|
Background
I had a URL shortcut on my desktop for some time. After upgrading Windows from 1909 to 2004, I found that the URL shortcut no longer seemed to work. Not surprising--my network shares no longer work either, for some reason. But rather than giving an error, it appeared that nothing happened when opening it. Alt+tab wouldn't recognize that any new windows were open.
I finally thought to try a title command after opening the URL shortcut, and found out that I was in an "Open with" pane.
Steps to reproduce:
Because you may not actually have this problem, it will be difficult to reproduce exactly.
Running
assoc .url=
, in an administrative command prompt, no longer effectively works to remove existing associations, even though it claims to.To reproduce the result, however, you can:
notepad c:\users\your_user_name\testfile.fakeextension
, and press enter.c:\users\your_user_name
, and press enter.Actual behavior:
NVDA will say "pane".
Additionally, pressing the arrow keys while at this stage, will result in nothing being spoken, which I consider a related bug (even though that behavior existed in the former "How do you want to open this file?" dialog in 1909 and earlier). It should place focus in the application selector.
Expected behavior:
System configuration
Windows 10, Version 2004 (OS Build 19041.329).
NVDA 2020.2beta2 installed. Didn't test other versions on W10 2004.
Rebooted, and tried Com Reg Fix.
Tried with no add-ons, and with latest stable Win 10 App Essentials loaded.
Additional information
I tested NVDA 2020.1 on Windows 10 version 1909. I confirmed the working case of "How do you want to open this file?". Since Windows 10 version 2004 has changed the nature of the window here, I saw no point in testing further on 2004 with older NVDA versions.
Anyone should be able to replicate this, but if you want a log, here it is.
Developer info for the Window, upon initial open, is as expected:
INFO - globalCommands.GlobalCommands.script_navigatorObject_devInfo (23:28:57.855) - MainThread (2788):
Developer info for navigator object:
name: None
role: ROLE_PANE
roleText: None
states: STATE_FOCUSABLE, STATE_FOCUSED
isFocusable: True
hasFocus: True
Python object: <NVDAObjects.IAccessible.IAccessible object at 0x07652630>
Python class mro: (<class 'NVDAObjects.IAccessible.IAccessible'>, <class 'NVDAObjects.window.Window'>, <class 'NVDAObjects.NVDAObject'>, <class 'documentBase.TextContainerObject'>, <class 'baseObject.ScriptableObject'>, <class 'baseObject.AutoPropertyObject'>, <class 'object'>)
description: None
location: RectLTWH(left=760, top=270, width=392, height=326)
value: None
appModule: <'openwith' (appName 'openwith', process ID 13464) at address 12f53d0>
appModule.productName: 'Microsoft® Windows® Operating System'
appModule.productVersion: '10.0.19041.1'
TextInfo: <class 'NVDAObjects.NVDAObjectTextInfo'>
windowHandle: 394708
windowClassName: 'Shell_Flyout'
windowControlID: 0
windowStyle: -1778384896
extendedWindowStyle: 8
windowThreadID: 8812
windowText: ''
displayText: ''
IAccessibleObject: <POINTER(IAccessible) ptr=0x5c32708 at 13043f0>
IAccessibleChildID: 0
IAccessible event parameters: windowHandle=394708, objectID=-4, childID=0
IAccessible accName: None
IAccessible accRole: ROLE_SYSTEM_CLIENT
IAccessible accState: STATE_SYSTEM_FOCUSED, STATE_SYSTEM_FOCUSABLE, STATE_SYSTEM_VALID (1048580)
IAccessible accDescription: None
IAccessible accValue: None
The text was updated successfully, but these errors were encountered: