Open Bug 1576980 Opened 4 months ago Updated Last month

[meta] DevTools support for high contrast mode


(DevTools :: CSS and Themes, enhancement)

Not set


(Not tracked)


(Reporter: jdescottes, Unassigned)


(Depends on 4 open bugs)


(Keywords: meta)

Meta bug to track the feature work needed to support high contrast mode in DevTools.

Currently DevTools does not support High Contrast mode. Before Bug 1539979, high contrast mode were simply not applied to the toolbox, because the devtools toolbox was loaded in a frame with type=chrome, which means it always kept the authored colors.

Now that DevTools are loaded in a frame with type=content, High Contrast mode colors are applied to the Toolbox, but since the stylesheets of DevTools were not designed with High Contrast support in mind, the end-result is not great yet.

We are currently working on adding an exception so that DevTools are preserved from High Contrast mode once again (bug 1575766).

After that we should add a preference that will allow to toggle the exception, so that we can work on high contrast mode for DevTools (see , bug not filed yet).

Finally we should review the DevTools panels in high contrast mode and fix our stylesheets so that the experience is good in High Contrast mode.

Note that high contrast mode will be improved with Bug 1575689, which should add support for rendering images in high contrast mode.

Thank you for the bug! CCing Florens as they've had some thoughts on this.

I don't know anything about high contrast mode from a platform perspective (the bugs Julian referenced).

But theoretically, if we wanted to implement a high contrast mode in CSS only, we could do it by setting all our --theme-* color variables. This could cover a lot of ground. Then we would have to go over a bunch of panels and components which use their own custom colors instead of --theme-* variables to do a bit of CSS refactoring.

On this page I prototyped a CSS-only high contrast theme, you can try it out by selecting "Color theme > High contrast" on the page:

How many high contrast styles would we need? Just one (e.g. white on black)? A dark one and a light one? Or do we need to match the styles used by the several macOS and Windows high contrast modes?

It seems like there are two different topics:

  • how DevTools should behave when the OS enables a High Contrast color scheme
  • create High Contrast DevTools themes for users who just want high contrast in the tools

How many high contrast styles would we need? Just one (e.g. white on black)? A dark one and a light one? Or do we need to match the styles used by the several macOS and Windows high contrast modes?

When the system enables High Contrast mode, technically DevTools should not be able to use authored colors. I am working on a temporary workaround in bug 1575766 to give us time to adapt our stylesheets to High Contrast mode. But I doubt we'll be allowed to keep the workaround forever (or we'd need to have a strong argument).

So for OS High Contrast modes the colors will be imposed by the OS. Maybe we need to create a special theme that is only used when we are in OS High Contrast mode, or we can just make all our themes work well when High Contrast mode is enabled.

So we need to identify which patterns in our styles don't work well in OS high contrast mode.

I don't know much, but I think buttons without borders are an issue. Even if our normal style is "flat" and doesn't have a border, we probably should have border: 1px solid transparent; so that the high contrast mode would override the transparent color and use a contrasted border instead.
Same issue for splitters which sometimes use a background-color to draw their 1px "border" instead of a CSS border (at least in Debugger).

Probably other patterns I'm not aware of.

You can easily test the impact of High Contrast mode in DevTools by following the STRs at

Now that Bug 1575766 has landed, make sure to set devtools.toolbox.force-chrome-prefs to false if you want to test the impact of High Contrast mode on DevTools.

Depends on: 1590215
You need to log in before you can comment on or make changes to this bug.