Windows Store apps: use app title as product name instead of wwahost #4259

nvaccessAuto · 2014-07-07T13:10:27Z

Reported by nvdakor on 2014-07-07 13:10
Hi,
Currently, when invoking appModule.productName for a Windows Store app, NVDA says "Windows operating system". Although this is fine for built-in apps such as Bing Weather and Windows Store, this may confuse users and developers when they are testing accessibility of Store apps (both existing ones and apps to be created in the future). As a way of providing actual product name for debugging purposes and for people to tell us which app they are having issues with, I propose using app title for productName.
Before:

Go to Windows Store app such as Weather.
Once the app opens, press NVDA+F1 to show developer info. Look under appModule.productName.
After:
Open any Windows Store app.
Press NVDA+F1 to open developer info. appModule.productName tells you the title of the app.
Implementation:
In appModules.wwahost.py, override _get_productName to return the title (api.getForegroundObject().name).
wwahost.AppModule.productName will contain the actual title of the app.
Thanks.

Blocked by #4569

nvaccessAuto · 2014-07-08T04:19:33Z

Comment 1 by jteh on 2014-07-08 04:19
Are you certain that the foreground title of these apps can never change? What if the app opens a dialog or other secondary main window? This certainly changes the title for desktop apps, but perhaps it doesn't for Store apps. We'd need to be very certain of this before considering using the foreground title.

nvaccessAuto · 2014-07-08T06:01:25Z

Comment 2 by nvdakor on 2014-07-08 06:01
Hi,
Some examples of apps which pops up a dialog include Skype, People and so forth when launched from local user account. However, when I press Alt+Tab to switch between programs, the name of the program with the pop-up dialog is announced before NVDA presents the pop-up dialog.
One way to get around this would be looking up GUID (global unique identifier) for each app in the app store, but the big issue is what if the user is not connected to the Internet.
Thanks.

nvaccessAuto · 2014-07-08T06:33:00Z

Comment 3 by jteh on 2014-07-08 06:33
When one of these dialogs open, what does NVDA+t report: the app name or the dialog name?

nvaccessAuto · 2014-07-08T06:38:25Z

Comment 4 by nvdakor on 2014-07-08 06:38
Hi,
The dialog I've seen reports the name of the dialog in question. I should add that these dialogs (user account ones) uses a different executable name (useraccountbroker.exe); I still need to find an app that opens its own pop-up dialog with the executable name of wwahost.exe so we canverify that the title is indded the name of the app in question.
Thanks.

nvaccessAuto · 2014-10-23T07:41:28Z

Comment 5 by jteh on 2014-10-23 07:41
We'll need to access the app package info, which will require some of the code for #4569.

LeonarddeR · 2018-02-09T18:41:05Z

cc @josephsl

josephsl · 2018-02-09T18:48:17Z

