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

Issue 318566 link

Starred by 81 users

Issue metadata

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

Sign in to add a comment

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
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?
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!
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?
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?
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

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.
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.
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. 
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.
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!
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?

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. 
@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.

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.
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.
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.
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.
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.
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!
Sample extension that will work as a theme in Canary in a couple of days.
1.4 KB Download
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

Labels: -Restrict-AddIssueComment-EditIssue
@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?
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.
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.
The new theme extension is working now! 
Inserted the css from
Perfect! Thanks for this.
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.  
I created a Yeoman Generator to easily scaffold new themes using this structure:
Woohoo! Looking forward to trying this out <3
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.
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
If so (dark theme), Solarized Light and Dark please. So I don't have to install another extension.
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. 
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!
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?
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.
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.
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?
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.
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.
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

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?
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.
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.
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