The fix seems logically correct (if we don't have a style we need to compute it). Can you tell why this hasn't caused trouble elsewhere and why it does cause trouble with anchor positioning?

You can just write

if (!existingStyle || existingStyle->hasExplicitlyInheritedProperties())

Good point.

As for why it does work without anchor positioning - in that scenarios the resolution of children of element that became visible again is being done altogether always. In that case, in WebCore::Style::TreeResolver::computeDescendantsToResolve() we're hitting case Change::Renderer: that forces full resolution (yields DescendantsToResolve::All). Moreover, further down the road in TreeResolver::determineResolutionType() we have combinedValidity equal to WebCore::Style::Validity::SubtreeInvalid (for entire subtree) that leads to full resolution of all subtree elements. With anchor-positioning, if the element that become visible again is anchor positioned, at the point when update.change resolves to Change::Renderer only the original element creates renderer - it's children have to wait for anchor-positioning resolution. When it finally is done (few passes after) the update.change resolves to DescendantsToResolve::ChildrenWithExplicitInherit which then leads to no resolution in TreeResolver::determineResolutionType() as such corner-case was never happening before. The fix proposed in this PR just handles such unhanded case.