New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 81 users

Issue metadata

Status: Fixed
Closed: Nov 2013
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

Sign in to add a comment

Issue 318566: User Stylesheets removal breaks all DevTools themes

Reported by, Nov 13 2013

Issue description

Chrome Version       : 33.0.1707.0 (canary)
URLs (if applicable) :

What steps will reproduce the problem?
1. Open ~/Library/Application Support/Google/Chrome/Default/User StyleSheets/Custom.css
2. Add styles
3. Open browser

What is the expected result?
Custom.css is applied to the browser's default styles

What happens instead?
Nothing. Custom User Stylesheets have been removed (

Please provide any additional information below. Attach a screenshot if

There has been many blog posts, tutorials and resources created around this customization. It seems to be something developers really appreciate having available to them. If you doubt that, definitely check out how many people have +1'd Addy Osmani's Google+ post a year back. This is definitely something we're using.

Reference links:
Screen Shot 2013-10-30 at 3.05.38 AM.png
60.0 KB View Download

Comment 1 by, Nov 13 2013

This is essential for presenters and others who regularly use the devtools in their presentations

Comment 2 by, Nov 13 2013

I thought this was a transient bug until I noticed this report. Surely this is some sort of oversight, or there is at least an alternative being readied to replace this functionality? I don't want to have to rely on Stylish/Stylebot to implement CSS globally. What exactly is the benefit to removing it anyway?

Comment 3 by, Nov 14 2013

Labels: Cr-Platform-DevTools Cr-Platform-DevTools-UX
Summary: User Stylesheets removal breaks all DevTools themes (was: User Stylesheets have been removed)
We indeed have been clear in the past that these are not supported by Chrome and things may break.

Yet, unfortunately a lot of developers rely on the User Stylesheet as a means to style the devtools.
* This was just published today and blew up a fair amount on twitter:
* Devthemez has been at the center of the community here:

There are no Chrome extension APIs that allow injection of styles into the devtools webapp, and indeed using Stylish ( to inject styles to devtools fails.

An extension API does seem like the more appropriate solution instead of a User Stylesheet. Perhaps this ticket is better served as a feature request for proper extension API access for this?

As an aside, thanks to the devtools theming community including Darcy, Maurice, Wes, Simon and all for such great work!

Comment 4 by, Nov 14 2013

it seems like the main chrome theme can affect devtools as my theme now makes devtools harder to use as the tab titles lack contrast.
229 KB View Download

Comment 5 by, Nov 14 2013

Pavel, WDYT about adding an extension API for styling the dev tools?

Comment 6 by, Nov 14 2013

Status: WontFix
@eddie: that was fixed and is unrelated.

@ojan: official support for themes is an effort we are not likely to allocate resources for:
- we need to brush up our styles and make them configurable
- CSS can break devtools badly, so we can't allow arbitrary styles there

We can't enable Stylish and alike to work on DevTools scheme due to the reasons described above (for similar reasons we don't allow styling chrome:// pages such as settings).

We were sort of Ok with theming via Custom.css (every other theme breaks devtools functionality, but manually pasting things into the browser files is an Ok entry barrier for that). Adding extension styling would add an official flavor and would raise expectations on the stability front.

So I guess this will now have to wait for us to come up with an official limited styling - seems like most custom themes were around making the UI dark. Paul, do you want to open another bug for that?

Comment 7 by, Nov 14 2013

If you guys are okay with theming via custom.css, why not re-enable it in the interim until another means is available?  

A majority of devs have very specific preferences on what their coding interface looks like, probably because we spend most of our day in it.  

You've also removed an option unique to chrome devtools.  No other browser (to my knowledge) had this ability.

Comment 8 by Deleted ...@, Nov 14 2013

I have to agree with Maurice. If the concept is okay with the team but the implementation might change in the future why not re-enable the feature until the new means is ready?

Comment 9 Deleted

Comment 10 by, Nov 14 2013

What about adding such option?

Comment 11 by, Nov 15 2013

Pavel: Would there be a large support overhead to us re-enabling support for theming via Custom.css until/such a time that a more clean theming solution is possible? In the past, developers have indicated a preference to a solution that offered more than simple color selection and it seems like Custom.css solved that use-case. 

If not, perhaps we can consider putting together a proposal at some point for proper theming support such that custom styles don't break the DevTools or slow down the teams efforts to evolve the UI.

Comment 12 by, Nov 15 2013

The maintenance cost would fall on ojan's shoulders (CL in question would need to be reverted), so it is rather a question to him.

Comment 13 by, Nov 15 2013

Isn't the burden on the theme designers and users who are knowledgeable enough to install custom themes to keep their themes up-to-date? If old CSS breaks DevTools in Chrome, that's not on the Chrome team. I've seen that happen many times since I started using themes—I simply grab updated CSS from the theme developer or remove the custom CSS until an update issued. We're talking about a DevTools audience that wears big boy/girl pants—we can handle switching back and forth if there's a conflict with new DevTool layout, etc. Please open a path for themes to return in form or another.

Comment 14 by, Nov 16 2013

Thousands of people have shown interest in a customisable UI and hundreds have starred and contributed on GitHub, it's a shame this feature has gone. I do hope it returns one way or another.

Comment 15 by, Nov 19 2013

i have uesed the userstylesheets for years to make the debugger output more readable. please reimplement the feature to keep our browser as nice and useable as it was before

Comment 16 by Deleted ...@, Nov 19 2013

was a neat feature!

Comment 17 by, Nov 19 2013

I really would appreciate having a way to have at least some moderate level of configuration here. 

Is there seriously no way to change from the blinding white and minuscule font sizes?

Comment 18 by, Nov 19 2013

I agree. This was a very nice feature. The white background kills my eyes after working long hours. Having the ability to change the devtools to my liking helped me immensely.

Comment 19 by, Nov 19 2013

@peter, @RISKFact,

You can inject your favorite theme if it's hosted on Github ->

However, this is not a solution.  It's a band-aid.  And it doesn't make the theme creation workflow any easier.

Comment 20 by, Nov 22 2013

I do hope it returns too.

You're pushing really nice features like Workspaces, so developers are spending more and more time in DevTools. 
Dropping custom themes was a very bad product decision.

Comment 21 by, Nov 22 2013

I must say i allready miss the feature.

I am developing with canary morst of the time. The new Emulation feature is great. But i have to admit that i will leave chrome behind me as nearly all developers in our company will too.

It is in my eyes a neccessary feature to have customizeable developer tools.

Watching 9 Hours the day on to small fonts or a white screen, or simply it is not possible to add 

--- code ---
.console-error-level .console-message-text{
    color: red;

.console-warning-level .console-message-text {
    color: darkorange;
--- code ---

to have the console more readable. Is realy a pain.

Chrome console is going to be as bad as the XCode console in future.

Comment 22 by, Nov 22 2013

The authoring and in-browser development story has been heavily improving in Chrome over the past year. As part of this, developers have been able to author code directly inside the Sources panel, without needing to switch back and forth between Chrome and their editor.

If we're to expect developers to do this, we need to ensure this story remains compelling..

Although the DevTools team will surely continue to hammer out improved authoring features, developers are going to want to customize the editor theme. This is already possible in Sublime, Vim, WebStorm and the other editors they use.

Firefox are working on improving their DevTools theming support and I think there remains a benefit to us supporting this feature, even if it remains unofficial and comes with a small amount of maintainance cost.

I would urge us to reconsider rolling back the patch removing User Stylesheet support.

Comment 23 by, Nov 22 2013

Update: Alexander is currently exploring a solution for stylesheet injection without requiring Custom.css to be re-enabled. This may take on the form of a text input field on the Settings page.

Comment 24 by, Nov 24 2013

Please allow injection via manifest:

  "manifest_version": 2,
  "name": "Content Scripts",
  "version": "1.0",
  "permissions": [
    "http://*/*", "tabs", "https://*/*", "chrome-devtools://*/*"
  "web_accessible_resources": [
  "content_scripts": [
      "matches": ["<all_urls>"],
      "css": ["global.css"]
      "matches": ["chrome-devtools://*"],
      "css": ["chrome_devtools/style.css"]

Comment 25 by, Nov 25 2013

 Issue 322882  has been merged into this issue.

Comment 26 by, Nov 26 2013

What about allowing an Chrome Extension to access DevTools? So it would allows us to select a theme to use by selecting the Custom.css from somewhere (and/or even from a website listing)?

So no hacks or workarounds with having to go on Users\{username}\{tons of sub-folders}\Custom.css or using inject scripts. I really loved DT customization, specially because my eyes hurt with white BG, so I used simonowendesign's SO-Dark-Monokai-v3.

Thumbs up for something official for customizing.

Comment 27 by, Nov 26 2013

I like the idea of having this customization under a Chrome Extension.

Comment 28 by, Nov 27 2013

This feature was holding back our work on improving style recalc performance in Blink. So, we're not inclined to add it back in. Sorry for the breakage. I didn't realize at the time that people used this feature in this way.

Comment 29 by, Nov 27 2013

What work around is proposed then as this could potentially kill chrome devtools for a few people? I'm starting to get to the point where devtools feels broken now and am seriously considering switching back to firebug or even firefox's native tools.

Comment 30 by, Nov 27 2013

Labels: Restrict-AddIssueComment-EditIssue
Status: Assigned
Thanks Ojan for chiming in. Indeed the breakage was not intentional, but it did reveal the hack that is how DevTools styling is done. 


If you head into about:flags you'll spot chrome://flags/#extensions-on-chrome-urls

When enabled, Chrome extensions can manipulate chrome:// URLs. DevTools is actually at chrome-devtools:// URLs, so we're looking at the possibility of 1) adding that protocol so the flag enables extension support and 2) limiting the surface area to only allow style injection. 

This is still quite experimental, so it's not something we're sure we can pull off. However, it's clear lots of folks use devtools themes so we're trying to make this work for you.

I'll also point out that we'd very happily review CSS polish changes, probably not for a Dark theme, but improvements are are always welcome. :)

Going to close to comments just to limit emails, please do star this ticket to track updates.

Thanks all!

Comment 31 by, Nov 27 2013

Sample extension that will work as a theme in Canary in a couple of days.
1.4 KB Download

Comment 33 by, Nov 27 2013

Status: Fixed
Themes (defined as in comment #31) will work when:

- DevTools experiments are enabled in about:flags
- Allow UI themes experiment is checked in settings

Comment 34 by, Nov 27 2013

Labels: -Restrict-AddIssueComment-EditIssue

Comment 35 by, Nov 27 2013

@paulirish @pfeldman Thanks for keeping us posted.

Out of interest in regards to "probably not for a Dark theme" why a white theme in the first place? Are there many benefits having a white theme over dark?

Comment 36 by, Nov 27 2013

It is the Chromium's default white background that makes us treat existing look  as default. But given how popular dark theme is, we will explore our options there.

Comment 37 by, Nov 28 2013

Someone here asked for design suggestions, here it comes:
Take a look at the developers tools in the latest Safari. They're really more beautiful (and looks like it has more functions) than chrome's.

Comment 38 by, Nov 29 2013

The new theme extension is working now! 
Inserted the css from
Perfect! Thanks for this.

Comment 39 by, Nov 30 2013

Thanks to the Chrome team for providing another means to support devtools theming!

On a sidenote, it looks like styles that use transforms cause some type of repaint delay.  

Using this theme[], you'll notice a delay when expanding or hovering over a node in the elements panel.

Comment 41 by, Dec 1 2013

I created a Yeoman Generator to easily scaffold new themes using this structure:

Comment 42 by, Dec 1 2013

Woohoo! Looking forward to trying this out <3

Comment 43 by, Dec 2 2013

To theme creators and boilerplate owners:

Please note that themes are still not supported officially (there is no stable API for them yet, not backwards compatibility). So our (and now your) users will get their front-ends broken with each and every update from our side.

To mitigate it, you could try adding explicit checks for Chrome version in your theme extension:

if (/Chrome\/(\d\d)/.exec(navigator.userAgent)[1] == 34)
    // inject stylesheet for Chrome 34
else if (/Chrome\/(\d\d)/.exec(navigator.userAgent)[1] == 33)
    // inject stylesheet for Chrome 33
    // do nothing

You will then be able to have multiple versions of stylesheets for different Chrome versions + you will have enough time to issue stylesheet updates along with your extension without breaking your users.

We'd like to keep providing great experience to our users and we now need your help!

Comment 44 Deleted

Comment 45 by, Dec 21 2013

Don't mean to hijack the thread, but I wanted to draw attention to the fact that the removal of user-stylesheet support is impacting more than just DevTools themers.

I was using a user stylesheet to work around the issue that Chrome no longer uses the OS-native scrollbar widget *and* (more importantly) removes the arrow buttons from the scrollbars, as discussed in  Issue 294543  and  Issue 318616 , which is a major hindrance in my daily work.

Comment 46 by, Jan 15 2014

Could you guys just bake in a dark-theme for chrome tools? I would have switched to Firefox, but their dev tools doesn't allow you to add styles on the fly like this:
251 KB View Download

Comment 47 by, Jan 15 2014

If so (dark theme), Solarized Light and Dark please. So I don't have to install another extension.

Comment 48 by, Feb 1 2014

This is a bummer, but at the very least there should be API for User StyleSheet-like extensions. There isn't any. I created an issue for this purpose:

Comment 49 by, Feb 23 2014

User style (custom.css) is a simple workaround to change the default background color in chrome which is not supported for years. The removing of support for custom.css is really sucks for me no matter what's your purpose. It breaks my adoption to a more suitable background color. To me, this change is evil and the direction is dangerous.

Comment 50 by, Feb 23 2014

After you install Helvetica Neue under Windows, text in Chrome is rendered extremely ugly. The User StyleSheet used to offer a workaround for this until we get the monster-takes 20 years to implement-feature DirectWrite support.

It might be time to switch to another browser. Not just because of this, but Chrome 32 was also a really buggy release.

Comment 51 by, Feb 26 2014

I used user style (custom.css) to change some extension layouts. For example, I use the Gridify extension.  However where the extension places the Gridify button is really annoying. I used custom.css to place elsewhere. Please custom.css back!

Comment 52 by, Feb 27 2014

Screw backward compatibility, apparently. Chrome is breaking left and right.

Comment 53 by Deleted ...@, Mar 2 2014

Chrome does not support the cleartype change in windows. I use custom.css to change the  darkness of the fonts in web changes. Is another way to do it?

Comment 54 by, Apr 14 2014

This has massively increased my development time, there's no way to use my favourite text editor to make mouse free live style updates without installing clunky extensions that only half work. This feels like a really retrograde step for developers - do we know why the user style sheets option was removed? 

Not only that, but an old user style ha remained sticky for me, and now all my Google pages have a red background. This has effectively killed one of my Chrome user profiles. The developer community and site quality will be hurt on account of this change.

Comment 55 by, Apr 14 2014

The old user stylesheet had a perf impact and a complexity cost that was deemed too high for the small population of users that made use of it. I, too, was one of those users and miss it, but it won't be coming back.

Control Freak ( ) is a well-maintained Chrome extension that allows for custom CSS/JS to be injected into specific URLs and domains. Very recommended.

Comment 56 by, Apr 14 2014

Can some explain to me whether this means theme extensions will no longer work? i.e. the "Allow custom UI themes" experiment in Canary?

Or this purely just the old option for custom CSS files?

Comment 57 by, Apr 14 2014

The new theme extensions are safe. Btw, check out which offers a platform for devtools theming. Very nice.

So in summary:

* The old Custom.css files are gone.
* "Allow custom UI themes" is the way forward for devtools themes.
* Control Freak, Stylish, etc are the way forward for adding arbitrary JS/CSS to the web.

Comment 58 by, Apr 14 2014

Thanks for that clarification. Personally, as long as the extensions are safe to customise DevTools then I don’t see the issue and I’m happy that I can continue using dark UI themes.

Comment 59 by, Apr 15 2014

So I can confirm that the best work around for now for rapid CSS prototyping is Stylish Extension:

Sadly it lacks support for the text editor of your choice, and you still need a mouse click on the save button (this adds a lot of roundtrip time for minor edits) but at least the site you are viewing updates on the fly, rather than requiring a refresh. Looks like I'll be using this unless I hear of a better route.

Comment 60 Deleted

Comment 61 by, Apr 29 2014

FWIW I understand why it has been removed and i support that. Perhaps, since many like a dark theme (I, for one, do not) you can offer a light/dark built-in theme like Firefox 29 does?

Comment 62 by, Aug 5 2014

yet, we can still install themes as extensions?
if google doesn't want to provide custom themes, perhaps they could develop so other apps to hook into a devtools api.

Comment 63 by, Nov 1 2014

The missing global stylesheet is a real problem because I used the same stylesheet with Safari and Firefox.

Now is impossible to do the same with Chrome because no extension will be able to read the global stylesheet from the user directory.

Comment 64 by, Feb 5 2015

Note that Chromium does not allow extensions to modify chrome:// internal URLs, so if Chromium wants to outsource user-style support, please enable the browser hooks needed to make that possible.

Comment 65 Deleted

Comment 66 by, May 22 2015

i'm not happy about this. Custom.css is such an easy, simple way to share styles across websites and browsers.

theme extensions mostly apply styles to specific urls, but custom.css is GLOBAL. Url-specific themers are NOT A REPLACEMENT for global css. 

other browsers still have this feature.

i only add one or two simple styles, the filesize of my custom css is tiny. now i am forced to use clunky extension front ends, with fat install footprints. really sucks. 

hate this!

Sign in to add a comment