New issue
Advanced search Search tips

Issue 10949 link

Starred by 91 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Jun 2016
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Feature

issue 89649

Sign in to add a comment

Use GTK widget renderering in web content

Reported by, Apr 24 2009

Issue description

Currently we use a widget theme cribbed from Android.

It'd be nice to use GTK, but our renderers don't have access to X and GTK 
depends on X.  So to implement this, we'd need to have the renderers be 
able to IPC up to the browser when they need a rendered widget, and then 
for the browser to send the pixels back down to the renderer.

Depending on the GTK theme:
 - if it only uses cairo, we don't need to involve X at all;
 - if it uses the GdkGC-like APIs for drawing, we might be able to fake it 
out to draw on a pixel buffer;
 - if it calls into X there's no way to avoid it.  This is especially sad 
because it means rendering is blocked on round-trips to X.  Hopefully we 
can cache a lot of rendered widgets to not make it too bad.

See also gtk_widget_get_snapshot, which is part of GTK 2.14 and a version 
ahead of our target.  :(

Comment 1 Deleted

Comment 2 Deleted

Comment 3 by, May 26 2009

 Issue 12602  has been merged into this issue.

Comment 4 by, Jun 25 2009

Labels: Mstone-LinuxBeta
Labels: -Mstone-LinuxBeta Mstone-4

Comment 6 Deleted

Comment 7 by, Jul 10 2009

Summary: Use GTK widget renderering in web content
(Retitling so it isn't confused with erg's recent work.  We now are 80% on using GTK 
widgets in the app normally.)

Comment 8 by, Aug 5 2009

BTW, part of the reason this is marked "large" is that it would likely be a 
significant perf hit for the renderer to need to go up to the browser and then out to 
X during the critical path of drawing.  So fixing this is not only implementing it, 
but then measuring how much it hurts our page load time and figuring out a fix for it.

Comment 9 by, Sep 2 2009

Labels: -Mstone-4 Mstone-X
Neither Evan nor I are very keen on doing this for all widgets, but I think it would 
be a good idea to do it for at least scrollbars. Still, even just scrollbars would be 

Comment 11 Deleted

additional keywords:

scroll bar scrollbar arrow

Comment 13 Deleted

Comment 14 Deleted

Comment 15 Deleted

Comment 16 Deleted

Comment 17 Deleted

Comment 18 by, Sep 24 2009

BTW, since I hadn't noted these here:

1) I had a nice conversation with Owen Taylor (of GTK fame) where he urged me to not 
do this.  Even the GdkGC approach I mention in the bug description, which seems 
reasonable from the APIs involved, seemed to him unlikely to work.  He was also 
unhappy at the number of hacks Mozilla had to do to get GTK-like widgets and how this 
had constrained GTK development.

2) I heard about the GTK 3 theme planning discussions and I mailed them details about 
what we'd need to make this work.  (Basically, the ability to say "render a button 
into this buffer"; we could then do the IPC bits mentioned in the original 
description.)  I'm not sure whether my request was taken seriously / integrated into 
what they were doing, and GTK 3 is still a long way off, but I was hoping to at least 
plant the seed.
 Issue 23130  has been merged into this issue.
Except the performance reduced, what would be the motivations for this?
I personnaly, as a KDE user, see already enough GTK in Chrome.
So web elements look decent and according to the desktop theme? This will help 
integration in ChromeOS too, where the browser dialogs are created outside the browser 
(atm, at least).
The following revision refers to this bug: 

r34183 | | 2009-12-09 12:11:39 -0800 (Wed, 09 Dec 2009) | 13 lines
Changed paths:

linux: theme scrollbars from GTK theme 

Pick the color of the slider's thumbpart and rail from the GTK theme. 
We cannot match the exact visual appearance of the GTK theme, as 
rendering engines can make arbitrary changes to the actual visual 
appearance. But by sampling a representative set of pixels, we ensure 
that we will at least match the general color scheme. 

