Activation fighting with the developer
Closed this issue · 4 comments
Viewport activation is one obvious case where the developer and the browser could accidentally fight with each other on activation: user agent activates when visible, then the developer re-locks, but it's still visible and so is activated.
Find-in-page is another example - just because the developer re-locks doesn't mean that the content is not still available to find-in-page.
What can be done about these situations?
One option could be to remove the ability to turn off activation again. This however, amounts to allowing activation only once, and therefore defeats many of the use-cases of rendersubtree.
Another is to do nothing, and expect developers not to do that or anticipate a broken site. Maybe there is analogy with scrolling: if the developer tries to control scroll exactly they will not be able to do so, because scrolling is asynchronous to developer control. Likewise so is rendering - the beforeactivate event is likely just an event queued up, and not timed in any way w.r.t. rendering.
A third could be to try to spec concepts like "the duration of a UA algorithm" and avoid re-activating elements twice in the same algorithm. That doesn't sound promising though.
I think it's fine to do nothing and let the developer locking win and not reactivate, and maybe we can help with exposing the reason of activation?
I think this is mostly a problem with viewport activation, the other activations don't have a really defined mechanism to re-do stuff so probably shouldn't try to reactivate and we should make sure developers knows the consequences. For viewport activation we should probably reactivate, but at least rendersubtree/locked state only updates when we do style recalc, so the fighting only happens just once per frame?
I think it's fine to do nothing and let the developer locking win and not reactivate, and maybe we can help with exposing the reason of activation?
I think it's hard for us to distinguish the case where the developer may intentionally relock this expecting us to activate (maybe it's offscreen and we activate when we roll it on screen) as compared to whether this is developer fighting the the UA (when locking happens with on screen content)
For viewport activation we should probably reactivate, but at least rendersubtree/locked state only updates when we do style recalc, so the fighting only happens just once per frame?
I agree with this. I don't think there's anything we can do to prevent this fighting, since as long as we don't have bugs, the UA is spec compliant :)
At the end of the day, if it isn't the developer's intent to find the UA, then the developer has a bug in their code (ie use skip-activation). It's possible that we want to bubble a warning to the dev console if we activate the same thing X frames in a row, since that may indicate that this fighting is happening.
This no longer applies, since the developer can't relock things manually.. only by specifying different CSS values