The function used to parse the variables.css file and do some regex matching
on the light/dark theme rules to extract the declaration value of a variable.
This patch makes the function simpler by getting the computed value of the
CSS variable, which automatically adapt to the current theme since we do set
`color-scheme` value properly when setting a theme.
In order for this to work properly, the variables that might be used in this
function need to be registered so the engine know they are colors.
We take this as an opportunity to rename the function to `getCssVariableColor`,
which is more explicit, and also make it take the actual CSS variable name,
and not only the suffix part that comes after `--theme-` for better grep-ability.
The test in browser_theme.js is adapted to reflect those changes.
Differential Revision: https://phabricator.services.mozilla.com/D220718
The computed panel was already read only, but this was done
by checking the swatch class name directly in the output parser,
which is not ideal.
Here we have a proper setting, that we can use in the computed panel,
as well as in the variable tooltip, where we can't interact with
the swatches.
The pointer cursor is only added onto swatches that are a button
or have a button role.
Tests are updated accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D220819
We used to show the checker but this regressed at some point.
A stacking context is needed to put the pseudo element which
contains the checker below the swatch, so we create it on
the swatch container.
We take this as an opportunity to cleanup the swatch rules,
using CSS variables to control swatch and background sizes.
This allows us to share the same classes for the computed panel
swatches, which only need a different size.
Differential Revision: https://phabricator.services.mozilla.com/D220525
This changes the `--x = red` tooltip content into just `red`.
We still keep the `--x is not set` as I'm unsure what the alternative could be
(and given it would probably still need localized string, as we can use `unset`,
which is an actual valid value)
Tests are updated to include the new tooltip content.
devtools/client/inspector/rules/test/browser_rules_preview-tooltips-sizes.js is
further tweaked to cover a frequent intermittent.
Differential Revision: https://phabricator.services.mozilla.com/D219138
A method is added to the source editor to handle syntax highlighting so we can
handle both cm5 and cm6.
As the rules for syntax highlighting in CodeMirror 6 were all defined in the `cm-editor`
class, we have to add a specific class that we can target for the previews,
and handle it in the light and dark CSS files.
Differential Revision: https://phabricator.services.mozilla.com/D219175
Using the computed value makes it possible to easily
show the color swatch where we previously couldn't,
mostly when a variable was based of other variables.
Test cases are added to assert the new behavior.
Differential Revision: https://phabricator.services.mozilla.com/D218728
For the computation of options.supportsColor, we were checking
if the variable declaration value was a valid color. This is
working well for simple case, but not when the declaration is
using other variables.
Switching to the computed value fixes this case.
The output parser test for variables is modified so we can
check all the test cases for a css variable declaration (we only
use to test for a color declaration).
A couple test cases are skipped because they're not supported yet.
Bugs have been filed and reference added in comments.
Depends on D218519
Differential Revision: https://phabricator.services.mozilla.com/D218727
The #createNode function wasn't adding attribute if they
were empty, meaning that the data-variable-computed attribute
wouldn't be set for empty computed value (which are stil valid).
Note that this doesn't look great in the tooltip at the moment,
we may display empty values differently in Bug 1912267.
Differential Revision: https://phabricator.services.mozilla.com/D218849
To be able to target the specific inplace editor input,
we add a new inputClass option to InplaceEditor that can
be used to add an additional class to the input.
Differential Revision: https://phabricator.services.mozilla.com/D216783
Update inplace editor "target" (tagname, attribute, …) focus style so it stands
out much more from the other items in the selected node line.
Since this wouldn't be easy/possible to do with the line "parts" colors set in
the themes stylesheet via theme-fg-color* classes, we remove those, add specific
classes when needed, and set the colors in markup.css.
When an inplace editor input is displayed, remove the "selected" style (blue background, white color)
from the line, so it's easier to understand we're in a different state.
Differential Revision: https://phabricator.services.mozilla.com/D216521
This patch adds a new `isDarkColorScheme` option to the OutputParser.
When passed, this will parse `light-dark` function to add an "unmatched" CSS
class to the param that isn't used: the first one when `isDarkColorsScheme` is
false, the second one when `isDarkColorScheme` is true.
Test cases are added in browser_outputparser.js to cover this.
Differential Revision: https://phabricator.services.mozilla.com/D217833
This patch introduce a new #stack property on the parser, which hold the parenthesis
stack so we can handle nested functions.
We switch the existing `colorFunctions` array to this new stack as it's doing
something similar, but a bit more generic.
When there's at least an entry in the stack, we want to put the parsed parts,
text or nodes, into the `parts` stack entry property so it can be used later
when we handle the function being closed.
This parts get put into the "parent" stack entry, or into the main #parsed array
when the stack becomes empty.
We could go further, migrating `parseMatchingParens`/`parseVariable` to use the
stack and the `onCloseParenthesis` method. This might be done as part of Bug 1630950,
where we want to handle nested css variables.
Differential Revision: https://phabricator.services.mozilla.com/D218218
With Bug 1909594, decorationLines items are expected to be an object.
We missed one callsite when marker.shouldMarkAllLines is true.
Differential Revision: https://phabricator.services.mozilla.com/D217784
The item to focus after hiding the popup was picked from the tooltip document,
but picking it in the anchor document sounds more appropriate.
Also avoid to re-set the focus if the tooltip document doesn't have the focus
anymore before hiding the console (e.g. the user clicked on something outside
of DevTools)
This allows to properly focus the event badge back when hiding the event listener
tooltip with the keyboard. We tweak the event badge focus style a bit to make
this more obvious.
Differential Revision: https://phabricator.services.mozilla.com/D216909
`MouseEvent.pointerId` is `undefined` so that `setPointerCapture(undefined)`
means `setPointerCapture(0)` and it captures both click of mouse and first
touch of touch input devices. It needs to listen to `pointerdown` event to
get the correct `pointerId` value. Then, it can use only `pointerdown` and
`pointerup` because they are fired before `mousedown` and `mouseup`.
Additionally, it handles a drag while a mouse button is pressed. Therefore,
it can ignore pointer events which are caused by other devices.
Although it's not required explicitly to release the capture when the pointer
is up, it needs to release capturing the pointer if `Escape` is pressed.
Therefore, this patch keeps the explicit release call.
Depends on D217216
Differential Revision: https://phabricator.services.mozilla.com/D217217
`MouseEvent.pointerId` is `undefined` so that `setPointerCapture(undefined)`
means `setPointerCapture(0)` and it captures both click of mouse and first
touch of touch input devices. Therefore, for getting correct `pointerId`,
it needs to listen to `pointerdown`. Then, we make it listen to `pointerdown`
and `pointerup` events because `mousedown` and `mouseup` are always fired after
`pointerdown` and `pointerup` (`mousemove` and `pointermove` are really
different, therefore, it needs to keep listening to `mousemove`). Finally,
they are handling a drag during a button press. Therefore, they are designed
only for mouse devices. Therefore, this patch makes the `pointerdown` listener
start to handle a drag only when the device type is "mouse".
Note that the pointer capture will be released when all pointers of the device
are inactivated. Therefore, it does not need explicitly to release the capture.
Depends on D217215
Differential Revision: https://phabricator.services.mozilla.com/D217216
This patch adds support for running debugger DAMP tests with CM6.
Currently switch off by default. Set the `devtools.debugger.features.codemirror-next` pref in
the custom.js to `true` to run.
Differential Revision: https://phabricator.services.mozilla.com/D210909
Nicolas Chevobbe