Stop propagating inertness into nested browsing contexts

[Loirooriol]

https://html.spec.whatwg.org/multipage/interaction.html#inert

While a browsing context container is marked as inert, its nested browsing context's active document, and all nodes in that Document, must be marked as inert.

Firefox and WebKit don't do this. Blink does, but I'm removing it since it can be a cross-site leak, and blocks fenced frames since it opens a communication channel.

Note that even if the contents in the nested browsing contexts are not marked as inert, if the browsing context container is inert, they won't respond to mouse interactions, and they won't be reached by sequential navigation.

CC @emilio, @nt1m

[nt1m]

I agree, the document inside the iframe should not be able to detect whether the parent document has made the frame inert.

[Loirooriol]

Firefox and WebKit don't do this.

Correction: it seems WebKit still allows selection as if not inert, but .focus() is prevented.

• Focusability: http://wpt.live/html/semantics/interactive-elements/the-dialog-element/inert-focus-in-frames.html
• Selection: http://wpt.live/html/semantics/interactive-elements/the-dialog-element/inertness-with-modal-dialogs-and-iframes.html

[domenic]

So, the cross-site leaks seems bad, so we'll need to do something here for sure. But I don't quite understand what you're saying.

Note that even if the contents in the nested browsing contexts are not marked as inert, if the browsing context container is inert, they won't respond to mouse interactions, and they won't be reached by sequential navigation.

I'm a bit unsure what this means. Are you talking specifically about the container not responding to mouse/sequential focus navigation? Or about the contents too?

If it is specifically about the container, then that seems bad. Sure, if you click on the border of the iframe, it won't get a click event. But if you click on a button inside the iframed page, it will. Similarly, you wouldn't be able to tab directly to the iframe, but you'd still tab to the stuff displayed inside it. That basically means iframes "punch a hole" in inertness for the page.

If this is about the contents too, then I don't understand the distinction you're drawing. If they're not clickable and not tab-to-able and at least in Firefox not selectable, aren't they just inert? And even if there's difference I'm missing, it seems like the communications channel is still present; if there's any operation which behaves differently before/after the container is made inert, then that's a communications channel.

[Loirooriol]

I mean that if you click in the middle of an iframe where there is a focusable element (inside the iframe), then this focusable element won't become focused if the iframe is inert. But a script in the iframe can still use .focus() and focus it, because the element is not inert after removing this propagation.

But if you click on a button inside the iframed page, it will.

This doesn't seem to be happening, pointer-events: none on the iframe prevents this in Blink, WebKit and Gecko.

you'd still tab to the stuff displayed inside it

Yes, if the iframe uses .focus(), then sequential navigation can continue inside the iframe.

If they're not clickable and not tab-to-able and at least in Firefox not selectable, aren't they just inert?

So the idea would be that they would still be kinda inert-ish to the user. But not really inert since iframe scripts would still be able to use .focus() and selection API as usual.

[domenic]

OK. So they can still track user actions cross-site, they just can't communicate programmatically? I'm not sure that's better, but I haven't thought too hard about it...

I don't think #7606 really captures those behaviors you mention, though. E.g. you still tab into the iframe, or are able to click on its contents, since there's now nothing stopping those sections of the spec from applying.

[Loirooriol]

So they can still track user actions cross-site

Not sure what you mean with "track". The iframe contents will still not receive mouse events, etc. so not much tracking to do? They will instead not be able to track if the parent page opens modal dialogs or something that could be detected by JS APIs when propagating inertness.

you still tab into the iframe

Why? Typically you can tab into the contents of a non-inert iframe because:

1. https://html.spec.whatwg.org/multipage/interaction.html#focusable-area

   A browsing context container (e.g. an iframe) is a focusable area

2. https://html.spec.whatwg.org/multipage/interaction.html#sequential-navigation-search-algorithm

   • Let candidate be the first suitable sequentially focusable area in the [...]
   • If candidate is a browsing context container with a non-null nested browsing context, then let new candidate be the result of running the sequential navigation search algorithm with candidate's nested browsing context as the first argument, direction as the second, and sequential as the third.

But if the iframe is inert, then it's not a candidate:

A suitable sequentially focusable area is a focusable area whose DOM anchor is not inert and is sequentially focusable.

so the algorithm skips the iframe (and all it's contents).

So maybe I wasn't clear enough: tabbing won't go into an inert iframe if the focus is outside of it. But if the focus is inside of it, then tabbing can navigate contents of the inert iframe, and go outside of it.

or are able to click on its contents

Well, I guess the CSS spec about pointer-events should explicitly define what happens when an iframe gets pointer-events: none, but we have interoperability that the click doesn't go into the iframe contents.

[domenic]

Not sure what you mean with "track". The iframe contents will still not receive mouse events, etc. so not much tracking to do? They will instead not be able to track if the parent page opens modal dialogs or something that could be detected by JS APIs when propagating inertness.

So in particular if a parent page's intent is to make (for example) an ad inert, in order to prevent it from tracking the user's mouse movements, that will no longer be possible from what I understand. More generally, a lot more information can now leak to the inert frame about the user's behavior than before. This might be worth it, to avoid the case of a collaborating top-level page passing information to the ad; I know that case is on peoples' minds a lot these days. But I wanted to be sure we're all recognizing the tradeoffs.

Why? Typically you can tab into the contents of a non-inert iframe because:

Thanks, you're right.

So maybe I wasn't clear enough: tabbing won't go into an inert iframe if the focus is outside of it. But if the focus is inside of it, then tabbing can navigate contents of the inert iframe, and go outside of it.

Yeah, I think it's surprising you can put focus inside an inert iframe at all. I think that's what the original spec was trying to prevent. But if we think that's the desired behavior, and we have web platform tests for this case, then OK. (Specifically for allowing focus, e.g. programmatically, inside an inert iframe; and then allowing TAB to take you out of the iframe.)

Well, I guess the CSS spec about pointer-events should explicitly define what happens when an iframe gets pointer-events: none, but we have interoperability that the click doesn't go into the iframe contents.

Inertness is not specified in terms of pointer-events currently.

I guess maybe "When a node is inert, then the user agent must act as if the node was absent for the purposes of targeting user interaction events" could apply; if the iframe node is absent, then targeting user interaction events is probably not going to work at the iframe's contents.

What about mouse move events, though?

[Loirooriol]

in order to prevent it from tracking the user's mouse movements

pointer-events: none should prevent that.

Inertness is not specified in terms of pointer-events currently.

The CSSWG resolved that inertness forces pointer-events: none at used-value time, w3c/csswg-drafts#6685 (comment). So I guess that should go into some spec, HTML or CSS-UI.

I guess maybe ...

Yes, but I would rather defer the exact details to the definition of pointer-events: none in CSS-UI. Which currently is along these lines, but can become more comprehensive in the future.

What about mouse move events, though?

They should be avoided by pointer-events: none: https://software.hixie.ch/utilities/js/live-dom-viewer/saved/10057

[domenic]

OK, so yeah, we should definitely specify that inertness causes pointer-events none somehow.

I guess that doesn't strictly need to be a blocker for this change, but it'd be reassuring if we had a path toward it.

Tests for mouse move events would also be good.

[Loirooriol]

BTW, I filed w3c/csswg-drafts#7069 for making it explicit that pointer-events: none in iframe makes hit-testing skip its contents, as all browsers already do.

[Loirooriol]

I have created web-platform-tests/wpt#32905 for testing more events like mousemove, and that it's possible to tab within an inert iframe or leave it if focus is already there.