Skip to content

Support embedded Chrome / CEF 3 controls on non-main GUI threads #8553

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

Closed
dglee42 opened this issue Jul 24, 2018 · 3 comments · Fixed by #13542
Closed

Support embedded Chrome / CEF 3 controls on non-main GUI threads #8553

dglee42 opened this issue Jul 24, 2018 · 3 comments · Fixed by #13542
Milestone

Comments

@dglee42
Copy link

dglee42 commented Jul 24, 2018

Steps to reproduce:

[Edited July 26: Jabber 12.0 is released and this issue applies to Jabber 12.0 and beyond, not just 12.0]

This issue occurs in Cisco Jabber versions 12.0 and later. I suspect this issue will occur in other applications that embed Chrome (CEF 3) controls and use them in multi-process fashion as well.

I can work with NVDA developers to test this, since I am set up in a Cisco test environment.

To test directly, as an alternative:

  • Get a copy of Cisco Jabber 12.0, by setting up an account at www.cisco.com and downloading it, or by writing to accessibility@cisco.com to request a copy of Jabber 12.0 for this effort. Suggested email subject: Debugging effort for NVDA handling of Jabber 12.x chat history.
  • Log into Jabber, select a contact, and start a chat by pressing Enter on a contact in the treeView displayed when the "Contacts" radio button is checked.
  • Send a line or two to the contact to create history entries.
  • Tab to the history area. NVDA should identify this as a Chrome area.

Actual behavior:

Chat history controls do not allow Browse mode to activate. See the "Other Information" section for details.

Expected behavior:

Browse mode should be allowed in chat history controls.

System configuration:

Jabber 12.0, Windows 10.

NVDA Installed/portable/running from source:

Running NVDA as an installed application.

NVDA version:

2018.2.

Windows version:

Various incarnations of Windows 10.

Name and version of other software in use when reproducing the issue:

Cisco Jabber 12.0 and later versions.

Other information about your system:

I have discussed this issue extensively with @jcsteh in Gitter. The following information is based on those discussions and on testing against Jabber 12.0, and a bit against 11.9 (which uses an Internet Explorer control instead of a Chrome control for chat history) for comparison:

Jabber 12.0 and later versions run the Chrome widget for chat history in a separate GUI thread from the main application. By comparison, Jabber 11.9 runs an IE widget in the main application thread.

NVDA uses some out-of-process means to access the Chrome control, whereas JAWS uses in-process code for this.

For out-of-process code, an IA2 COM proxy needs to be registered. NVDA registers an IA2 COM proxy for the main GUI thread, but doesn't for other threads. The result is that it is unable to access IA2 information on the chat history controls in Jabber 12.x.

Modifying NVDA's proxy registration approach would require a low-level (C++) modification to NVDA itself and cannot be accomplished via an add-on.

Other questions:

Does the issue still occur after restarting your PC?

Yes.

Have you tried any other versions of NVDA?

2018.1.

@Adriani90
Copy link
Collaborator

cc: @feerrenrut

@Adriani90
Copy link
Collaborator

cc: @michaelDCurran

@LeonarddeR
Copy link
Collaborator

LeonarddeR commented Mar 26, 2022

I wrote a proto type to address this. See #13542

seanbudd pushed a commit that referenced this issue Mar 2, 2023
…ead (#13542)

Fixes #8553

Summary of the issue:
When an app offers IAccessible2 as its accessibility interface, NVDA needs to install a COM proxy in the UI thread to utilize IA2. However, some apps, particular those that embed Chromium Embedded Controls, have a separate UI thread for the browser control. IAccessible2 and therefore browse mode doesn't work in these controls.

Description of how this pull request fixes the issue:
Register IA COM Proxy in all threads that ever send focus or foreground win events

Testing strategy:
Tested with the Chromium Embedded Framework test case from #13493 (comment)
@nvaccessAuto nvaccessAuto added this to the 2023.2 milestone Mar 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants