Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Impact of inert on hit-testing needs to be specified #6685

Open
smfr opened this issue Sep 24, 2021 · 7 comments
Open

Impact of inert on hit-testing needs to be specified #6685

smfr opened this issue Sep 24, 2021 · 7 comments
Labels
css-ui-4 Current Work

Comments

@smfr
Copy link
Contributor

smfr commented Sep 24, 2021

This is a CSS placeholder for whatwg/html#5650, since the CSS WG needs to (eventually) specify hit-testing, but in the shorter term come to an agreement on how the inert attribute affects hit-testing.
@nt1m
Copy link
Member

nt1m commented Sep 27, 2021 •
edited
Loading

Chrome's current behaviour:

  • Makes node "disabled"/"inactive"
  • Event target is retargeted using a magic algorithm for "user input events" (this is not well specified)
  • elementsFromPoint still returns inert node
  • Purely DOM based inert inheritance: node with inert attribute as parent of modal <dialog> makes that <dialog> inert
  • (implementation detail): Node::isInert() is Chromium is sort of a lie in the modal dialog case: Node::isInert will return true for an ancestor of a modal dialog (if document is blocked by a modal dialog), so <body> would technically be inert, but the <dialog> would still be interactable?!

WebKit's implemented behaviour:

  • Applies pointer-events: none; style behaviour on any inert node
  • Overrides it with pointer-events: auto on a modal <dialog> unless <dialog> specifically has the inert attribute set.
  • Event target/elementsFromPoint works similarly as a pointer-events: none node
  • CSS based approach: node with inert attribute as parent of modal <dialog> does not make the dialog inert!
  • Does not change pointer-events computed style

Firefox's implemented behaviour:

  • Identical to WebKit, except modal <dialog> can never be inert, even with the inert attribute set explicitly on the dialog.
  • Sets pointer-events resolved style to none on inert nodes (so it does affect computed style!)

Proposal:

  • Make nodes with inert attribute act like pointer-events: none
  • Introduce the concept of "modal element" which encompasses:
    • topmost modal <dialog>
    • current fullscreen element

The modal element wouldn't be affected by any ancestor with the inert attribute, but the inert attribute explicitly set on a modal element can make it inert.

  • Redefine "blocked by a modal dialog" concept to:
    • Make the top most modal dialog the current modal element
    • Make the document element inert
  • TODO: should it affect pointer-events computed style?

@smfr
Copy link
Contributor Author

smfr commented Sep 28, 2021

See also #4499 and #6280

@bradkemper
Copy link
Contributor

bradkemper commented Sep 28, 2021 •
edited
Loading

I'd like to see inert being handled in a way similar to WebKit, but still affecting computed value. Pointer-events is a good start, and could be made more granular for disabling just scroll wheel, etc. I think ewe should also have something like keyboard-events: none to be able to also disable keyboard events and tabbing to the element, which should maybe also make the element unreachable from screen readers too.

@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed effect of inert on hit testing, and agreed to the following:

  • RESOLVED: Resolve on WK behavior. Use pointer-events:none, but don't reflect into computed style (use "behaves as" wording); same with user-select and related focus behavior
  • RESOLVED: Add definition of p-e:none, at least, to UI 4
  • RESOLVED: Steal the top-layer spec from Fullscreen, put it into Position 3.