BUG= 10949 
patch by <markus [at] chromium>
original review:

Review URL:

The following revision refers to this bug: 

r34285 | | 2009-12-10 13:40:32 -0800 (Thu, 10 Dec 2009) | 16 lines
Changed paths:

re-apply r34183

linux: theme scrollbars from GTK theme 

Pick the color of the slider's thumbpart and rail from the GTK theme. 
We cannot match the exact visual appearance of the GTK theme, as 
rendering engines can make arbitrary changes to the actual visual 
appearance. But by sampling a representative set of pixels, we ensure 
that we will at least match the general color scheme. 

BUG= 10949 
patch by <markus [at] chromium>
original review:

Review URL:

Just tried a build containing this code, wow. Huge difference, thanks a lot to 
everyone who was involved!
why can't I see any difference in the latest (r34319) snapshot?
I have not built it for quite a while,Is building it myself a  must?

Comment 26 by, Dec 11 2009

@25: I can see the change in the snapshot. It's just a change to the colors of the 
"Just" :)

One thing I noticed: the background of the scrollbar now has a very dark border (much 
darker than native scrollbars) which does not really look nice. Maybe this can still 
be fixed?

Attached is a screenshot of a native and chrome's scrollbar.
1.8 KB View Download

Comment 28 by, Dec 12 2009

Labels: -Size-Large
Unfortunately, this code is heuristic-y and a bit hacky, and doesn't match most GTK 
themes very well at all.  But Markus was really tired of not being able to see his 
scroll bars, and he thinks this is at least better than it was before.  Hopefully not 
too many people are upset by it.
I do think this is an improvement, and it is certainly easier to see than previously. 
That said, here's another shot of chromium sticking out.
1.5 KB View Download
Maybe you could just take the scrollbar background color, make it a *bit* darker and 
use that for the scrollbar borders? Also, taking the scrollbar handle color and making 
it quite a bit darker for the handle borders and lines?
It is very difficult to get exactly the same look as the native theme, as we do not have access to the 
actual theming engine from within the renderers. And theming engines are essentially at liberty to do 
pretty much anything they want. So, short of doing the expensive round-trip to the browser for each and 
every drawing operation, there is no way we can ever get the exact same pixel values.

In general, we have to be able to do the right thing, independent of whether the user selected a light 
theme, a dark theme, a high-contrast theme, or maybe a theme that has non-rectangular and textured UI 

What we do now is to ask GTK to render both a slider and track for us. We do this once at startup. In most 
cases, these representative examples of sliders and tracks will render exactly the same as the theme, but 
in some cases the theming engine does more complicated things, and the rendered pixel that we get are 
different from the ones that would normally be drawn by the theming engine. Those are the cases where you 
see colors diverge more than you would normally see in other themes.

Once we have these pixels, we then try to find a region within the set of pixels that is relatively 
representative of the whole. This is complicated by the fact that some theming engines draw borders of 
various thickness around the UI elements, whereas others don't (or maybe just use transparency). Also, 
some theming engines include textured elements, whereas others don't.

The upshot is that we can typically determine the average color for slider and track, but we cannot 
reliably determine the border color at all. After all, some themes might not even have a border. We also 
cannot determine any textures that are added to the corners or the middle of the slider.

Overall, we end up just averaging pixel values, and then using them to determine the colors that we will 
use when drawing our slider and our track. As we have no way of computing border colors, that reliably 
gives correct results with all themes, we don't even try. Instead, we use code that determines visually 
pleasing border colors for all possible combinations of slider and track colors. For some themes, this 
border color will happen to be pretty close to the native look. For other themes, it can be wildly 
different. This would be particularly true for high-contrast themes that deliberately pick borders that 
differ a lot from all the other colors.

Our goal with this change was not to match the native look 100%, but instead to provide a look that blends 
in nicely with the native look. This is in line with the rest of Chrome's UI which often subtly differs 
from the native look, but overall makes an attempt to fit in.

