Load the following page:

data:text/html,<div id="container"><div style="position:absolute; transform: translate(100px, 100px);"><p>test</p></div></div>

Examine the bounds of the paragraph accessible. They are not translated as expected, and their cached bounds differ from their un-cached bounds.

Note that this behavior is not easily visible until the resolution of Bug 1806356, which forces the inner div to create an accessible. With the patch here, this issue shows more directly. The bounds are much closer with that patch, but are still slightly off.

Accounting for DPI scaling, the cached bounds are 8px larger in both x and y than the non-cached bounds. That sounds very suspiciously like some kind of padding or margin and seems similar to bug 1809695, though the cause may be different.

When we apply transforms, we ignore the parent relative bounds and instead let the transform apply the translation to the parent. I wonder if this causes problems in this case for some reason.

What's curious to me is that if we were missing something here, I would have expected the cached bounds to be 8px smaller than the non-cached bounds, not larger.

The outer div is offset from the document by (8, 8). If you put role="presentation" on the outer div:
data:text/html,<div id="container" role="presentation"><div style="position:absolute; transform: translate(100px, 100px);"><p>test</p></div></div>
the cached and non-cached bounds match. That suggests that the offset from the document to the outer div is being added by the transform as well as the outer div's parent relative bounds.

The transform should be from the inner div to the outer div. Why is it from the inner div to the root?

Oh. I wonder if these two frames aren't actually ancestor -> descendant? Perhaps they're sibling frames or frames in different subtrees somehow? Figuring that out would require looking at the frame tree.

I confirmed these indeed aren't ancestors:

1. nsLayoutUtils::GetTransformToAncestor takes an optional aOutAncestor parameter which outputs the ancestor that was actually used. aOutAncestor != boundingFrame.
2. nsLayoutUtils::IsAncestorFrameCrossDocInProcess(boundingFrame, frame) is false.

Without position: absolute, they are ancestors as expected.

Calculating it relative to an ancestor causes problems when the frame ancestry and the a11y ancestry diverge.
For example, this can happen for a transform which is also position: absolute.
In that case, the parent Accessible's frame is not an ancestor of the child Accessible's frame.
Since the transform is no longer relative to the ancestor, we no longer need to remove our parent-relative bounds before applying it.
However, we do need to ensure that we apply the transform before adding parent-relative bounds.

https://hg.mozilla.org/mozilla-central/rev/cc03272083b0