Hi, hopefully we should do something about it, as there are folks still using Windows 8.x and they might encounter hoste3d apps. Thanks. From: Leonard de Ruijter [mailto:notifications@github.com] Sent: Friday, February 9, 2018 10:41 AM To: nvaccess/nvda <nvda@noreply.github.com> Cc: Joseph Lee <joseph.lee22590@gmail.com>; Mention <mention@noreply.github.com> Subject: Re: [nvaccess/nvda] Windows Store apps: use app title as product name instead of wwahost (#4259) cc @josephsl <https://github.com/josephsl> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4259 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AHgLkAuEb6RyKnk66ENfr10VE8asH0Dmks5tTJFDgaJpZM4SAW78> .

Adriani90 · 2019-01-02T13:59:37Z

@josephsl, @michaelDCurran, @jcsteh any update on this issue? I think the priority for Windows 8 store apps is quite low. in favour o0f Windows 10. Right?

Adriani90 · 2019-01-02T14:00:01Z

Is this issue occuring also on Windows 10?

josephsl · 2019-01-02T18:01:58Z

Hi,

Not by much, as most apps do come with their own executables (including converted desktop apps). I'm leaving this open in case we can find a solution for wwahost issue. Thanks.

josephsl · 2019-01-03T01:15:25Z

Hi,

And I found one: kernel32::GetPackageFullName. This function returns a serialized representation of an app package info, including name, version, architecture, and family. Each part is separated by an underscore, which makes it easy to parse this (index 0 is publisher.name, index 1 is version).

I'll come up with a pull request in the next few hours.

Thanks.

…on. Re nvaccess#4259. AppModule.productName/productVersion looks at product name/version fields for the executable itself. For WWAHost, this means a generic product name (Microsoft Windows operating system) and version (Windows major.minor.build.revision) will be returned, thus not giving an accurate picture as to which app is being hosted and the guest app version. Thankfully, there is a function (kernel32.dll::GetPackageFullName) that will return a serialized package info text, which does return the actual product name and version of the hosted app. The package info structure consits of name, version, publisher, architecture and other relevant information for a package given the process ID for the app container, and is joined via an underscore character (_), with the first two indecies being publisher.name and version, respectively. Thus modified AppModule._setProductInfo for wwahost to fetch the app info via the function described above. This then allows the correct name and version of the hosted app to be returned. Note that in some cases, product version is 1.0.0.0 (especially Store app in Windows 8 and 8.1), but this can be ignored.

…via length.value. Re nvaccess#4259. Comment from James Teh (Mozilla): try using length.value instead of a dedicated buffer variable, as the function used returns nonimportant error codes instead of actual length.

josephsl · 2019-09-08T02:59:34Z

Hi,

Update: #10114 will resolve this through a more generic version as part of base app module, as this issue also extends to universal aps and converted desktop apps, too.

Thanks.

A more generic way of setting product name and version for hosted apps, including those hosted within WWAHost, will be used from base app module, thus this setter method is no longer needed.

… info for Microsoft Store apps. Re nvaccess#7894. User32.dll::IsImmersiveProcess won't quite cut it for Store apps: * File Explorer is seen as an immersive app but it is not really a Store application. * Converted desktop apps are seen as not immersive but they are Store apps. The more accurate way to determine this information is looking for app package info, which can be done by calling kernel32.dll::GetPackageFullName. This returns a string representation of app name, version, architecture, language, and app ID (the first two are used in nvaccess#4259). Every Store app comes with app model XML file that provides data for this structure (Store version of NVDA is no exception). Thus use this method, which is now part of a private function in the base app module so not only product name and version setter can use it, but also Store app property can call this method.

…e process, and app architecture (#8644) * App modules: add appPath property, clarify that app module packages are also supported. Re #7894. Add appModuleHandler.AppModule.appPath property used to obtain the full path for the executable (e.g. C:\Windows\explorer.exe). Also, in app module docstring, clarify that app module packages (appmodname/__init__.py) are also supported. * App modules: add isWindowsStoreApp property. Re #7894. AppModule.isWindowsStoreApp will call user32.dll::IsImmersiveProcess to determine if the app is hosted inside a Windows RT container. This is useful for dealing with universla apps on Windows 10. * App modules: add appArchitecture property. Re #7894. appModule.appArchitecture will return the architecture for which the app is written. It can be x86 (32-bit app on 32-bit Windows), AMD64 (x64 app), or ARM64 (64-bit ARM app). This is accomplished by use of kernel32.dll's IsWow64Process2 (available on Windows 10 build 10586 and later). * App module properties: address review comments. Re #7894. appModule.isWindowsStoreApp: check if it is below Windows 8, also fixed tuple syntax. appModule.appArchitecture: variable renames to make it clear. * App modules/app architecture: use much improved is64bitProcess method. re #7894. Thanks to work on ARM64 detection in appModule.is64BitProcess: use kernel32::isWow64Process2 directly and obtain either AMD64 or ARM64, falling back to AMD64 if that Windows API function isn't present (the function is present in Windows 10 Version 1511 (build 10586) and later). * App architecture: rewrite the whole thing in order to support detection of 32-bit ARM apps. Re #7894. Windows 10 Version 1903 includes foundatoins to support 32-bit ARM apps. Because this means two 32-bit architectures must be handled, rewrite app architecture method to: 1. Record architecture to arch names inside a map. 2. Call kernel32::IsWow64Process2 first and obtain arch name fromthe arch values map. 3. If IsWow64process2 fails for some reason (Windows 7 through 10 Version 1507), return appropriate architecture name based on 64-bit process status. * App architecture: mention ARM32. re #7894. * Lint fixes. Fixes include inline comments and spaces around dictionary operator. * App properties: use a dedicated (private) method for fetching package info for Microsoft Store apps. Re #7894. User32.dll::IsImmersiveProcess won't quite cut it for Store apps: * File Explorer is seen as an immersive app but it is not really a Store application. * Converted desktop apps are seen as not immersive but they are Store apps. The more accurate way to determine this information is looking for app package info, which can be done by calling kernel32.dll::GetPackageFullName. This returns a string representation of app name, version, architecture, language, and app ID (the first two are used in #4259). Every Store app comes with app model XML file that provides data for this structure (Store version of NVDA is no exception). Thus use this method, which is now part of a private function in the base app module so not only product name and version setter can use it, but also Store app property can call this method. * Product name and version for Store apps: use the dedicated package info function. Re #7894. Use the dedicated package info function for obtaining product name and version: * If the package info is a string, info will be parsed. * If it is None, executable file info will be fetched. * Windows Store property: use package info method to determine if the underlying process is a Windows Store app. Re #7894. User32.dll::IsImmersiveProcess won't work all the way, but package info fetching will (on Windows 8 and later). Therefore use the package info method to determine if a given process is a Windows Store app. * Windows Store app property: use platform version tuple from sys.getwindowsversion(). Re #7894. * App modules/immersive package info: use length instead of unused buffer to obtain actual package info length (addressing review action). Re #7894.

…version and which app module to load (#9119) * App modules/WWAHost: update copyright header. * WWAHost: fetch product name and version via GetPackageFullName function. Re #4259. AppModule.productName/productVersion looks at product name/version fields for the executable itself. For WWAHost, this means a generic product name (Microsoft Windows operating system) and version (Windows major.minor.build.revision) will be returned, thus not giving an accurate picture as to which app is being hosted and the guest app version. Thankfully, there is a function (kernel32.dll::GetPackageFullName) that will return a serialized package info text, which does return the actual product name and version of the hosted app. The package info structure consits of name, version, publisher, architecture and other relevant information for a package given the process ID for the app container, and is joined via an underscore character (_), with the first two indecies being publisher.name and version, respectively. Thus modified AppModule._setProductInfo for wwahost to fetch the app info via the function described above. This then allows the correct name and version of the hosted app to be returned. Note that in some cases, product version is 1.0.0.0 (especially Store app in Windows 8 and 8.1), but this can be ignored. * WWAHost: load appropriate app module for the hosted app. Re #4569. Just like Javaw (hosted Java apps): different app modules for apps hosted by WWAHost are desirable for handling individual apps. Thus fetch which app module to load via a call to kernel32.dll::GetApplicationUserModelId. The app model text consists of app family name, an exclamation point, and the app name. Because Python can't import files with exclamation marks in the middle of their name, just return the lowercase version of app name (latter half of the app model text). Note that app modules for WWAHost apps must import contents of wwahost app module in order to take advantage of package-specific product name/version field, as well as other potential services in the future. * appModules/WWAHost: docstring updates. Re #4569. Reviewed by Leonard de Ruijter (Babbage): clarify docstring, and give an explanation as to how app model text is constructed and reasoning behind returning only a portion of it. * Dev guide: add sections and an example on hosted apps. Re #4569. * appModules/wwahost: obtain length of the app module/full name string via length.value. Re #4259. Comment from James Teh (Mozilla): try using length.value instead of a dedicated buffer variable, as the function used returns nonimportant error codes instead of actual length. * Dev guide: remove confusing paragraph on wwahost notess. * WWAHost: app content should not become a browse mode document by default. Although content appears to be a webpage, it is actually part of an app hosted inside WWAHost. This includes apps from Windows 8.x days, as well as progressive web apps (PWA's) that are not really browse mode documents. Apps requiring browse mode may override 'disable browse mode by default' flag to suit their needs. * WWAHost: lint fixes. Lint fixes include splitting long lines and comment style. * WWAHost: remove product name and version setter. Re #4259. A more generic way of setting product name and version for hosted apps, including those hosted within WWAHost, will be used from base app module, thus this setter method is no longer needed. * appModules/wwahost: update copyright header * appModules/WWAHost: remove bulk of app module class apart from browse mode off flag. Comment from Mick Curran (NV Access): in 2012, WWA Host app module was reponsible for turning what was essentially a web application into a proper 'application'. This was needed prior to introduction of browse mode flag for app modules. Now that this flag is present, there is no need for role coercion anymore (users can toggle browse mode instead).

nvaccessAuto added the bug label Nov 10, 2015

nvaccessAuto mentioned this issue Nov 10, 2015

Load specific app modules for apps hosted by wwahost.exe #4569

Closed

josephsl mentioned this issue Jan 3, 2019

App modules/WWAHost: use package functions to determine product name/version and which app module to load #9119

Merged

josephsl mentioned this issue Sep 8, 2019

Windows Store/immersive apps: obtain product name and version via package functions if possible #10108

Closed

josephsl mentioned this issue Sep 8, 2019

App modules/product name and version: use kernel32::GetPackageFullName to obtain product info for immersive (hosted) apps #10114

Merged

michaelDCurran closed this as completed in #10114 Sep 10, 2019

nvaccessAuto added this to the 2019.3 milestone Sep 10, 2019

josephsl mentioned this issue Sep 18, 2019

App modules: add additional properties for benefit of testing, add-ons and alike #7894

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Windows Store apps: use app title as product name instead of wwahost #4259

Windows Store apps: use app title as product name instead of wwahost #4259

nvaccessAuto commented Jul 7, 2014

nvaccessAuto commented Jul 8, 2014

nvaccessAuto commented Jul 8, 2014

nvaccessAuto commented Jul 8, 2014

nvaccessAuto commented Jul 8, 2014

nvaccessAuto commented Oct 23, 2014

LeonarddeR commented Feb 9, 2018

josephsl commented Feb 9, 2018 via email

Adriani90 commented Jan 2, 2019

Adriani90 commented Jan 2, 2019

josephsl commented Jan 2, 2019

josephsl commented Jan 3, 2019

josephsl commented Sep 8, 2019

Windows Store apps: use app title as product name instead of wwahost #4259

Windows Store apps: use app title as product name instead of wwahost #4259

Comments

nvaccessAuto commented Jul 7, 2014

nvaccessAuto commented Jul 8, 2014

nvaccessAuto commented Jul 8, 2014

nvaccessAuto commented Jul 8, 2014

nvaccessAuto commented Jul 8, 2014

nvaccessAuto commented Oct 23, 2014

LeonarddeR commented Feb 9, 2018

josephsl commented Feb 9, 2018 via email

Adriani90 commented Jan 2, 2019

Adriani90 commented Jan 2, 2019

josephsl commented Jan 2, 2019

josephsl commented Jan 3, 2019

josephsl commented Sep 8, 2019