[PATCH 2/6] uiautomationcore/tests: Skip UiaProviderFromIAccessible tests on Win10v1507.
huw.davies at physics.ox.ac.uk
Wed Jun 8 03:56:06 CDT 2022
On Tue, Jun 07, 2022 at 11:29:12AM -0400, Connor McAdams wrote:
> On Tue, Jun 07, 2022 at 04:13:45PM +0100, Huw Davies wrote:
> > On Tue, Jun 07, 2022 at 11:02:31AM -0400, Connor McAdams wrote:
> > > On Tue, Jun 07, 2022 at 10:07:22AM +0100, Huw Davies wrote:
> > > > On Wed, May 25, 2022 at 02:37:35PM -0400, Connor McAdams wrote:
> > > > > In Windows 10 version 1507, UiaProviderFromIAccessible will try to check
> > > > > the IAccessible passed in against the root IAccessible of the HWND
> > > > > associated with the passed in IAccessible. In all other Windows
> > > > > versions, this check is done on a call to get_HostRawElementProvider, or
> > > > > the first time navigating towards a parent or sibling. Rather than work
> > > > > around this, just skip the tests if this happens.
> > > >
> > > > Could we write the tests so that they don't rely on implementation
> > > > details? Presumably applications run correctly on Windows 10 v1507.
> > > >
> > > > Huw.
> > >
> > > So, essentially most of my tests for UI Automation kind of revolve
> > > around things like SET_EXPECT/CHECK_EXPECT/CHECK_CALLED tests as a way
> > > of testing what UI Automation does with the interfaces we pass into it.
> > > This is similar to how the tests for oleacc are done. In this case, we'd
> > > end up with a number of tests where we'd have to add a bunch of
> > > SET_EXPECT's to account for one specific version of Windows, then we'd
> > > need some sort of special CHECK_CALLED that could account for a broken
> > > behavior. It's a lot more work than I think it's worth to work around a
> > > bug in one specific version of Windows 10.
> > Is it really a bug in Windows; it seems more like a different
> > implementation? How different are the call sequences?
> I believe it's a bug, or at least a behavior that was undesirable.
> All other versions of Windows seem to delay this root IAccessible check
> until specific methods are called on the IRawElementProviderSimple
> wrapper. The check is basically sending the HWND associated with an
> IAccessible a WM_GETOBJECT message, and then the returned IAccessible is
> compared against the currently wrapped one. This can end up with:
I'm still not convinced it's a bug or even undesirable behaviour; it's
just different. However, skipping here does allow some useful tests,
so I'll let it go and hope Windows doesn't change its implementation
More information about the wine-devel