jkarlin
How can users prevent user-hostile frame pausing?
Consider a site which as an "anti-copying" feature puts all its content into a frame that it then pauses. It allows scrolling the parent document of that frame. Per the letter of the explainer, this means the user cannot select text in the subframe. Can the user even bring up a context menu for things in the frame? What about other sorts of interaction?
These sorts of anti-copying features have long existed (e.g., hijacking mouse and keyboard events). Does this add anything new?
Yes, it does. UAs have user overrides for the existing user-hostile things and extensions that allow bypassing them, and those overrides can be done in a way that is not exposed to web pages in any way. But overriding pausing has all sorts of observable effects by the web page, because its scripts run when they "shouldn't".
Presumably that's unspecced UA intervention? It's hard to maintain compatibility with unspecced UA features.
The point of "UA interventions" is that we realize a spec we had is bad and willfully violate it for the benefit of users.
Designing a new spec with the assumption that UAs will just come up with interventions to work around problems in it is not desirable, especially when the interventions will be easy to detect by sites.
My point was that the interventions themselves should be added to the spec. Designing a spec that doesn't interfere with undocumented interventions is rather challenging.
I don't see why we wouldn't want the frame to know that it was unpaused.
My point was that the interventions themselves should be added to the spec.
Yes, that is my point too. Good, we're in violent agreement. ;)
I don't see why we wouldn't want the frame to know that it was unpaused.
Well, one simple problem is frames that remove themselves from the DOM if unexpectedly unpaused, to hide their stuff...