I could certainly tweak the algorithm for picking border colors. But after testing with a large number of 
themes, I have come to the conclusion that no matter what we do, it will always look wrong for at least 
some themes. The values that I finally settled on are a compromise that works OK for most of the 
mainstream themes. It is somewhere between light and moderate contrast. Both light and moderate contrast 
themes appear to be in very common use, so this is good. If you prefer a high-contrast theme, you are 
unfortunately out of luck. This algorithm cannot represent that choice.
Thanks for the long post, Markus.

After testing over 50 themes now I have to say the "slider" and "track" colors come very close in most cases. The look is not really a big deal I think (even if the style of the theme's native scrollbars is very different, chrome's scrollbars still fit in quite nicely).

The only thing I am a bit concerned about are results such as shown in comment 29. Orange? Is this the average color you get from the red and grey? 

Is there a technical reason why "slider" and "track" need to have the same border color?
Is there any possibility of providing a method for the user to choose the colors for 
widget rendering (and highlighting, for that matter) through configuration files, 
command line arguments, or UI forms? If automatically choosing colors is so difficult, 
why not let people do it?
Actually evilgnome has a very good point here. I don't think chrome should rely on 
this but it would be nice to have some *extension* which would let you manually 
set/override the scrollbar colors. Does the necessary extension api exist?
By the sounds of things, any way you do this is going to be a bad hack, unless you 
just go back and do what you should have done in the first place: use the GTK 

Comment 36 by, Dec 13 2009

if i'm not mistaken, there are things you can't do with the gtk scrollbar, like 
displaying where all the search results are, which is a feature i really like in 

Comment 37 by, Dec 14 2009

@markus: see, I told you that people would complain about it...

We have this:
you could imagine adding plumbing for more colors.  But I think more work on that 
track is probably not worth the effort.  The closer you get to a native-looking 
scrollbar, the more obvious it is that it isn't a native scrollbar.  I still would 
welcome a correct patch if it could be shown to not destroy performance.  Maybe when 
GTK 3 comes out.  :P
Would be nicer if you didn't have to restart chrome after clicking "Use GTK+ theme" 
for the scrollbar to change colour.

But the only really important thing is that it's no longer an impossible-to-see grey 
on grey!
@evan: we knew that there'd be complaints. Themes are a very emotional topic. Personally, I 
am happy with what we have. It is strictly better than what we had before. At least, now I 
can actually see the scrollbar :-) And if the trade-off is between an exact match of the 
theme versus security and performance, I know which one I prefer.

Ultimately, it would be great if GTK could render pixels into an offscreen buffer without 
needing an X11 display. There'd still be some difficulties in getting native scrollbars 
exactly right in this model, but it would go a long way towards this goal.

@t.lainson: I thought there was an open bug with regards to making theme changes take 
effect immediately, and I think Evan Stade was going to work on it. So, we are aware of the 
problem. This used to work better, but recent changes to how Chrome handles preferences 
broke this feature, and for now you'll need to restart the browser after making a theme 

@michael.monreal: I believe you can adjust the look and feel of scrollbars with CSS style 
sheets. And you actually have quite a large amount of control of the appearance. Is this 
something that can be controlled by extensions? I would suspect so, but I haven't looked in 
detail at the extension API.
I totally agree that what we have now is a lot more usable than before (not regarding 
those themes which have a gray-on-gray scrollbar "on purpose").

Using CSS-like sheets to apply small hacks to the theme colors would be a great way to 
allow users to fix the (minor) shortcomings of the current implementation. What about 
a "userChrome.css" (firefox) like file for stuff like this?

Comment 41 by, Dec 14 2009

Supporting user style sheets is  issue 2393 , but I'm not sure if you can style 
scrollbars in CSS in browsers other than IE.

Comment 42 by, Dec 14 2009

