nsIAccessibleDocument GetWindowHandle was removed causing Selenium native event injection to fail

NEW
Unassigned

Status

()

Core
Disability Access APIs
3 years ago
5 days ago

People

(Reporter: automatedtester, Unassigned)

Tracking

36 Branch
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
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

3 years ago
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

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

Comment 3

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

Comment 4

3 years ago
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

3 years ago
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

3 years ago
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

3 years ago
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

3 years ago
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

3 years ago
(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.
(Reporter)

Comment 10

3 years ago
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
Flags: needinfo?(benjamin)

Comment 11

3 years ago
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.
Flags: needinfo?(benjamin)

Comment 12

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

Comment 13

3 years ago
You'd have to write code to make that possible.

Comment 14

3 years ago
(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

3 years ago
At the moment we use it to get HWND only.

Comment 16

3 years ago
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

3 years ago
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.
You need to log in before you can comment on or make changes to this bug.