Firefox Developer Experience

,

Firefox DevTools Newsletter — 131

Posted by

Nicolas Chevobbe

–

Developer Tools help developers write and debug websites on Firefox. This newsletter gives an overview of the work we’ve done as part of the Firefox 131 Nightly release cycle.

Firefox being an open source project, we are grateful to get contributions from people outside of Mozilla:

Want to help? DevTools are written in HTML, CSS and JS so any web developer can contribute! Read how to setup the work environment and check the list of mentored issues

Supercharging CSS variables debugging

CSS variables, or CSS custom properties if you’re a spec reader, are fantastic for creating easy reusable values through your pages. To make sure they’re as enjoyable to write in your IDE as to debug in the Inspector, all vendors added a way to quickly see the declaration value of a variable when hovering it in the rule view.

DevTools rules view with the following declaration: `height: var(--button-height)`. A tooltip point to the variable and indicates that its value is 20px

This does work nicely as long as your CSS variable does not depend on other variables. For such cases, the declaration story might not give you a good indication of what is going on.

DevTools rules view with the following declaration: `height: var(--default-toolbar-height)`. A tooltip point to the variable and indicates that its value is `var(--default-toolbar-height)`
Not really useful, what’s --default-toolbar-height value?

You’re now left with either going through the different variable declarations to try to map the intermediary values to the final one, or look in the Layout panel to check the computed value for the variable. This is not super practical and requires multiple steps, and you might already be frustrated because you’re chasing a bug for 3 hours now and you just want to go home and relax! That happened to us too many times, so we decided to show the computed value for the variable directly in the tooltip, where it’s easy for you to see (#1626234).

DevTools rules view with the following declaration: `height: var(--default-toolbar-height)`. A tooltip point to the variable and indicates that its value is `var(--default-toolbar-height)`. It also show a "computed value" section, into which we can read "calc(24px - 2 * 2px)"


This is even more helpful when you’re using custom registered properties, as the value expression can be properly, well, computed by the CSS engine and give you the final value.

The same declaration as previously, but the tooltip "computed value" section now indicates "20px" There's also a "@property" section with the following: ``` syntax: '<length>'; inherits: true; initial-value: 10px; ```


Since we were upgrading the variable tooltip already, we decided to make it look good too, parsing the values the way we do in the rules view already, showing color preview, striking through unused var() and light-dark() parameters, and more (#1912006) !


The variable tooltip with the following value: `var(--border-size, 1px) solid light-dark(hotpink, brown)` The 1px in `var` and `brown` in `light-dark` are struck through, indicating they're not used. The computed value section indicate that the value is `2px solid light-dark(hotpink, brown)`

What’s great with this change is that now that we have the computed value at hand, it’s easy to add color swatch next to variables relying on other variables, which we weren’t doing before (#1630950)

The following rules: ``` .btn-primary { color: var(--button-color); } :root { --button-color: light-dark(var(--primary), var(--base)); --primary: gold; --base: tomato; } ``` before `var(--button-color)`, we can see a gold color swatch, since the page is in light theme.

Even better, this allows us to show the computed value of the variable in the autocomplete popup (#1911524)!

A value is being added for the color property. The input has the `var(--` text in it, and an autocomplete popup is displayed with 3 items: - `--base tomato` - `--button-color rgb(255, 215, 0) - `--primary gold`

While doing this work and reading the spec, I learnt that you can declare empty CSS variables which are valid.

(…) writing an empty value into a custom property, like --foo: ;, is a valid (empty) value, not the guaranteed-invalid value.

https://www.w3.org/TR/css-variables-1/#guaranteed-invalid

It wasn’t possible to add an empty CSS variable from the Rules view, so we fixed this (#1912263). And then, for such empty values, we show an <empty> string so you’re just not left with an empty space, wondering if there’s a bug in DevTools (#1912267, #1912268).

The following rule is displayed in the rules view: ``` .btn-primary { --foo: ; color: var(--foo); } ``` A tooltip points to `--foo`, and has the following text: `<empty>` The computed panel is also visible, showing `--foo`, which value is also `<empty>`

Enhanced Markup and CSS editing

One of my favorite feature in DevTools is the ability to increase or decrease values in the Rules view using the up and down arrows from the keyboard. In Firefox 131 you can now use the mouse wheel to do the same things, and like with the keyboard, holding Shift will make the increment bigger, and holding Alt (Option on OSX) will make the increment smaller (#1801545). Thanks a lot to Christian Sonne, who started this work!

Editing attributes in the markup view was far from ideal as the differences between an element attribute being focused and the initial state of attribute inputs was almost invisible, even to me. This wasn’t great, especially with all our work on focus indicator which aims to bring clarity to users, so we improved the situation by changing the style of the selected node when an attribute is being modified, which should help make editing less confusing (#1501959, #1907803, #1912209)

Firefox 130 on the left, and Firefox 131 on the right. On the top, the class attribute being focused with the keyboard, on the bottom, the class attribute being edited via an input, with its content selected. On the left, there’s almost no visible differences between the two states.

Bug fixes


In Firefox 127, we did some changes to improve performance of the markup view, including how we detect if we should show the event badge on a given element. Unfortunately we also completely broke the event badge if the page was using jQuery and Array prototype was extended, for example by including Moo.js. This is fixed in this Firefox 131 and in ESR 128 as well (#1916881)

We got a report that enabling the grid highlighter in some specific conditions would stress GPU and CPU, as we were triggering too many reflows, as we were working around platform limitation to avoid rendering issues. This limitation is now gone and we can save up cycle and avoid frying your GPU (#1909170).

Finally, we made selecting a <video> element using the node picker not play/pause said video (#1913263).

And that’s it for this months folks, Thank you for reading this and using our tools, see you in a few weeks for a new round of updates 🙂

Full list of fixed bugs in DevTools for the Firefox 131 release:

Nicolas Chevobbe

Leave a Reply

Your email address will not be published. Required fields are marked *