Inherited properties from ::details-content pseudo element are not displayed in the Rules view
Categories
(DevTools :: Inspector: Rules, defect, P3)
Tracking
(firefox139 fixed)
| Tracking | Status | |
|---|---|---|
| firefox139 | --- | fixed |
People
(Reporter: nchevobbe, Assigned: nchevobbe)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
- Set
layout.css.details-content.enabledtotrue - Navigate to
data:text/html,<meta charset=utf8><style>details::details-content {color: tomato;}</style><details open><summary>Example summary</summary><p>First paragraph.</p><p>Second paragraph</p></details> - Open the inspector
- Select one of the
pelement inside the<details>node
-> make sure that we can see that the paragraph inherits its tomato color from the ::details-content pseudo
|
Assignee | |
Comment 1•7 months ago
|
||
This does make the inherited rule appear:
diff --git a/devtools/server/actors/page-style.js b/devtools/server/actors/page-style.js
--- a/devtools/server/actors/page-style.js
+++ b/devtools/server/actors/page-style.js
@@ -704,7 +704,7 @@ class PageStyleActor extends Actor {
);
// Now any pseudos.
- if (showElementStyles && !options.skipPseudo) {
+ if (!options.skipPseudo) {
const relevantPseudoElements = [];
for (const readPseudo of PSEUDO_ELEMENTS) {
if (!this._pseudoIsRelevant(bindingElement, readPseudo)) {
@@ -806,7 +806,7 @@ class PageStyleActor extends Actor {
case "::file-selector-button":
return node.nodeName == "INPUT" && node.type == "file";
case "::details-content":
- return node.nodeName == "DETAILS";
+ return !!node.closest("details");
case "::placeholder":
case "::-moz-placeholder":
return this._nodeIsTextfieldLike(node);
But it appears at the very top of the rules view, as if the pseudo element was on the p element.
It also doesn't seem to be taken into account for the "overridden" properties (e.g. if there's a color declaration on details, it won't be stroke through, even if it's not applied), and it also doesn't appear in the computed panel.
So I guess we need to have something specific for pseudo elements that can have whose declarations inherits.
Note that these kind of pseudo element rules should also be taken into account for CSS variable.
E.g. on data:text/html,<meta charset=utf8><!DOCTYPE html><style>details{ color: gold;}details[open]::details-content {--x: tomato; color: dodgerblue;padding: 0.5em;border: thin solid grey;} p { outline: 1px solid var(--x);} </style><details open><summary>Example summary</summary><p>First</p><p>Second</p></details> , var(--x) is properly computed to tomato (we have a redish outline on the paragraph), and so hovering --x should show in the tooltip tomato.
|
||
Updated•7 months ago
|
|
|
Assignee | |
Comment 2•7 months ago
|
||
Luke suggested that we could use the same setup as what we have for ::part(), as we do actually handle this properly for them.
InspectorUtils.getMatchingCSSRules(node) will return (inherited or not) ::part() rules, even though the pseudo parameter isn't passed.
We should probably align what we do so ::part and ::details-content (and any other pseudo element from which "child" elements might inherit) would work the same.
Emilio, there doesn't seem to be any test for DevTools + ::part(), so I wonder if this is intentional or if it just happens to work by mistake ?
|
||
Comment 3•7 months ago
|
||
But I'm confused, getMatchingCSSRules doesn't return inherited declarations, does it? If you pass node = the-slot, and pseudo = null, it should also return the ::details-content rules.
|
|
Assignee | |
Comment 4•7 months ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #3)
But I'm confused,
getMatchingCSSRulesdoesn't return inherited declarations, does it? If you passnode = the-slot, andpseudo = null, it should also return the::details-contentrules.
When you say the-slot, I guess this doesn't refer to the <details> element (because getMatchingCSSRules(detailEl) won't return the ::details-content rules (you actively need to pass the pseudo param to get them).
The differentce with ::part() may also comes from the fact that Inspector.getCSSPseudoElementNames() doesn't return ::part (again, not sure if it's wanted or not)
|
|
||
Comment 5•7 months ago
|
||
Right, when I say the-slot, I mean the slot element which is I'm detail's shadow tree (and matches this pseudo)
|
|
Assignee | |
Comment 6•6 months ago
|
||
This required a few changes both on the server and the client.
For such element-backed pseudo element rules, they need to be considered "closer"
to the selected element than the rules on the <details> element.
This means we also need to display those rules in their own dedicated "Inherited from"
section to make sure overridden declarations are properly marked as such.
A test is added to cover the different cases we have to handle.
|
||
Updated•6 months ago
|
|
||
Comment 8•6 months ago
|
||
| bugherder | ||
|
||
Updated•5 months ago
|
Description
•