New wpt failures in /css/selectors/focus-visible-007.html
Categories
(Core :: CSS Parsing and Computation, defect)
Tracking
()
People
(Reporter: wpt-sync, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [wpt])
Syncing wpt PR 27156 found new untriaged test failures in CI
Tests Affected
New Tests That Don't Pass
/css/selectors/focus-visible-007.html
Using keyboard while element is focused should trigger :focus-visible; using mouse without moving focus should not cancel it; moving focus using mouse should cancel it.: FAIL (Chrome: PASS, Safari: FAIL)
CI Results
Gecko CI (Treeherder)
GitHub PR Head
Notes
These updates will be on mozilla-central once bug 1686543 lands.
Note: this bug is for tracking fixing the issues and is not
owned by the wpt sync bot.
This bug is linked to the relevant tests by an annotation in
https://github.com/web-platform-tests/wpt-metadata. These annotations
can be edited using the wpt interop dashboard
https://jgraham.github.io/wptdash/
If this bug is split into multiple bugs, please also update the
annotations, otherwise we are unable to track which wpt issues are
already triaged. Resolving as duplicate or closing this issue should
be cause the bot to automatically update or remove the annotation.
|
||
Comment 1•4 years ago
|
||
This test was wrong but it has been fixed now.
Still it fails in Firefox because when it sends the SHIFT key, that doesn't change anything regarding :focus-visible matching in Firefox, however that makes the element match :focus-visible in Chromium.
This follows this part of the spec:
- If the user interacts with the page via the keyboard, the currently focused element should match '':focus-visible'' (i.e. keyboard usage may change whether this pseudo-class matches even if it doesn't affect '':focus'').
|
||
Comment 2•4 years ago
|
||
It's unclear to me whether this test is entirely valid/correct, for a couple of reasons:
(1) The spec text quoted in comment 1 is one of the points listed under "User agents can choose their own heuristics for when to match :focus-visible; however, the following (non-normative) suggestions can be used as a starting point". As such, it is explicitly not a normative requirement but just a suggestion.
(2) It's not clear to me whether pressing the Shift key should be considered as "interact[ing] with the page". A clearer "interaction" would be, for example, using an arrow key to move the caret within an editable element, after having placed the caret (and focused the element) via a mouse action. But merely pressing or releasing a modifier key such as Shift does not (usually) amount to an "interaction" with the page at all.
|
|
||
Comment 3•4 years ago
|
||
Adding Alice on CC as I believe she was the original author of this test, at least I reviewed my recent changes on it.
(In reply to Jonathan Kew (:jfkthame) from comment #2)
It's unclear to me whether this test is entirely valid/correct, for a couple of reasons:
(1) The spec text quoted in comment 1 is one of the points listed under "User agents can choose their own heuristics for when to match :focus-visible; however, the following (non-normative) suggestions can be used as a starting point". As such, it is explicitly not a normative requirement but just a suggestion.
All the :focus-visible spec is full of suggestions, and the tests check those suggestions. It's true that user agents can do whatever they want regarding them.
Anyway regarding WPT tests, as the spec text says "should" it looks like having regular tests is the way to go (https://web-platform-tests.org/writing-tests/file-names.html#test-features):
.optional : Indicates that a test makes assertions about optional behavior in a specification, typically marked by the RFC 2119 “MAY” or “OPTIONAL” keywords. This flag should not be used for “SHOULD”; such requirements can be tested with regular tests, like “MUST”.
Thought maybe we have to add "should" meta flag (https://web-platform-tests.org/writing-tests/css-metadata.html#requirement-flags).
(2) It's not clear to me whether pressing the Shift key should be considered as "interact[ing] with the page". A clearer "interaction" would be, for example, using an arrow key to move the caret within an editable element, after having placed the caret (and focused the element) via a mouse action. But merely pressing or releasing a modifier key such as Shift does not (usually) amount to an "interaction" with the page at all.
An editable element will always match :focus-visible when it's focused, so it's not an option. Maybe we could use other keys like ENTER or SPACE, or a regular letter on this test, instead of a modifier key like SHIFT, to make things clearer. WDYT?
|
|
||
Comment 4•4 years ago
|
||
(In reply to Manuel Rego Casasnovas from comment #3)
All the :focus-visible spec is full of suggestions, and the tests check those suggestions. It's true that user agents can do whatever they want regarding them.
Anyway regarding WPT tests, as the spec text says "should" it looks like having regular tests is the way to go (https://web-platform-tests.org/writing-tests/file-names.html#test-features):.optional : Indicates that a test makes assertions about optional behavior in a specification, typically marked by the RFC 2119 “MAY” or “OPTIONAL” keywords. This flag should not be used for “SHOULD”; such requirements can be tested with regular tests, like “MUST”.
That's an interesting question, actually. I would have assumed this text about .optional is referring to terminology like SHOULD or MUST when these occur in normative spec text. But here in :focus-visible, the entire list of "heuristics for when to match" is explicitly called out as being "(non-normative) suggestions", at which point it's not clear to me that the word "should" has any meaning beyond its everyday English sense.
Note that https://drafts.csswg.org/selectors-4/#w3c-conventions refers us to RFC 2119 for the meaning of terms like SHOULD "in the normative parts of this document". But these heuristics are not in a normative part of the document at all, so that doesn't apply here.
As such, I'm still not convinced there is spec support for testing this behavior in this way.
|
|
||
Comment 5•4 years ago
|
||
(In reply to Manuel Rego Casasnovas from comment #3)
An editable element will always match :focus-visible when it's focused, so it's not an option. Maybe we could use other keys like ENTER or SPACE, or a regular letter on this test, instead of a modifier key like SHIFT, to make things clearer. WDYT?
Yes, to test "interacts with the page via the keyboard" I think a character key (or caret-movement key) would be a better choice. In most cases, a modifier key by itself does not interact with anything; it only has meaning in combination with a character key that it can modify.
|
|
||
Comment 6•4 years ago
|
||
Sent a PR to WPT to use ENTER instead of SHIFT in this test: https://github.com/web-platform-tests/wpt/pull/27656
|
|
||
Updated•4 years ago
|
Description
•