This adds the pasring support for:
1. `::view-transition`
2. `::view-transition-group(name)`
3. `::view-transition-image-pair(name)`
4. `::view-transition-old(name)`
5. `::view-transition-new(name)`
The `name` here is a `<custom-ident>` or `*`.
Differential Revision: https://phabricator.services.mozilla.com/D219713
We define the tick colors in CSS, using relative color syntax to
add the alpha we want.
We set the highlighter-* variables as registered properties so
the computed value will be the end color, even if we use
the light-dark function.
Differential Revision: https://phabricator.services.mozilla.com/D220706
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
The paused frame will still be considered as selected from the point of view of stepping buttons, and shown with a grey background,
but will no longer be highlighted with a blue background.
Differential Revision: https://phabricator.services.mozilla.com/D219779
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
The variable is being used in inspector-swatches.css,
so it should be set in a shared stylesheet too.
The highlight of shape points on hover was broken,
so I took the opportunity to fix it here.
Differential Revision: https://phabricator.services.mozilla.com/D220513
gNotificationBox doesn't go there anymore (it goes inside the toolbox),
so we have really no use for that.
Simplify how the devtools theme is set on the browser, so that it is set
on the root.
Differential Revision: https://phabricator.services.mozilla.com/D220769
The paused frame will still be considered as selected from the point of view of stepping buttons, and shown with a grey background,
but will no longer be highlighted with a blue background.
Differential Revision: https://phabricator.services.mozilla.com/D219779
This will help make browser_rules_edit-size-property-dragging.js more robust and
will help to land the changes from Bug 1885232.
The order of assertions in browser_rules_edit-size-property-dragging.js is modified
to circumvent Bug 1913358.
Differential Revision: https://phabricator.services.mozilla.com/D218921
This cache might keep destroyed windowUtils helpers in some scenarios involving navigations with a process change.
The regular getter is slightly slower, but the performance hit should not be noticeable.
Differential Revision: https://phabricator.services.mozilla.com/D220785
dquote>
dquote> The default dark-mode tooltip background is lighter than
dquote> the tooltip, which was causing some low contrast issues.
dquote> A solution might have been to define specific colors that
dquote> would work against such background, but this would be complex,
dquote> and brittle IMO.
dquote> The simpler solution is to make the tooltip background the
dquote> same as the rules view background, where we know our colors
dquote> have enough contrast, and introducing new ones have a higher
dquote> chance of having good contrast as it is upfront, in comparison
dquote> to the tooltip that you have to trigger.
Differential Revision: https://phabricator.services.mozilla.com/D220567
Alexandre Poirot