The full IRC log of that discussion <TabAtkins> Topic: effect of inert on hit testing
<TabAtkins> github: https://github.com//issues/6685
<TabAtkins> smfr: There has been a history of impls of `inert` that haven't matched
<TabAtkins> smfr: Chrome and Gecko already mismatch, now WebKit is implementing and want a spec that is clear
<TabAtkins> smfr: Historically, Chrome's was mor ein terms of DOM propagation
<TabAtkins> smfr: If an event hit an inert node it woudl skip up to an ancestor
<TabAtkins> smfr: Gecko was in terms of pointer-events; it woudl ignore the inert element so clicks could go to underneath it
<TabAtkins> smfr: On a call a few weeks ago chrishtr said he'd talk to Google folks and see if they're okay with doing Gecko's behavior
<TabAtkins> smfr: Also questions about whether inert effects APIs like elementFromPoint()
<TabAtkins> smfr: And some keyboard interactions
<TabAtkins> chrishtr: I did not unfortunatley get to talk to a11y team in Chrome, but I did review the discussions again.
<TabAtkins> chrishtr: I think there are pros and cons to both; I think we could just discuss Tim's proposal point-by-point and see if it's okay to everyone
<TabAtkins> chrishtr: Also no browsers publicly ship the attribute yet, so all browsers are still changeable right now
<bkardell_> q+
<TabAtkins> smfr: Dialog and Fullscreen specs refer to inert and say it should be applied to the document, with the dialog/fullscreen excepted from the effect
<TabAtkins> smfr: So even if the attribute ahsn't shipped, there are implications on those features
<TabAtkins> chrishtr: I didn't look at the code for dialog/fullscreen, did anyone else
<TabAtkins> chrishtr: I assume it ignores hit-test events in the dialog
<TabAtkins> chrishtr: So I think we can discuss this holistically and probably dialog impl coudl be changed in Chromium, unless someone knows about compat problems
<TabAtkins> emilio: I doubt the set order issue is going to be a problem for fullscreen/dialog, because they're on the top layer and thus always on top of everything else
<TabAtkins> emilio: In terms of impl, Gecko's has an internal CSS property called 'inert', and we apply it to everything and reset it on the dialog, that has effects on pointer-events and such
<astearns> ack bkardell_
<TabAtkins> bkardell_: Interesting bc dialog was defined with the terms of top-layer and inertness, but didn't expose them or refer to them elsewhere. They're two separate but related problems, and depending on what you do with the top layer it helps answer the other questions
<TabAtkins> bkardell_: The way libraries today make dialogs is to create a pseudo-top-layer that's a top-level child of body, so they can make everything else inert
<TabAtkins> bkardell_: When we define that, and Alice did the initial impl and we did the polyfill, some of the things around top layer are a little wonky maybe
<TabAtkins> bkardell_: There ahs been an incredible amount of discussion on this topic. Before Alice left on sabbatical, she agreed there were things in Chrome to work on.
<TabAtkins> bkardell_: So I think it's worth talking about top-layer first to set up the questions about inert, imo
<smfr> q+
<TabAtkins> chrishtr: I see now that Tim did put some comments on Chrome's behavior and quirks
<astearns> ack smfr
<TabAtkins> smfr: One fo the fundamental difficulties is the inert spec says you can't make a descendant of an inert node non-inert, and yet the dialog spec says the document is inert and then the dialog (a child of the document) is non-inert...
<TabAtkins> smfr: And if the impl is pointer-events based, youa re allowed to make a descendant of a pointer-events:none node pointer-events:normal
<TabAtkins> ntim: WebKit recently implemented a pointer-events-based approach, similar to Firefox
<TabAtkins> astearns: So bkardell_ suggested starting with top layer
<TabAtkins> bkardell_: So let's discuss how it's defined and how it works
<TabAtkins> bkardell_: If it works something like existing impls in libraries, so it's effectively projected to a sibling of the document, we can think about it one way
<smfr> q+
<TabAtkins> bkardell_: If talking about the tree itself and where it lives normally in the tree, things get a lot more complicated
<TabAtkins> q+
<astearns> ack smfr
<TabAtkins> smfr: I think we're happy with the way top-layer is specified; it renders z-ordered above the rest of the doc
<chrishtr> q+
<TabAtkins> smfr: I think Chrome/WEbKit do that now
<TabAtkins> smfr: If there are implications for event propagation, maybe they're not clear enough
<fantasai> scribe+
<astearns> ack TabAtkins
<fantasai> TabAtkins: IIRC, the way we've described top layer is that it get reparented in the layer tree sense
<fantasai> TabAtkins: being a direct child of the top-level document/canvas/thing
<fantasai> TabAtkins: That way nothing can interfere with its positioning
<fantasai> TabAtkins: That's how we specced it, are we doing something different now?
<fantasai> chrishtr: No, that's what spc and impl do
<fantasai> chrishtr: reparent into new stacking context that is z-indexed above everything else
<fantasai> chrishtr: It's well-specified, afaict
<fantasai> TabAtkins: Shouldn't have any effect on events, that works normally
<ntim> smfr: https://fullscreen.spec.whatwg.org/#rendering
<fantasai> chrishtr: My guess is chromium, hit testing happens on the layout box tree
<fantasai> chrishtr: so the impl probably sees the dialog element and then fails to look up the tree to see the inert attribute above it
<fantasai> chrishtr: If you see an inert node, stop at that node, but don't check ancestors
<fantasai> chrishtr: I think that's how impl, and not consistent with spec
<fantasai> chrishtr: Maybe we should discuss directly, should the impl just be exactly what Firefox and WebKit have already implemented?
<fantasai> chrishtr: Seems the difference is "?? cannot be iner, except when ... dialog"
<fantasai> emilio: That's a Gecko bug
<fantasai> emilio: Dialog is inert, we use the same mechanism
<fantasai> emilio: should be fixable
<fantasai> emilio: Rest of document is inert so can't do anything
<fantasai> emilio: but that seems like Gecko bug
<fantasai> emilio: other is, does this affect computed value of pointer-events?
<fantasai> emilio: In Gecko it does
<fantasai> emilio: The alternative was to have an internal property and check that everywhere you check pointer-events: none
<fantasai> emilio: This way clearer for implementers and authors
<fantasai> emilio: And less likely to accidentally cause divergence in the future
<fantasai> s/authors/more useful to authors/
<fantasai> chrishtr: UA style sheet?
<fantasai> emilio: A bit more magic than that
<fantasai> emilio: It's like an inherited property, which causes a bunch of other properties to compute differently
<fantasai> emilio: It's conceptually same as UA rule
<fantasai> emilio: In practice, we made an internal property to handle the inheritance.
<fantasai> emilio: Anything in subtree will have pointer-events: none forever, unless inert value is changed on descendant
<fantasai> [discussion of the implementation detail and how it's not visible to authors]
<fantasai> bkardell_: ???
<fantasai> emilio: ????
<fantasai> chrishtr: What about dialog?
<ntim> https://searchfox.org/mozilla-central/source/layout/style/res/ua.css#171
<ntim> https://searchfox.org/mozilla-central/source/layout/style/res/html.css#836
<fantasai> emilio: Sets the internal bit on the document element
<fantasai> emilio: and then dialog has a UA rule that applies this inert property to the default when modal
<smfr> s/???/does that also affect the accessibility bits?// ans: yes
<fantasai> chrishtr: So special exception not accessible to developers
<fantasai> emilio: right
<fantasai> emilio: There's no way, spec-wise, for devs to override that
<fantasai> emilio: we could add that capability, unsure how it would look
<fantasai> emilio: Spec says anything under inert subtree is inert, and no way to un-inert a node
<fantasai> flackr: I think it'd get complicated for anything other than top-layer to override
<fantasai> bkardell_: That's why top layer is important here
<fantasai> bkardell_: if you are in top layer, can reason about things
<fantasai> bkardell_: some details that are observable that we need to agree on and document
<fantasai> bkardell_: I believe that back in April, Alice suggested that she might want to take a look at revamping some of Chrome's internals to use a pointer-events-like behavior
<fantasai> bkardell_: There was some hesitance to say the magic *was* pointer-events
<fantasai> bkardell_: because seemed architecturally unfortunate
<fantasai> emilio: why?
<fantasai> emilio: pointer-events shouldn't really be a CSS property, but we're way past that point now
<fantasai> emilio: So given that, I'm happy to say that inert is managed via pointer-events
<fantasai> chrishtr: In the Intent to Ship that didn't complete for this feature
<fantasai> chrishtr: Alice tried it and didn't like it
<fantasai> chrishtr: Didn't like that not targettable from getElementsFromPoint
<fantasai> bkardell_: makes inspector break
<fantasai> emilio: yeah, but that's an issue with inspector
<smfr> q+
<fantasai> chrishtr: It doesn't make sense to have pointer-events: none; and then ...
<fantasai> chrishtr: UA can special-case inspector
<fantasai> bkardell_: we have problem with top layer already, can't inspect stuff underneath
<astearns> ack chrishtr
<astearns> ack smfr
<fantasai> smfr: We could always add an options dictionary to getElementsFromPoint
<TabAtkins> smfr: To let it include pointer-events:none or inert if we wanted to
<TabAtkins> bkardell_: And then devtools would use that by defualt
<TabAtkins> chrishtr: and we could do that as a feature enhancement and devtools can just use magic
<TabAtkins> chrishtr: asking tim/simon, is what Emilio said consistent with what WebKit does?
<TabAtkins> chrishtr: You do some magic thing that makes descendants of inert p-e:none and the dialog is exempted?
<TabAtkins> ntim: It's mostly the same yeah, we just don't hcange the computed styles for pointer-events
<TabAtkins> emilio: I slightly prefer actually changing the computed style, for the reasons i described before, but don't feel super strongly.
<TabAtkins> emilio: Would just be a little unfortunate and easy to make mistakes in the future for authors
<TabAtkins> ntim: Not changing computed styles gives us flexibility to change inert in the future or not be fully consistent with the p-e:none value, but don't feel strongly either
<TabAtkins> bkardell_: I have a slight pref for Apple's because it makes the impl detail visible
<TabAtkins> emilio: We do specify some things in terms of UA style, and other things in terms of "behaves as", so I don't have a strong opinion, it's just a slight pref toward reflecting it in the computed style
<bkardell_> s/makes the impl detail visible/ff's makes the implementation details observable
<TabAtkins> chrishtr: So it sounds like what's already in WK/Gecko is fine, and Chrome can change and the WG can agree on that in spec
<TabAtkins> chrishtr: So next is whether pointer-events:none is okay
<TabAtkins> astearns: Do we want to resolve on that first?
<TabAtkins> chrishtr: Talk about the next first
<TabAtkins> chrishtr: So Chrome originates the event up the tree to the first non-inert ancestor, Gecko just hit-tests down to the next non-inert in the stacking layer
<TabAtkins> chrishtr: I see why Gecko does this - it's easy to reuse behavior - but do we think it's the right semantic choice?
<TabAtkins> emilio: No strong opinion, but if there is a better choice it shoudl be a pointer-events value
<TabAtkins> ntim: Makes sense to me because you can have non-inerts inside of inert trees
<TabAtkins> chrishtr: But that's non web-exposed as a feature, just for this thing
<TabAtkins> TabAtkins: But it's a reasonable use-case that authors would want to do similar things with; why would we treat it as a special case they can't use?
<TabAtkins> chrishtr: Right. I think the question of mixed inertness is separate from whether you hit-test below it.
<TabAtkins> emilio: Yes, orthogonal
<smfr> q+
<TabAtkins> chrishtr: So argument ot make is that p-e:none is already there and sky isn't falling, so maybe it's fine
<TabAtkins> emilio: Yeah, and if we did it another way anyway, we should just add a new p-e value to it
<TabAtkins> flackr: I think hit-testing behidn the thing works well for a lot of use-cases where you have an event handler on an ancestor
<TabAtkins> TabAtkins: That works either way tho - Chrome's behavior will walk the
<TabAtkins> smfr: But that could mean an element gets the event even if you're lcicking elsewhere, if the clicked child is positioned outside
<TabAtkins> TabAtkins: Yeah, but it would have gotten the element if the child weren't inert
<TabAtkins> smfr: [missed about backdrop]
<TabAtkins> ntim: You can display:none the ::backdrop
<TabAtkins> ntim: Question was if we can pierce the top-layer, yes we can
<TabAtkins> chrishtr: Visually yes, but not hit-testing
<TabAtkins> ntim: Because everything else is inert, yes
<emilio> q+
<astearns> ack smfr
<chrishtr> q+
<TabAtkins> emilio: Lacking a strong use-case to pursue a new p-e value, I suggest we just stick with none, and maybe change in the future if we feel it's needed
<TabAtkins> emilio: I'm okay on blocking on the new value if people think it's useful, but unless there's a strong reason to do it...
<TabAtkins> flackr: And there are a lot of use-case for *not* hitting an ancestor, which is p-e:none today, so we should stick with that by default
<astearns> ack chrishtr
<emilio> ack emilio
<TabAtkins> chrishtr: Agree with emilio and rob that we don't have a strong reasons to *not* use p-e:none, so we should just use that
<TabAtkins> chrishtr: So that allows us to resolve
<TabAtkins> chrishtr: I propose we resolve on the webkit behavior - don't expose the computed style (for the reason brian mentioned) and use p-e:none behavior
<TabAtkins> chrishtr: And when inert is set, force p-e, focus, etc in a user-agent way that's not exposed to devs
<TabAtkins> chrishtr: And elementFromPoint() skips the inert elements
<TabAtkins> astearns: I'm a little concerned about having this magic UA behavior...
<TabAtkins> astearns: If it's not *expressible* by authors; I want to make sure that what the UA does is something all the engines can implement in an interoperable way
<TabAtkins> astearns: Usually that means we have a property with the behavior
<TabAtkins> astearns: I'm concerned that magic means we might not get the details right
<TabAtkins> chrishtr: emilio, am I right that the Gecko impl just sets a UA-internal prop?
<TabAtkins> emilio: Yeah
<TabAtkins> flackr: And I think it's equivalent to a descendant selector with p-e:none in the UA, and equivalent rule for modals, etc
<TabAtkins> emilio: Not quite there becuase of shadow dom, it's actually inherited, but close enough
<TabAtkins> astearns: I don't think we've done a feature as a magic property
<TabAtkins> TabAtkins: We've never *specified* one as such, but several features are implemented as such
<fantasai> +1 I'm not concerned about speccing this
<emilio> +1
<TabAtkins> bkardell_: I kinda agree with everyone else; if we can come up with a demonstrable reason to expose this, that should be a separate discussion
<astearns> ack fantasai
<TabAtkins> Proposed resolution: Resolve on WK behavior. Use pointer-events:none, but don't reflect into computed style (use "behaves as" wording); same with user-select and related focus behavior
<TabAtkins> ntim: question about interaction of inert and modals, what if you have an inert node as ancestor of modal?
<TabAtkins> emilio: depends on details of how we spec, maybe modal dialogs are just always non-inert
<TabAtkins> bkardell_: The direct descendant of a top-layer should never be inert, right?
<TabAtkins> ntim: We could let people explicitly opt out of inert
<TabAtkins> emilio: I agree this is a different issue
<TabAtkins> emilio: If we decide that inert works this way, they can still spec it how they want
<TabAtkins> emilio: I do think that a modal dialog should never be inert unless exlicitly given inert
<TabAtkins> bkardell_: Do we need to talk about isInert()?
<TabAtkins> ntim: That's internal
<TabAtkins> ntim: What about <dialog modal inert>?
<TabAtkins> emilio: We should let HTML decide on that
<TabAtkins> emilio: I think it's edge-casey and we should just deal with the general problems here
<TabAtkins> astearns: So punt on explicitly-inert dialog question for now.
<TabAtkins> astearns: Any other discussion?
<TabAtkins> smfr: Where are we writing this? No spec for hit-testing yet
<TabAtkins> chrishtr: Should it live in HTML?
<TabAtkins> TabAtkins: We've got other hit-testing things that we need to define in CSS
<TabAtkins> chrishtr: But for this it just needs to define that something "behaves as..."
<TabAtkins> ntim: And there's already an HTML heading for it
<TabAtkins> florian: Do we need a spec for this with a "Hit Testing: TBD" section?
<TabAtkins> chrishtr: Yes, I took an action item to find someone for that two weeks ago.
<TabAtkins> chrishtr: Would be useful to make an empty spec with a TODO
<TabAtkins> fantasai: Maybe useful for a subsection in UI-4?
<florian> s/with a "Hit Testing: TBD" section?/with a "Hit Testing: TBD" section, and the rest of the spec being a copy of the relevant part of CSS2?/
<TabAtkins> florian: pointer-events:none is not really specified
<ntim> https://html.spec.whatwg.org/multipage/interaction.html#inert-subtrees
<TabAtkins> chrishtr: Oh yeah jeez, we should add a paragraph saying p-e:none means you're not hit-tested
<ntim> top layer is very intuitively in fullscreen
<TabAtkins> RESOLVED: Resolve on WK behavior. Use pointer-events:none, but don't reflect into computed style (use "behaves as" wording); same with user-select and related focus behavior
<TabAtkins> RESOLVED: Add definition of p-e:none, at least, to UI 4
<chrishtr> @smfr what was the top layer stuff that needed specifying that tab just mentioned?
<smfr> chrishtr: see https://fullscreen.spec.whatwg.org/#rendering
<TabAtkins> Yeah they want us to steal that section
<TabAtkins> So we should
<fantasai> [disussing who should draft spec text]
<fantasai> TabAtkins: Also, should we steal the rendering section of fullscreen and import into csswg?
<TabAtkins> smfr: We might already ahve a resolution for specifying top-level
<TabAtkins> astearns: so proposed resolution is to put top layer into Positioning if we don't already have a resolution for it
<TabAtkins> bkardell_: There were some PRs about top layer in HTML itself.
<TabAtkins> astearns: I imagine we can steal the current spec text as-is and the inherit any issues from Fullscreen and HTML
<TabAtkins> astearns: objections?
<TabAtkins> RESOLVED: Steal the top-layer spec from Fullscreen, put it into Position 3.
<emilio> \o/ for making progress on `inert`

@mozilla-apprentice mozilla-apprentice mentioned this issue Sep 29, 2021
Open
frivoal added a commit that referenced this issue Sep 30, 2021
@frivoal
[css-ui-4] Define 'pointer-events'
7e11396 
As resolved in #6685 (comment)
@frivoal
Copy link
Collaborator

frivoal commented Sep 30, 2021

As resolved above, I've added a stub spec for pointer-events to css-ui-4: https://drafts.csswg.org/css-ui-4/#pointer-events-control (give it some time for the spec to be rebuilt). Please open new issues for any follow up on that.

nt1m added a commit to web-platform-tests/wpt that referenced this issue Oct 4, 2021
@nt1m
Remove inert event retargeting tests (#30866)
17f95b6 
See w3c/csswg-drafts#6685
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Oct 6, 2021
@nt1m @moz-wptsync-bot
Bug 1733979 [wpt PR 30866] - Remove inert event retargeting tests, a=…
0ae3cf2 
…testonly

Automatic update from web-platform-tests
Remove inert event retargeting tests (#30866)

See w3c/csswg-drafts#6685
--

wpt-commits: 17f95b6d1e12b1a4bebfbff42fcd4d6fb8efc269
wpt-pr: 30866
jamienicol pushed a commit to jamienicol/gecko that referenced this issue Oct 7, 2021
@nt1m @moz-wptsync-bot
Bug 1733979 [wpt PR 30866] - Remove inert event retargeting tests, a=…
6ca0e13 
…testonly

Automatic update from web-platform-tests
Remove inert event retargeting tests (#30866)

See w3c/csswg-drafts#6685
--

wpt-commits: 17f95b6d1e12b1a4bebfbff42fcd4d6fb8efc269
wpt-pr: 30866
blueboxd pushed a commit to blueboxd/chromium-legacy that referenced this issue Nov 17, 2021
@Loirooriol
[inert] Force 'pointer-events: none' on inert nodes at used-value time
6aadd45 
The CSSWG resolved that inert nodes should behave as if they had
'pointer-events: none', but without changing the computed style.
w3c/csswg-drafts#6685 (comment)

This is done by adding a public ComputedStyle::UsedPointerEvents() that
returns EPointerEvents::kNone for inert, and privatizing the existing
ComputedStyle::PointerEvents() just for friend classes.

Note that computed_style_fields.py needs to be tweaked, otherwise the
automatically generated PropagateIndependentInheritedProperties() would
still try to call ResetPointerEventsIsInherited(), which is no longer
defined. Now it needs to be ResetPointerEventsIsInheritedInternal().

After this change, it will be possible to remove the hit-testing
retargeting for inert.

Bug: 692360

TEST=external/wpt/html/semantics/interactive-elements/the-dialog-element/dialog-inert.tentative.html
TEST=external/wpt/inert/inert-computed-style.html

Change-Id: I720908d3e1c47d7cd13b9fe9e1110e44ff70f56b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3281968
Reviewed-by: Anders Hartvoll Ruud <[email protected]>
Reviewed-by: Rune Lillesveen <[email protected]>
Commit-Queue: Oriol Brufau <[email protected]>
Cr-Commit-Position: refs/heads/main@{#942180}
blueboxd pushed a commit to blueboxd/chromium-legacy that referenced this issue Nov 18, 2021
@Loirooriol
[inert] Remove hit test retargeting for inert
e2b9c07 
r942180 made inert nodes behave as 'pointer-events: none', as resolved
by the CSSWG in w3c/csswg-drafts#6685

Then, the magic hit test retargeting for inert is no longer needed.

Bug: 692360
Change-Id: I950f0967f093d6acb20877e049fb1bcf75a88de1
Cq-Do-Not-Cancel-Tryjobs: true
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3257651
Commit-Queue: Oriol Brufau <[email protected]>
Reviewed-by: Koji Ishii <[email protected]>
Reviewed-by: Nektarios Paisios <[email protected]>
Cr-Commit-Position: refs/heads/main@{#942823}
Gabisampaio pushed a commit to Gabisampaio/wpt that referenced this issue Nov 18, 2021
@nt1m @Gabisampaio
Remove inert event retargeting tests (web-platform-tests#30866)
58e02dd 
See w3c/csswg-drafts#6685
@nt1m nt1m mentioned this issue Nov 19, 2021
Merged
@fantasai fantasai added the css-ui-4 Current Work label Jan 26, 2022
@Loirooriol Loirooriol mentioned this issue Feb 8, 2022
Closed
aarongable pushed a commit to chromium/chromium that referenced this issue Feb 15, 2022
@Loirooriol
[inert] Force 'user-select: none' on inert nodes at used-value time
f1944a2 
The CSSWG resolved that inert nodes should behave as if they had
'user-select: none', but without changing the computed style.
w3c/csswg-drafts#6685 (comment)

This is done by adding a public ComputedStyle::UsedUserSelect() that
returns EUserSelect::kNone for inert, and privatizing the existing
ComputedStyle::UserSelect() just for friend classes.

This doesn't seem to have much impact to editing since IsSelectable()
was already checking IsInert().

But now accessibility will set kNotUserSelectableStyle=true when inert.

Bug: 692360

TEST=All/DumpAccessibilityTreeTestWithIgnoredNodes.InertAttribute/blink

AX-Relnotes: Inert nodes will be considered non-selectable.
Change-Id: Iffc15fb90976234768721a6e006de9b6defeee55
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3460673
Reviewed-by: Aaron Leventhal <[email protected]>
Reviewed-by: Rune Lillesveen <[email protected]>
Commit-Queue: Oriol Brufau <[email protected]>
Cr-Commit-Position: refs/heads/main@{#971185}
This was referenced Feb 17, 2022
Closed
Open
Merged
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Feb 24, 2022
@Loirooriol @chromium-wpt-export-bot
[inert] Force 'user-modify: none' on inert nodes at used-value time
c1ba173 
This is done by adding a public ComputedStyle::UsedUserModify() that
returns EUserModify::kNone for inert, and privatizing the existing
ComputedStyle::UserModify() just for friend classes.

Code related to the style resolver, style adjuster, inheritance, etc.
continues using UserModify(), since inert should only change used styles
w3c/csswg-drafts#6685 (comment)

Forcing 'user-modify: none' wasn't explicitly resolved by the CSSWG, but
it solves the inconsistency of editing commands having different
behaviors when executed in a node which is both in inert and editable
subtrees, depending on whether the inert root is a descendant of the
editing root, or an inclusive ancestor.

Forcing 'user-modify: none' is also consistent with Firefox, though it
doesn't have much effect there, it doesn't avoid editability.

Bug: 692360

TEST=external/wpt/inert/inert-and-contenteditable.tentative.html

Change-Id: I4a34b9715272019b0b8daae0fd5ed3e25e38eddf
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Feb 24, 2022
@Loirooriol @chromium-wpt-export-bot
[inert] Force 'user-modify: none' on inert nodes at used-value time
e451f9e 
This is done by adding a public ComputedStyle::UsedUserModify() that
returns EUserModify::kNone for inert, and privatizing the existing
ComputedStyle::UserModify() just for friend classes.

Code related to the style resolver, style adjuster, inheritance, etc.
continues using UserModify(), since inert should only change used styles
w3c/csswg-drafts#6685 (comment)

Forcing 'user-modify: none' wasn't explicitly resolved by the CSSWG, but
it solves the inconsistency of editing commands having different
behaviors when executed in a node which is both in inert and editable
subtrees, depending on whether the inert root is a descendant of the
editing root, or an inclusive ancestor.

Forcing 'user-modify: none' is also consistent with Firefox, though it
doesn't have much effect there, it doesn't avoid editability.

Bug: 692360

TEST=external/wpt/inert/inert-and-contenteditable.tentative.html

Change-Id: I4a34b9715272019b0b8daae0fd5ed3e25e38eddf
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3486876
Reviewed-by: Rune Lillesveen <[email protected]>
Commit-Queue: Oriol Brufau <[email protected]>
Cr-Commit-Position: refs/heads/main@{#974783}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Feb 24, 2022
@Loirooriol @chromium-wpt-export-bot
[inert] Force 'user-modify: none' on inert nodes at used-value time
727e9fb 
This is done by adding a public ComputedStyle::UsedUserModify() that
returns EUserModify::kNone for inert, and privatizing the existing
ComputedStyle::UserModify() just for friend classes.

Code related to the style resolver, style adjuster, inheritance, etc.
continues using UserModify(), since inert should only change used styles
w3c/csswg-drafts#6685 (comment)

Forcing 'user-modify: none' wasn't explicitly resolved by the CSSWG, but
it solves the inconsistency of editing commands having different
behaviors when executed in a node which is both in inert and editable
subtrees, depending on whether the inert root is a descendant of the
editing root, or an inclusive ancestor.

Forcing 'user-modify: none' is also consistent with Firefox, though it
doesn't have much effect there, it doesn't avoid editability.

Bug: 692360

TEST=external/wpt/inert/inert-and-contenteditable.tentative.html

Change-Id: I4a34b9715272019b0b8daae0fd5ed3e25e38eddf
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3486876
Reviewed-by: Rune Lillesveen <[email protected]>
Commit-Queue: Oriol Brufau <[email protected]>
Cr-Commit-Position: refs/heads/main@{#974783}
DanielRyanSmith pushed a commit to DanielRyanSmith/wpt that referenced this issue Feb 28, 2022
@Loirooriol @DanielRyanSmith
[inert] Force 'user-modify: none' on inert nodes at used-value time
1b6ebae 
This is done by adding a public ComputedStyle::UsedUserModify() that
returns EUserModify::kNone for inert, and privatizing the existing
ComputedStyle::UserModify() just for friend classes.

Code related to the style resolver, style adjuster, inheritance, etc.
continues using UserModify(), since inert should only change used styles
w3c/csswg-drafts#6685 (comment)

Forcing 'user-modify: none' wasn't explicitly resolved by the CSSWG, but
it solves the inconsistency of editing commands having different
behaviors when executed in a node which is both in inert and editable
subtrees, depending on whether the inert root is a descendant of the
editing root, or an inclusive ancestor.

Forcing 'user-modify: none' is also consistent with Firefox, though it
doesn't have much effect there, it doesn't avoid editability.

Bug: 692360

TEST=external/wpt/inert/inert-and-contenteditable.tentative.html

Change-Id: I4a34b9715272019b0b8daae0fd5ed3e25e38eddf
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3486876
Reviewed-by: Rune Lillesveen <[email protected]>
Commit-Queue: Oriol Brufau <[email protected]>
Cr-Commit-Position: refs/heads/main@{#974783}
@annevk
Copy link
Member

annevk commented Mar 10, 2022

The inert attribute is now part of HTML. We essentially defer to pointer-events as far as hit testing goes. Perhaps that means this can be closed?

Commit is whatwg/html@755ae90.

@Loirooriol Loirooriol mentioned this issue Mar 14, 2022
Open
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Mar 22, 2022
@Loirooriol @moz-wptsync-bot
Bug 1756993 [wpt PR 32967] - [inert] Force 'user-modify: none' on ine…
b1fa7e8 
…rt nodes at used-value time, a=testonly

Automatic update from web-platform-tests
[inert] Force 'user-modify: none' on inert nodes at used-value time

This is done by adding a public ComputedStyle::UsedUserModify() that
returns EUserModify::kNone for inert, and privatizing the existing
ComputedStyle::UserModify() just for friend classes.

Code related to the style resolver, style adjuster, inheritance, etc.
continues using UserModify(), since inert should only change used styles
w3c/csswg-drafts#6685 (comment)

Forcing 'user-modify: none' wasn't explicitly resolved by the CSSWG, but
it solves the inconsistency of editing commands having different
behaviors when executed in a node which is both in inert and editable
subtrees, depending on whether the inert root is a descendant of the
editing root, or an inclusive ancestor.

Forcing 'user-modify: none' is also consistent with Firefox, though it
doesn't have much effect there, it doesn't avoid editability.

Bug: 692360

TEST=external/wpt/inert/inert-and-contenteditable.tentative.html

Change-Id: I4a34b9715272019b0b8daae0fd5ed3e25e38eddf
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3486876
Reviewed-by: Rune Lillesveen <[email protected]>
Commit-Queue: Oriol Brufau <[email protected]>
Cr-Commit-Position: refs/heads/main@{#974783}

--

wpt-commits: 727e9fba27829221cda0e4691b0610940f4a0fbc
wpt-pr: 32967
aosmond pushed a commit to aosmond/gecko that referenced this issue Mar 26, 2022
@Loirooriol @moz-wptsync-bot
Bug 1756993 [wpt PR 32967] - [inert] Force 'user-modify: none' on ine…
f3d8d5d 
…rt nodes at used-value time, a=testonly

Automatic update from web-platform-tests
[inert] Force 'user-modify: none' on inert nodes at used-value time

This is done by adding a public ComputedStyle::UsedUserModify() that
returns EUserModify::kNone for inert, and privatizing the existing
ComputedStyle::UserModify() just for friend classes.

Code related to the style resolver, style adjuster, inheritance, etc.
continues using UserModify(), since inert should only change used styles
w3c/csswg-drafts#6685 (comment)

Forcing 'user-modify: none' wasn't explicitly resolved by the CSSWG, but
it solves the inconsistency of editing commands having different
behaviors when executed in a node which is both in inert and editable
subtrees, depending on whether the inert root is a descendant of the
editing root, or an inclusive ancestor.

Forcing 'user-modify: none' is also consistent with Firefox, though it
doesn't have much effect there, it doesn't avoid editability.

Bug: 692360

TEST=external/wpt/inert/inert-and-contenteditable.tentative.html

Change-Id: I4a34b9715272019b0b8daae0fd5ed3e25e38eddf
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3486876
Reviewed-by: Rune Lillesveen <[email protected]>
Commit-Queue: Oriol Brufau <[email protected]>
Cr-Commit-Position: refs/heads/main@{#974783}

--

wpt-commits: 727e9fba27829221cda0e4691b0610940f4a0fbc
wpt-pr: 32967
@emilio emilio mentioned this issue Apr 11, 2022
Closed
mjfroman pushed a commit to mjfroman/moz-libwebrtc-third-party that referenced this issue Oct 14, 2022
@Loirooriol @copybara-github
[inert] Force 'pointer-events: none' on inert nodes at used-value time
87072d8 
The CSSWG resolved that inert nodes should behave as if they had
'pointer-events: none', but without changing the computed style.
w3c/csswg-drafts#6685 (comment)

This is done by adding a public ComputedStyle::UsedPointerEvents() that
returns EPointerEvents::kNone for inert, and privatizing the existing
ComputedStyle::PointerEvents() just for friend classes.

Note that computed_style_fields.py needs to be tweaked, otherwise the
automatically generated PropagateIndependentInheritedProperties() would
still try to call ResetPointerEventsIsInherited(), which is no longer
defined. Now it needs to be ResetPointerEventsIsInheritedInternal().

After this change, it will be possible to remove the hit-testing
retargeting for inert.

Bug: 692360

TEST=external/wpt/html/semantics/interactive-elements/the-dialog-element/dialog-inert.tentative.html
TEST=external/wpt/inert/inert-computed-style.html

Change-Id: I720908d3e1c47d7cd13b9fe9e1110e44ff70f56b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3281968
Reviewed-by: Anders Hartvoll Ruud <[email protected]>
Reviewed-by: Rune Lillesveen <[email protected]>
Commit-Queue: Oriol Brufau <[email protected]>
Cr-Commit-Position: refs/heads/main@{#942180}
NOKEYCHECK=True
GitOrigin-RevId: 6aadd45a00e1d6512dd17c3a2d31f5d89647c97e
mjfroman pushed a commit to mjfroman/moz-libwebrtc-third-party that referenced this issue Oct 14, 2022
@Loirooriol @copybara-github
[inert] Remove hit test retargeting for inert
440e5c9 
r942180 made inert nodes behave as 'pointer-events: none', as resolved
by the CSSWG in w3c/csswg-drafts#6685

Then, the magic hit test retargeting for inert is no longer needed.

Bug: 692360
Change-Id: I950f0967f093d6acb20877e049fb1bcf75a88de1
Cq-Do-Not-Cancel-Tryjobs: true
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3257651
Commit-Queue: Oriol Brufau <[email protected]>
Reviewed-by: Koji Ishii <[email protected]>
Reviewed-by: Nektarios Paisios <[email protected]>
Cr-Commit-Position: refs/heads/main@{#942823}
NOKEYCHECK=True
GitOrigin-RevId: e2b9c07caf767a295026023ba5813ca339024a76
mjfroman pushed a commit to mjfroman/moz-libwebrtc-third-party that referenced this issue Oct 14, 2022
@Loirooriol @copybara-github
[inert] Force 'user-select: none' on inert nodes at used-value time
e854b79 
The CSSWG resolved that inert nodes should behave as if they had
'user-select: none', but without changing the computed style.
w3c/csswg-drafts#6685 (comment)

This is done by adding a public ComputedStyle::UsedUserSelect() that
returns EUserSelect::kNone for inert, and privatizing the existing
ComputedStyle::UserSelect() just for friend classes.

This doesn't seem to have much impact to editing since IsSelectable()
was already checking IsInert().

But now accessibility will set kNotUserSelectableStyle=true when inert.

Bug: 692360

TEST=All/DumpAccessibilityTreeTestWithIgnoredNodes.InertAttribute/blink

AX-Relnotes: Inert nodes will be considered non-selectable.
Change-Id: Iffc15fb90976234768721a6e006de9b6defeee55
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3460673
Reviewed-by: Aaron Leventhal <[email protected]>
Reviewed-by: Rune Lillesveen <[email protected]>
Commit-Queue: Oriol Brufau <[email protected]>
Cr-Commit-Position: refs/heads/main@{#971185}
NOKEYCHECK=True
GitOrigin-RevId: f1944a2f4cd881ac3b985059e440ecb5384735eb
mjfroman pushed a commit to mjfroman/moz-libwebrtc-third-party that referenced this issue Oct 14, 2022
@Loirooriol @copybara-github
[inert] Force 'user-modify: none' on inert nodes at used-value time
e286b60 
This is done by adding a public ComputedStyle::UsedUserModify() that
returns EUserModify::kNone for inert, and privatizing the existing
ComputedStyle::UserModify() just for friend classes.

Code related to the style resolver, style adjuster, inheritance, etc.
continues using UserModify(), since inert should only change used styles
w3c/csswg-drafts#6685 (comment)

Forcing 'user-modify: none' wasn't explicitly resolved by the CSSWG, but
it solves the inconsistency of editing commands having different
behaviors when executed in a node which is both in inert and editable
subtrees, depending on whether the inert root is a descendant of the
editing root, or an inclusive ancestor.

Forcing 'user-modify: none' is also consistent with Firefox, though it
doesn't have much effect there, it doesn't avoid editability.

Bug: 692360

TEST=external/wpt/inert/inert-and-contenteditable.tentative.html

Change-Id: I4a34b9715272019b0b8daae0fd5ed3e25e38eddf
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3486876
Reviewed-by: Rune Lillesveen <[email protected]>
Commit-Queue: Oriol Brufau <[email protected]>
Cr-Commit-Position: refs/heads/main@{#974783}
NOKEYCHECK=True
GitOrigin-RevId: ad88e5d90ce91ba9ebd96278770259689e908b05
@css-meeting-bot css-meeting-bot mentioned this issue Mar 22, 2023
Closed
@flackr
Copy link
Contributor

flackr commented Jun 16, 2023

I prefer something like chrome's previous behavior where the inert node is still hit but perhaps dispatches events to the non-inert ancestor. Using pointer-events: none means that the user may interact with content that is being obscured which feels like it could lead to accidental interactions.

@flackr flackr mentioned this issue Jun 16, 2023
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
css-ui-4 Current Work
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
9 participants
@smfr @frivoal @flackr @fantasai @annevk @nt1m @atanassov @bradkemper @css-meeting-bot