1122727 - nsIAccessibleDocument GetWindowHandle was removed causing Selenium native event injection to fail

Status: NEW

(Core :: Disability Access APIs, defect)

Description

[David Burns :automatedtester]

in https://hg.mozilla.org/mozilla-central/rev/dbf096855eb5 we appear to have removed GetWindowHandle which was being relied upon by the Selenium (read we broke the native event injection). 

What should we be using instead or should this be added back?

Comment 1

[alexander :surkov (:asurkov)]

can you obtain it from nsIWidget similar to how we do that in accessibility http://mxr.mozilla.org/mozilla-central/source/accessible/generic/DocAccessible.cpp#1124

Comment 2

[Alexei Barantsev]

and how to obtain a reference to pres shell from nsISupports *node ?

Comment 3

[alexander :surkov (:asurkov)]

you should be able to query docshell from window, and then get presshell.

Comment 4

[Alexei Barantsev]

Can you please show an example? There are too many "window" classes in gecko, I can't understand quickly which one is required and how to get from nsISupport to the proper window class.

Comment 5

[alexander :surkov (:asurkov)]

I don't really have proven to work example but I would try to do something like:
node.document.defaultView.queryInterface(nsIDocShell).presShell

I guess we could back windowHandle prop to nsIAccessibleDocument c++ version since Selenium is accessibility client but the method is Windows specific and it seems you can get a window handle on your own. However I'm not sure if you need window handles for emulated windows (the mode we run in for certain screen readers).

Comment 6

[Jim Evans]

Bringing in nsViewManager.h so that we can call GetViewManager() then subsequently get the default widget yields compile errors defined with the #error directive. To wit:

#error :  Internal string headers are not available from external-linkage code.

Somewhere in the transitive dependencies, nsStringFwd.h gets pulled in, which triggers this compile error.

Comment 7

[alexander :surkov (:asurkov)]

ok, to not make you to dig deep into gecko what about to add crossplatform method into nsIAccessibleDocument
[noscript] readonly attribute voidPtr nativeWindow;

Comment 8

[Jim Evans]

Which would get us back to the functionality we had in prior versions with the windowHandle attribute. What do we do in the meantime, to get us working with Gecko 35?

Comment 9

[alexander :surkov (:asurkov)]

(In reply to Jim Evans from comment #8)
> Which would get us back to the functionality we had in prior versions with
> the windowHandle attribute.

right

> What do we do in the meantime, to get us working
> with Gecko 35?

I'm not sure I can do anything for Gecko 35. Maybe you should try to figure out if you can bypass those external-linkage stuff.

Comment 10

[David Burns :automatedtester]

bsmedberg,

Do you have any thoughts that you can offer to get comment 6 solved. Not having stable APIs in the SDK has burned the Selenium project again

Comment 11

[Benjamin Smedberg]

I think the whole question here presumes that you are using binary XPCOM components, which is a bad idea and will not be supported soon. None of our binary APIs are stable.

I'm not sure why you're using a native window handle at all, but to the extent that you still need it you should focus your efforts on making this available via script and then passing it to a DLL via jsctypes.

Comment 12

[Alexei Barantsev]

Any suggestions how to obtain HWND via script? I read from the documentation that nsIWidget is not scriptable.

Comment 13

[Benjamin Smedberg]

You'd have to write code to make that possible.

Comment 14

[alexander :surkov (:asurkov)]

(In reply to alexander :surkov from comment #5)
> I don't really have proven to work example but I would try to do something
> like:
> node.document.defaultView.queryInterface(nsIDocShell).presShell
> 
> I guess we could back windowHandle prop to nsIAccessibleDocument c++ version
> since Selenium is accessibility client

just realized that selenium is not about accessibility only so triggering the accessibility engine for non a11y stuff is not what you should do. Just to make sure, do you use anything from nsIAccessible... interfaces except that HWND thing? If no then the bug should be moved to a proper component.

Comment 15

[Alexei Barantsev]

At the moment we use it to get HWND only.

Comment 16

[alexander :surkov (:asurkov)]

so, right, you shouldn't run accessibility engine for that since it affects negatively on overall performance. you have to figure out how to expose HWND via script as Benjamin says.

Comment 17

[gorf4673]

Not just Selenium having this issue.
While we are trying to move to a JS based plugin, our binary plugin that ties heavily with a Microsoft only environment and has options that require a window handle.