Expanded computed view shows erroneous information with @layer
Categories
(DevTools :: Inspector, defect, P2)
Tracking
(firefox117 verified, firefox118 verified)
People
(Reporter: nchevobbe, Assigned: nchevobbe)
References
Details
Attachments
(2 files)
Steps to reproduce
- Navigate to
data:text/html,<meta charset=utf8><style>@layer A, B;body {color: red;}@layer A {body {color: green ;}}@layer B {body {color: blue ;}}</style>Hello
- Open the inspector, navigate to the computed view
- Expand the
color
item
Expected results
The red
property is the one that is active
Actual results
The blue
property is the one that is active
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 1•2 years ago
|
||
The algorithm we use to sort rules in the server (devtools/server/actors/inspector/css-logic.js#1511-1566 ) is based on https://www.w3.org/TR/css-cascade-4/#cascading which doesn't cover layers. We should follow https://www.w3.org/TR/css-cascade-5/#cascading instead
Comment 2•2 years ago
|
||
We should try to address this one before Bug 1824652, it might indirectly help.
Assignee | ||
Comment 3•2 years ago
|
||
In order to fix this, we need to be able to compare the cascade layers of 2 CSSRules
The only thing we can do natively is gather the list of ancestor CSSLayerBlockRule
for a given rule, but that does not give us the cascade layers order of the overall page, and given that those layers can be nested, which does impact how rules compare order (see https://www.w3.org/TR/css-cascade-5/#layer-names) , I don't think we can do this on our own.
Emilio, does the engine keep the layers tree somehow, and could it be exposed (e.g. in InspectorUtils
) so we could use it here ?
Zooming back a bit, it looks like in https://searchfox.org/mozilla-central/rev/82828dba9e290914eddd294a0871533875b3a0b5/devtools/server/actors/inspector/css-logic.js#1511-1566 we're re-doing a lot of the work the engine does to know which property value should be applied to an element, and I wonder if there's an opportunity for us to re-use that in an easier way
Comment 4•2 years ago
|
||
So... we keep a flattened list of layers here and here, but we don't keep that order in the OM so it's not particularly trivial to expose...
How are you getting the style rules? Presumably getCSSStyleRules
? We should generally return them properly sorted. The only differences there would be importance and style attribute / animation rules which we skip:
We could trivially return the importance as well if that'd make your life easier? You probably also want a marker of sorts for the style attribute (since !important
and some other things can override it).
Assignee | ||
Comment 5•2 years ago
|
||
Given that we get the rules from InspectorUtils.getCSSStyleRules
, the selectors
are already sorted the way the platform handles them.
We only need to reorder those in case a value is important, otherwise we rely
on the original rules order.
Extensive tests are added to make sure we covered possible cases.
Updated•2 years ago
|
Updated•2 years ago
|
Comment 7•2 years ago
|
||
Backed out for causing dt failures in devtools/client/debugger/test/mochitest/browser_dbg-preview-frame.js
Backout link: https://hg.mozilla.org/integration/autoland/rev/d696dbcd9f176118f53da139bc1f4a2cb7c8bb37
Assignee | ||
Comment 8•2 years ago
|
||
ah, some unwanted changes sneaked in the commit, I'll fix this
Comment 10•2 years ago
|
||
bugherder |
Updated•2 years ago
|
Reproducible on a 2023-07-11 Nightly build on macOS 12.
Verified as fixed on Firefox 117.0b2(build ID: 20230801180159) and Nightly 118.0a1(build ID: 20230802220030) on macOS 12, Windows 10, Ubuntu 22.
Description
•