Bugzilla

I investigated this issue a bit in an attempt to better understand what's going on. I dumped the entire contents of the cache for all accessibles in the tree before and after removing the padding in the above example to figure out what's stale. It looks like the culprit is the iframe doc's cached relative-bounds. `LocalAccessible::BundleFieldsForCache` doesn't get called on the iframe doc when you adjust padding on the iframe element. `RemoteAccessibleBase::BoundsWithOffset` relies on those cached relative-bounds to calculate its answer, so you end up with the outer doc accessible bounds being correct, but everything downstream of it being incorrect (due to the stale relative-bounds). Really, the relative-bounds are stale for the true OOP case, too (I checked), it's just that the `BoundsWithOffset` calculation works a bit differently when there's a real process boundary, in such a way that the problem is masked.

It's possible that we need to monitor padding in `MaybeQueueCacheUpdateForStyleChanges`. My feeling is that, however it happens we need to ensure that `BundleFieldsForCache` gets called on the iframe doc when certain bounds-affecting attributes of the iframe element are changed. I think that would cause us to recalculate the relative bounds and update the cache accordingly. Maybe that means queueing a cache update for the outer doc accessible's child in `MaybeQueueCacheUpdateForStyleChanges` if we see a change to {padding, border, width, height, maybe more?}. Alternately, maybe we need a notification from layout to update that iframe doc.

See more of this discussion (including thoughts from Morgan) [here](https://phabricator.services.mozilla.com/D157240#5184930).

I investigated this issue a bit in an attempt to better understand what's going on. I dumped the entire contents of the cache for all accessibles in the tree before and after removing the padding in the above example to figure out what's stale. It looks like the culprit is the iframe doc's cached relative-bounds. `LocalAccessible::BundleFieldsForCache` doesn't get called on the iframe doc when you adjust padding on the iframe element. `RemoteAccessibleBase::BoundsWithOffset` relies on those cached relative-bounds to calculate its answer, so you end up with the outer doc accessible bounds being correct, but everything downstream of it being incorrect (due to the stale relative-bounds). Really, the relative-bounds are stale for the true OOP iframe case, too (I checked), it's just that the `BoundsWithOffset` calculation works a bit differently when there's a real process boundary, in such a way that the problem is masked.

It's possible that we need to monitor padding in `MaybeQueueCacheUpdateForStyleChanges`. My feeling is that, however it happens we need to ensure that `BundleFieldsForCache` gets called on the iframe doc when certain bounds-affecting attributes of the iframe element are changed. I think that would cause us to recalculate the relative bounds and update the cache accordingly. Maybe that means queueing a cache update for the outer doc accessible's child in `MaybeQueueCacheUpdateForStyleChanges` if we see a change to {padding, border, width, height, maybe more?}. Alternately, maybe we need a notification from layout to update that iframe doc.

See more of this discussion (including thoughts from Morgan) [here](https://phabricator.services.mozilla.com/D157240#5184930).

I investigated this issue a bit in an attempt to better understand what's going on. I dumped the entire contents of the cache for all accessibles in the tree before and after removing the padding in the above example to figure out what's stale. It looks like the culprit is the iframe doc's cached relative-bounds. `LocalAccessible::BundleFieldsForCache` doesn't get called on the iframe doc when you adjust padding on the iframe element. `RemoteAccessibleBase::BoundsWithOffset` relies on those cached relative-bounds to calculate its answer, so you end up with the outer doc accessible bounds being correct, but everything downstream of it being incorrect (due to the stale relative-bounds). Really, the relative-bounds are stale for the true OOP iframe case, too (I checked), it's just that the `BoundsWithOffset` calculation works a bit differently when there's a real process boundary, in such a way that the problem is masked.

It's possible that we need to monitor padding in `MaybeQueueCacheUpdateForStyleChanges`. My feeling is that, however it happens, we need to ensure that `BundleFieldsForCache` gets called on the iframe doc when certain bounds-affecting attributes of the iframe element are changed. I think that would cause us to recalculate the relative bounds and update the cache accordingly. Maybe that means queueing a cache update for the outer doc accessible's child in `MaybeQueueCacheUpdateForStyleChanges` if we see a change to {padding, border, width, height, maybe more?}. Alternately, maybe we need a notification from layout to update that iframe doc.

See more of this discussion (including thoughts from Morgan) [here](https://phabricator.services.mozilla.com/D157240#5184930).