I was wrong, webkit does support styled scrollbars:

If you want to customize them yourself (like with userChrome.css) you can write a user 
script and install it as an extension.
Would it be possible to make the scrollbar's theme somewhat based on the overall 
Chromium theme? At the very least, more contrast would be nice. I generally have a 
hard time seeing the scrollbar.

Comment 44 by, Dec 18 2009

Labels: -Area-BrowserUI Area-UI-Features
Area-UI-Features label replaces Area-BrowserUI label
markus, is it a bug or a "feature" that the classic (and all other non-gtk) themes 
still display the gray-on-gray scrollbar? Meaning, you can not have an individually 
themed browser AND visible scrollbars at the same time?

I really wonder why chrome themes can't provide their own set of scrollbar colors...

Comment 46 by, Dec 30 2009

Chrome themes can't provide their own scrollbar colors because the theming system was 
built on systems where scrollbars always are in one color.  *shrug*
At least IE supports (used to?) colored scrollbars (using CSS)

Comment 48 by, Dec 31 2009

Check out the source on

The following revision refers to this bug: 

r35712 | | 2010-01-07 10:18:54 -0800 (Thu, 07 Jan 2010) | 6 lines
Changed paths:

Only calculate the GTK scrollbar colors once and then update all RenderPreferences on theme change.

BUG= 10949 

Review URL:

Comment 50 by, Jan 13 2010

Labels: -Type-Bug Type-Feature

Comment 51 by, Jan 27 2010

 Issue 31820  has been merged into this issue.

Comment 52 by, Feb 17 2010

 Issue 35972  has been merged into this issue.
Labels: -Area-UI-Features Area-UI

Comment 54 Deleted

I last posted on this bug in Dec. '09, so I think it's time to update with another shot of what this can look like in a gtk environment. Here are a few expressive shots of what chromium looks like on my system.
125 KB View Download
120 KB View Download
117 KB View Download
Same problem here (Ubuntu 10.04 and 10.10)
The scroll bar is not the same as the theme.
Is there any chance that proper gtk theme rendering will be supported for chrome in the near future?

Comment 58 Deleted

Comment 59 by Deleted ...@, Jan 12 2011

No.  I too was hopeful for far too long.

Comment 60 by Deleted ...@, Mar 4 2011

What about buttons, please ? Is it possible they match the GTK theme colors ? How to proceed ? Will be thanks to an extention ?

Chromium for Windows has Aero style controls, Chromium for MacOS X has Aqua controls so why Chromium for Linux doesn't use native GTK+ controls (buttons, check box...) ?

Thank you for your answer !
Because either the developers are too lazy or incompetent to be able to do that!
If you scrolled a bit to the top of this comment list, you could see in that the devs didn't implement this because of performance issues. Also read comment 18 about the way Mozilla used GTK widgets.
It has been just assumed that there will be a performance issue. There is just one scrollbar that has to be painted, how much time does it take to get a scrollbar from X? How many controls/widgets does a web page contain on average and how much time will it take to paint them? I can give you a few solutions myself and since i am not a developer on webkit so I cant program them myself. I believe there is no problem in programming that can't be solved unless you don't want to.

Comment 64 by, Mar 8 2011

 Issue 69672  has been merged into this issue.

Comment 65 by, Mar 8 2011

 Issue 46353  has been merged into this issue.

Comment 66 by Deleted ...@, Mar 13 2011

Thank you for your answer Marcel K. !
Wouldn't it be better if Chromium could provide a special engine API for theming the elements which can't be rendered via GTK+?
Such engine would get a cairo_t* passed to its functions and do all the rendering it wants.
This way theme makers would be able to adapt their themes to Chromium (and, potentially, for other such apps).

Comment 68 by, Jul 19 2011

Blocking: 89649

Comment 69 by Deleted ...@, Aug 1 2011

Now with GTK 3, would it be possible to use native GTK+ controls (buttons, check box...) to match the GTK theme ?

