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

WWAHost/app window: separate app window role coercion from app module #9117

Open
josephsl opened this issue Jan 2, 2019 · 6 comments
Open

WWAHost/app window: separate app window role coercion from app module #9117

josephsl opened this issue Jan 2, 2019 · 6 comments

Comments

@josephsl
Copy link
Collaborator

@josephsl josephsl commented Jan 2, 2019

Hi,

A follow-up to #4569 and should serve as a foundation for fixing the latter issue:

Background:

Various apps from Windows 8/8.1/10 are hosted inside WWAHost, particularly for apps that include web browser rendering engine controls for their user interfaces (for example, Store from Windows 8.x, Twitter app from Windows 10, etc.). In the Windows 8.x era, WWAHost was responsible for hosting interfaces for many apps, whereas in Windows 10, this host executable is used in progressive web apps (PWA's) and other apps using web rendering technologies.

Due to technology in use, WWAHost apps are seen as browse mode documents by NVDA. In October 2012, an app module for this host app was added that requested NVDA to treat the top-level window as a proper application window. This worked at that time because the hosted apps employed MSHTML for interface presentation. Fast forward to 2019 and apps such as Twitter employs EdgeHTML (a UIA universe) for hosting interface controls.

Is your feature request related to a problem? Please describe.

To summarize #4569: an infrastructure for importing app modules for apps hosted by WWAHost was suggested by querying user app model for a package. However, this means giving up role coercion technique that will cause apps from Windows 8.x era, and PWA's from Windows 10 era to tell NVDA that their top-level windows are browse mode documents. on Windows 10, this won't be a problem because browse mode is sufficient for using web apps; on Windows 8.x, native app functionality and navigation strategies for various apps won't work anymore.

Describe the solution you'd like

One possible solution is moving the role coercion routine (event_NVDAObject_init) to somewhere else. However, this may create duplicate code paths, as we need to check for MSHTML (Windows 8.x) and EdgeHTML (windows 10) objects. If this move is successful, it allows #4569 to come to life more easily by letting WWAHost app module responsible for telling NVDA which hosted app module to load, and letting individual apps to pick which portion should be good for browse mode.

Describe alternatives you've considered

The alternative is modifying the appName property in WWAHost app module to return the actual name of the app in question. This allows role coercion to work on Windows 8.x (Windows 10 PWA's are a different story).

Additional context

Note that Windows 8.1 (not 8) is in extended support phase (no feature updates; Windows 8 support ended in January 2016), with support from Microsoft scheduled to expire in January 2023 (also affects Windows server 2012/2012 R2). Given the rise of PWA's on Windows 10, and because we may need to let the Core and/or add-ons support various web apps hosted by WWAHost, I would like to request looking into this one.

Thanks.

@josephsl

This comment has been minimized.

Copy link
Collaborator Author

@josephsl josephsl commented Jan 2, 2019

@Brian1Gaff

This comment has been minimized.

Copy link

@Brian1Gaff Brian1Gaff commented Jan 3, 2019

@josephsl

This comment has been minimized.

Copy link
Collaborator Author

@josephsl josephsl commented Jan 3, 2019

@josephsl

This comment has been minimized.

Copy link
Collaborator Author

@josephsl josephsl commented Jul 30, 2019

Hi,

As of NVDA 2019.2, there is now a property in app modules that allows them to forego browse mode. However, in order for that to work properly, the plan outlined above should be implemented.

Thanks.

@josephsl

This comment has been minimized.

Copy link
Collaborator Author

@josephsl josephsl commented Aug 15, 2019

Hi,

I won't be able to work on WWAHost pull request until this issue is resolved, as role coercion is important for user experience. In regards to app name based on app model, perhaps it can be done after #7894 comes to life, because app models are important for immersive apps.

Thanks.

@josephsl

This comment has been minimized.

Copy link
Collaborator Author

@josephsl josephsl commented Sep 8, 2019

Hi,

There are two ways I can think of that can resolve this dilemma:

  1. Move app role coercion routine to NVDAObjects.IAccessible.MSHTML package to cover Windows 8.x; for Windows 10, it should be part of NVDAObjects.UIA.edge package. This means PWA's won't be true web apps as far as user experience is concerned.
  2. Remove app role coercion from WWAHost app module. This reverts an old commit from 2012. This is also a possibility now that we have browse mode flag for app modules so app modules can declare themselves as not needing browse mode at startup.

I personally vote for the second option:

  1. Consistency and use of new techniques.
  2. App modules can choose their own destiny when it comes to enforcing focus/app module at startup.
  3. Better reflects today's reality as more apps become web services.

Before #9119 can come to life fully, a resolution to this issue should be sought. That way that PR can be informed as to what to do next.

Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.