[inert] Add WPTs for interaction of inert attribute with modal dialog #31668
Conversation
|
@Loirooriol I don't think the specs are necessarily clear on this. https://fullscreen.spec.whatwg.org/#new-stacking-layer says:
Following this definition, modal dialogs should escape inertness, given inert is implemented based on style/rendering. From a web perspective, I don't think anyone will try to open a fullscreen element/modal dialog, with the intent for them to be inert. And if it is their intent to do so, they can set inert explicitly on the modal element. w3c/csswg-drafts#6685 (comment) also resolved on WK behavior fwiw which I described explicitly in the previous comment with the "modal element" proposal being described. cc @emilio |
|
The HTML spec has yet to be updated: whatwg/html#7134 |
|
@nt1m I don't think the CSSWG resolved about dialogs:
Also, seems potentially out of scope for CSS, and better addressed by the WHATWG.
To me this doesn't necessarily imply that it escapes inertness. The CSS cascade still treats it as a child of its parent, not a child of the root. Like, I'm fine with switching Chromium to what Firefox and WebKit do, it would actually be simpler since inertness could be stored as a single bool instead of a 3-valued enum. But the HTML spec seems pretty clear to me, even with your PR whatwg/html#7134 Anyways, regardless of what we do, we need tests. Especially since the 2nd one crashes WebKit. |
chromium-wpt-export-bot
force-pushed
the
chromium-export-cl-3290703
branch
from
64f0950 to
64c677b
Compare
I just wanted to say that I agree with this part. CSS selects <div style="display:none">
<dialog id=d>This is a test</dialog>
</div>
<script>
window.onload = () => d.showModal();
</script>Do you think the |
|
@mfreed7 It's quite unclear tbh, the top layer escapes lots of things. It escapes ancestor CSS
I think this should be clarified when the top layer is moved to a CSS spec. The "etc." is vague and I'm not quite sure what it covers. For instance, if it covers Also, my second argument would be that this is similar to setting this CSS: This is slightly easier to understand in CSS terms. And this reflects in the implementation too, this required a tri-state value for taking in account the ancestor. I don't feel too strongly about this tbh, and I think Emilio doesn't either... |
chromium-wpt-export-bot
force-pushed
the
chromium-export-cl-3290703
branch
from
64c677b to
7943003
Compare
https://html.spec.whatwg.org/multipage/interaction.html#inert is clear: > While document is so blocked [by a modal dialog], every node that is > connected to document, with the exception of the subject element and > its shadow-including descendants, must be marked inert. (The elements > excepted by this paragraph can additionally be marked inert through > other means; being part of a modal dialog does not "protect" a node > from being marked inert.) However, both Firefox and WebKit ignore this, and let modal dialogs escape the inertness set by an ancestor with the 'inert' attribute. There is also an interesting case: when the modal dialog is the root element. Firefox handles this fine, but Chromium used to fail the test, and WebKit directly crashes. Bug: 692360 Change-Id: Ie52201a1f31790392180c96a9e08be1b5eee86d8 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3290703 Commit-Queue: Oriol Brufau <obrufau@igalia.com> Reviewed-by: Mason Freed <masonf@chromium.org> Cr-Commit-Position: refs/heads/main@{#945411}
chromium-wpt-export-bot
force-pushed
the
chromium-export-cl-3290703
branch
from
7943003 to
92b5595
Compare
https://html.spec.whatwg.org/multipage/interaction.html#inert is clear:
However, both Firefox and WebKit ignore this, and let modal dialogs
escape the inertness set by an ancestor with the 'inert' attribute.
There is also an interesting case: when the modal dialog is the root
element. Firefox handles this fine, but Chromium used to fail the test,
and WebKit directly crashes.
Bug: 692360
Change-Id: Ie52201a1f31790392180c96a9e08be1b5eee86d8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3290703
Commit-Queue: Oriol Brufau <obrufau@igalia.com>
Reviewed-by: Mason Freed <masonf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#945411}