Thank you in advance for your answer !

Comment 70 by, Aug 1 2011

Our renderers still can't access GTK, so while GTK3 might make it easier, there'd likely still be performance consequences.  I don't think GTK3 makes a big difference on this bug.

I found this comment, by a Mozilla VP, pretty interesting:
He regrets doing GTK rendering and suggests that one of the reason Chrome has been popular on Linux is because we *don't* do such a thing.

With all that said, I'd still be happy to review a patch to implement this, if it doesn't regress performance.  So the bug remains open.
I'm of the opinion that most form controls would not benefit from such a patch, regardless of performance. Even if I set my system theme to purple, I probably don't want widgets in the render view to suddenly turn purple because that will break a lot of webpages (especially if they do something like override the default button text color). Webpages are mostly designed for light-colored/silver/grey/beige buttons when their color/appearance is not otherwise specified.

Comment 72 by Deleted ...@, Aug 2 2011

OK, but WebkitGTK+ ( is able to use native GTK+ controls (buttons, check box...) without much performance consequences. Strange !
it won't affect performances, right. all you need is to give gtk a cairo context, and it'll simply draw the widget. the performance compromise is so small (drawing a couple of buttons is in the order of milliseconds) that you can't claim it. maybe it was more complicated with gtk+2, as you needed to create fake widgets, sometime bind them into offscreen windows, etc etc. now it's just pure drawing, pretty fast.
If not use gtk3, then just export a theme API which would use cairo contexts to draw things, like i suggested in comment 67 (any comments on it from devs?).
Being one of oxygen-gtk devs, I'd really like to implement a KDE-Oxygen style for Chromium page widgets, but there lacks a good way (API) to do this.

Comment 75 by Deleted ...@, Aug 2 2011

Thank you andrea for your answer ! :-)
So why Chromium for Linux doesn't use native GTK+ controls (or there is something yet I don't understand) ? ;-)
does any WebkitGTK browser have a multi-process architecture?

Comment 77 by, Aug 3 2011

As said in the bug summary, the renderers don't have access to X or GTK.  To restate that, the part of Chrome that renders page content doesn't have access to any files on your disk, which includes GTK theme files and graphics; I don't believe GTK would even initialize because they don't have access to X either.
But why not even plain cairo engine? Is it really impossible to load a .so outside the renderers and make them call its exported functions to render widgets to gdk-pixbufs or something similar?
I used to want this. Now I'm not so sure.

If work was done to make the widgets Chrome uses now look _awesome,_ so much so that the Safari guys would want to crib them, then I wouldn't mind that they didn't match the native theme.
I think the only thing stopping us from making them look better is finding someone with the talent, motivation and time.
Bumping this. Re: #80, I see that there are (and have been for some time) new form controls inside Settings. The checkboxes, radio buttons, and regular buttons all look beautiful. Is there a possibility these could be made default for form control rendering on regular web pages for Linux?

Comment 82 by, Jun 11 2012

Blocking: -89649 chromium:89649
(Un-ccing myself from bugs.)

Comment 83 by, Nov 27 2012

Blocking: -chromium:89649 chromium:89649
Project Member

Comment 84 by, Mar 10 2013

Labels: -Area-UI Cr-UI
Project Member

Comment 85 by, Jun 19 2016

Labels: Hotlist-OpenBugWithCL
A change has landed for this issue, but it's been open for over 6 months. Please review and close it if applicable. If this issue should remain open, remove the "Hotlist-OpenBugWithCL" label. If no action is taken, it will be archived in 30 days.

For more details visit - Your friendly Sheriffbot
There seems to be little point in implementing this now, as Chromium has dropped support for GTK rendering of the menus, toolbars and tooltips (somewhere near version 35).
Status: WontFix (was: Available)
I agree, now that we no longer use GTK this doesn't make sense anymore.

Sign in to add a comment