Skip to content
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

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

Closed
nvaccessAuto opened this issue Oct 23, 2014 · 10 comments · Fixed by #9119
Closed

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

nvaccessAuto opened this issue Oct 23, 2014 · 10 comments · Fixed by #9119
Milestone

Comments

@nvaccessAuto
Copy link

Reported by jteh on 2014-10-23 07:35
wwahost.exe hosts many Windows Store apps (though it seems some do have their own executables). To allow for application specific customisation, we should identify the specific application in the app module name.

I think we can use GetApplicationUserModelId (in kernel32) for this purpose. This includes a "!" character, so we'll need to check whether Python will cope with this and replace if not.
Blocked by #4360
Blocking #4259

@nvaccessAuto
Copy link
Author

Comment 1 by jteh on 2014-10-23 07:36
GetApplicationUserModelId in MSDN

@nvaccessAuto
Copy link
Author

Comment 4 by nvdakor on 2015-01-02 09:46
Hi,
Looking at how to work on this...
It turns out wwahost.exe is similar to javaw - uses command-line arguments to decide which app to host. If you try the following in Python Console (after obtaining the PID for the app in question):

import appModuleHandler
x = appModuleHandler.getWmiProcessInfo(PID)x.CommandLine

The argument of interest is:

-ServerName:appName.wwa```
For apps such as Calendar, a unique name will be shown, with some showing app.wwa (such as Bing Weather). However, wwa names can change, so it's not quite reliable, but at least getting the wwa name via command-line is possible (for those who don't know, there exists a ticket that requests locating names of apps hosted by wwahost); if I can figure out how to read buffer in Python, I'll do some research on the application model function and getting the package info (if it works, should this be added to winKernel?).
For OS, I put Windows 8, as wwahost (and WinRT in general) is available on Windows 8 and higher (including 8.1). Thanks.

@nvaccessAuto
Copy link
Author

Comment 5 by nvdakor on 2015-01-02 10:41
Hi Jamie,
At least on Cygwin, when I attempt to import a module with exclamation point in the middle of the name, I get a syntax error. Also, GetApplicationUserModelId does return the name of the app when I test this against Bing News, Weather, Mail and others.
Since the function itself returns a buffer and might be used in many Windows Store apps, should this be part of winKernel? If so, I'm willing to create a branch that adds this function (by the way, OpenProcess is defined twice in winKernel).
Thanks.

@nvaccessAuto
Copy link
Author

Comment 6 by jteh (in reply to comment 5) on 2015-01-06 07:41
Replying to nvdakor:

At least on Cygwin, when I attempt to import a module with exclamation point in the middle of the name, I get a syntax error.

What about when you do it via __import__ (which is how NVDA does it for app modules)?

Since the function itself returns a buffer and might be used in many Windows Store apps, should this be part of winKernel?

I'd probably just call it directly in the wwahost app module, as I don't think we'll need to call it elsewhere.

@LeonarddeR
Copy link
Collaborator

cc @josephsl

@josephsl
Copy link
Collaborator

josephsl commented Jan 2, 2019

Hi,

This issue mainly affects Windows 8.x, as Windows 10 do come with apps which have their own executables. Note that appPath property from another pull request might help out if needed.

Thanks.

@josephsl
Copy link
Collaborator

josephsl commented Jan 2, 2019

Hi,

Import test: test fails - files with an exclamation mark in the middle of the name isn't imported.

I'd go for command line version (see the example code fragment above), as it can be passed onto app module handler string replacement patch. I'll send a pull request soon.

Thanks.

@josephsl
Copy link
Collaborator

josephsl commented Jan 2, 2019

Hi,

An unexpected case showed up on Windows 10: The Twitter PWA (progressive web app) that is hosted inside WWAHost.exe. If PWA's are hosted inside wwahost, then this boosts priority of this issue, as more PWA's may show up on Microsoft Store.

Thanks.

@josephsl
Copy link
Collaborator

josephsl commented Jan 2, 2019

Hi,

Actually, GetApplicationUserModelId is way faster than command line method, validating @jcsteh's hunch.

Thanks.

josephsl added a commit to josephsl/nvda that referenced this issue Jan 3, 2019
…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.
josephsl added a commit to josephsl/nvda that referenced this issue Jan 4, 2019
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.
@josephsl
Copy link
Collaborator

josephsl commented Sep 8, 2019

Hi,

PR #9119 has a side effect: the application role workaround for WWAHost breaks, meaning browse mode will be enforced. This means we may need to add a special case for this in IAccessible/MSHTML, or re-examine the app role strategy.

Thanks.

michaelDCurran pushed a commit that referenced this issue Jul 6, 2020
…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 nvaccessAuto added this to the 2020.3 milestone Jul 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants