Use --theme-selection-color instead of white.
Don't lower opacity on frames and use dedicated variable instead.
Tweak some selectors to make sure the panel looks good in all situations.
Differential Revision: https://phabricator.services.mozilla.com/D228841
This allows the state of the button to be announced to screen readers,
as well as make it follow the styling we have for such buttons.
We can now rely on the state of the attribute to change the icon.
Differential Revision: https://phabricator.services.mozilla.com/D227940
The pressed style was reusing --toolbarbutton-hover-background, instead of using the more
semantically appropriate --toolbarbutton-checked-background.
The latter was having a very distinct style (blue background), which didn't match the
style we wanted. But, I don't think the style as used anywhere and seemed more like
a relic of a previous design, so I updated the variable to mimic what we currently
have in regular themes, and adapted the colors for High Contrast.
This way we can extract some selectors into their own rules so we have a more fine-grained
way to style those.
We take this as an opportunity to remove the --toolbarbutton-focus* variables and
the declarations using them as we now have proper focus indicator on the buttons.
Differential Revision: https://phabricator.services.mozilla.com/D227840
No element with the `devtools-toolbarbutton` class can have a label or a checked attribute,
or can have `.toolbarbutton-text` items, so we can remove some selectors and rules from the stylesheet.
We take this as an opportunity to refactor the stylesheet with CSS nesting.
Depends on D221945
Differential Revision: https://phabricator.services.mozilla.com/D227838
This only tweaks the colors of the tabs for the different states (hover, selected, reordering),
to make it consistent with the changes made in the previous commit.
Differential Revision: https://phabricator.services.mozilla.com/D221945
In HCM, we change the background color when it's selected, whereas in regular mode,
we only change the text color (and add a thin line on top).
On hover, in HCM we want to change the text color, and in regular mode only the
background color.
To handle those more easily, we introduce new variables so that we can easily
define them for HCM too.
Differential Revision: https://phabricator.services.mozilla.com/D228638
I had big issues with this patch as it was causing random crashes
when run with MOZ_PROFILER_STARTUP=1 and breaking browser_xpcom_graph_wait.js
which does the same.
I tried to get around that by avoiding the IOInterposer registration
in CacheIOThread, but that was also problematic.
Eventually it seems there's no longer a good reason to keep calling
PR_CreateThread manually instead of NS_NewNamedThread, so I switched
to that and all of the previous issues are gone.
The stack is now twice as big, but hopefully that's not a major issue.
All other behaviour should stay the same.
Differential Revision: https://phabricator.services.mozilla.com/D132381
The initial check for nb == 0 should not be needed now that we test that the expected number of elements are displayed. The initial version of the patch was only using `some` and there it made sense to special case nb == 0, but we ended up improving this before landing.
Differential Revision: https://phabricator.services.mozilla.com/D228660
Firefox UI don't have such transition, and they need to not be applied
in High Contrast Mode/reduced motion, so we can remove them all together.
Differential Revision: https://phabricator.services.mozilla.com/D228464
The components weren't used anywhere. We can also remove selectors and rules that were targetting
classes only used in this file.
Differential Revision: https://phabricator.services.mozilla.com/D227837
Adapt the color of the text and arrow, especially on hover.
This covers accordion in the rules view, the layout panel and the debugger.
Differential Revision: https://phabricator.services.mozilla.com/D228149
This adds a new variable with the same colors than the variable one that we can use as a drop-in replacement.
For some cases, we could reuse the existing --theme-body-emphasized-background.
The Debugger ResultList style could be simplified as it should always have either 'small' or 'big' class, which
were both setting a background color for selected item, overriding the declaration that was using --theme-accordion-header-background.
Differential Revision: https://phabricator.services.mozilla.com/D228148
Because the tracer actor runs in the content process, the preference toggling logic
has to be done in some code running in the parent process: TargetConfiguration.
Differential Revision: https://phabricator.services.mozilla.com/D227833
Stop manually crafting the profiler data by using SpiderMonkey hooks.
Instead, use the profiler native pipeline to do the collection.
This still relies on JSTracer class in order to trigger the record on next interaction or page load.
One caveat is that it starts the profiler from the content process, which prevents recording screenshots correctly.
Differential Revision: https://phabricator.services.mozilla.com/D227831
The test was failing accessibility check because we're clicking
on the tag line. Since we're handling element selection just fine
with the keyboard, we don't need to have the line being a proper
target, so we can disable the check.
Differential Revision: https://phabricator.services.mozilla.com/D227923
The components weren't used anywhere. We can also remove selectors and rules that were targetting
classes only used in this file.
Differential Revision: https://phabricator.services.mozilla.com/D227837
