[PATCH 1/2] oleacc: Implement AccessibleObjectFromEvent.

[Huw Davies]

On Fri, Aug 27, 2021 at 10:29:35AM -0400, Connor McAdams wrote:
> On Fri, Aug 27, 2021 at 09:26:09AM +0100, Huw Davies wrote:
> > On Tue, Aug 10, 2021 at 08:42:56PM -0400, Connor McAdams wrote:
> > > +    hr = IAccessible_get_accChild(*ppacc, cid, &child);
> > > +    if (FAILED(hr))
> > > +        FIXME("get_accChild failed with %#x!\n", hr);
> > 
> > It's unclear to me, having not spent any time looking at this API,
> > what failure here means.  Should we just return the failure (after
> > releasing "acc")?  The FIXME() implies it's not handled and yet
> > presumably that corresponds to the !child case below, so it seems like
> > you're trying to handle it?  Could this be tested?
> >
> 
> So, according to MSDN, get_accChild is supposed to return 'S_FALSE' if
> the child ID that is passed in represents a 'simple element', which is
> an element that has its data retrieved from its parent IAccessible. If
> the child ID represents a full IAccessible 'child', it returns S_OK and
> an IDispatch interface. However, I've found through testing, that even
> if get_accChild returns a failure code, AccessibleObjectFromEvent
> doesn't fail, it just behaves as though it went through the simple
> element path (S_FALSE) path. A FIXME may not be the best way to signify
> this, but I feel like it's a little bit useful to have some indication
> if this method returned a failure code for logging. Maybe a WARN or a
> TRACE or something might be more appropriate. There is a test for this
> in my current tests.

Right, so definitely not a FIXME then, since you're apparently handling
it in the same way as Windows does.  Probably just a TRACE would do.

That being the case, you should NULL-init child and not rely on
the failing call to do it.

Be wary of "over-testing"; if this is something that is likely to
occur in practice that's fine, but if it's not then don't bother
probing it.

Huw.