Chrome_RenderWidgetHostHWND

[Anthony Tietjen]

Regarding this change: https://codereview.chromium.org/151083002/

It appears that the Chrome_RenderWidgetHostHWND (which "Visible" but "Transparent") is in Chrome 34 Beta and 35 Canary for Windows. When using a tool to look at the window hierarchy, there is only one of those listed as children under the main Chrome instance. When switching tabs, it switches out the handle of that Chrome_RenderWidgetHostHWND but still only shows one instance of it under the main Chrome instance.

However, using a window hierarchy inspection tool on Chrome 33 Stable it reveals multiple [Static] handles (which are not "Visible") as children of the main Chrome instance. It seems there is one for each tab.

If I understand correctly, the change was to use Chrome_RenderWidgetHostHWND instead of the [Static] objects because the [Static] objects didn't work for vendors' existing code which looks for the Chrome_RenderWidgetHostHWND instead.

I just have a few questions:

1. Is this something that broke for vendors with the release of the Aura versions of Chrome?

2. Did older versions of Chrome (that didn't use Aura) use Chrome_RenderWidgetHostHWND, thus it used to work for vendors?

3. Most importantly: The description states that this is a short-term workaround. Also, one comment indicates that it would go to QA before deciding to drop it. Will you continue to use Chrome_RenderWidgetHostHWND in the future releases, or is there another potential solution in the works?

Thanks in advance!

Anthony

[Scott Violet]

Indeed. This is all a giant hack. Some drivers were expecting a
particular HWND hierarchy with specific names. To fix users with these
drivers we added back an extra HWND. The hope is that over time we can
remove the hacks and go with just the topmost HWND.

-Scott

> --
> --
> Chromium Developers mailing list: chromi...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev

[Carlos Pizano]

More specifically older lenovo thinkpads, there is a sizable population where the synaptics driver only injects the desired windows scroll messages if the window hierarchy looks certain way.

We don't have a clear path to transition back to the single window hierarchy ATM.

[Anthony Tietjen]

Scott and Carlos,

Thank you for the responses. In the screenshots below you will see the following:

1) Chrome 35 Canary has two tabs open but only one child HWND.

    That child HWND has dimensions set. (Even though it is set to be transparent.)

2) Chrome 33 Stable has two tabs open and also has two child HWND objects. I assume there is one for each tab.

    The active tab's corresponding child in the hierarchy has dimensions set, but the inactive one does not -- which is fine for my scenario.

If I understand correctly, there is not a plan outlined yet for the final state of this hierarchy.

Question 1: In your minds do you feel would it eventually end up to where there are absolutely zero child objects? Or do you feel it would end up more like it it behaves in Chrome 33, where there are multiple child [Static] objects.

Question 2: If changes are made to this hierarchy, how soon do you feel it would be before a change would likely occur? Are we talking weeks, months, years? (I realize that priorities can change at a moment's notice. So a rough guess will be fine.)

Again, thank you so much for your help and insight as I research this development project!!!!

Chrome 33 (Stable)

Chrome 35 (Canary)

[Scott Violet]

Child windows are implementation details. You should not be relying on them to determine information about an app.

I'm not sure what you need this information for, but I believe accessibility APIs can likely give you information about the app itself. I'm not familiar with them though.

  -Scott

[Dominic Mazzoni]

I can help with accessibility APIs. It'd help if you could explain exactly what you're trying to accomplish. I'd also encourage you to try not to rely on anything about the HWND class name. Use MSAA or UI Automation if possible.

[Carlos Pizano]

The goal is to have 0 child windows as long as 3rd party (aka plugins) and users are mostly unaffected. We can't at this time and it might get even crazier. 

[Anthony Tietjen]

Carlos, Scott, Dominic,

Thank you all for the help. This is good to know at least what the goal is. It sounds like I shouldn't depend on the child window since things could change at any time.

I think we have determined a way to get what we need without depending on a child window.

I really appreciate the responses you have given me. I hope you have a great day!

--Anthony