178713 - GTK Metal theme causes GTK_WINDOW_PIXMAP errors & color problem

Status: RESOLVED WORKSFORME

(Core Graveyard :: Skinability, defect)

Description

[Charles Slivkoff]

Mozilla reports Gdk-CRITICAL messages using GTK+ "Metal" theme (or variants). 
This visually results in strange colors being displayed in the scrollbars until 
the scrollbar gets focus. I will attach 2 screen-shots to demonstrate.

Gdk-CRITICAL **: file gdkwindow.c: line 1440: assertion `window_private-
>window_type != GDK_WINDOW_PIXMAP' failed.

Gdk-CRITICAL **: file gdkcolor.c: line 1008: assertion `colormap != NULL' 
failed.

Gdk-CRITICAL **: file gdkwindow.c: line 1440: assertion `window_private-
>window_type != GDK_WINDOW_PIXMAP' failed.

Gdk-CRITICAL **: file gdkcolor.c: line 1008: assertion `colormap != NULL' 
failed.

Gdk-CRITICAL **: file gdkwindow.c: line 1440: assertion `window_private-
>window_type != GDK_WINDOW_PIXMAP' failed.

Gdk-CRITICAL **: file gdkcolor.c: line 1008: assertion `colormap != NULL' 
failed.

Gdk-CRITICAL **: file gdkwindow.c: line 1440: assertion `window_private-
>window_type != GDK_WINDOW_PIXMAP' failed.

Gdk-CRITICAL **: file gdkcolor.c: line 1008: assertion `colormap != NULL' 
failed.

Gdk-CRITICAL **: file gdkwindow.c: line 1440: assertion `window_private-
>window_type != GDK_WINDOW_PIXMAP' failed.

Gdk-CRITICAL **: file gdkcolor.c: line 1008: assertion `colormap != NULL' 
failed.

Gdk-CRITICAL **: file gdkwindow.c: line 1440: assertion `window_private-
>window_type != GDK_WINDOW_PIXMAP' failed.

Gdk-CRITICAL **: file gdkcolor.c: line 1008: assertion `colormap != NULL' 
failed.

Gdk-CRITICAL **: file gdkwindow.c: line 1440: assertion `window_private-
>window_type != GDK_WINDOW_PIXMAP' failed.

Gdk-CRITICAL **: file gdkcolor.c: line 1008: assertion `colormap != NULL' 
failed.

Comment 1

[Charles Slivkoff]

Attachment: screen grab of browser with bad colors in scrollbars

Comment 2

[Charles Slivkoff]

Attachment: screen grab of browser with good colors in scrollbars

this was taken after pointer focus had been given to both scrollbars

Comment 3

[Christian Krause]

This problem occurs in the 1.2 release, too.
(OS: linux, gtk+: 1.2.10)

There are no error messages, but the strange colors of the scrollbars are the
same...

The gtkmozembed is also affected, because it shows the same behaviour in galeon.

Comment 4

[Ron]

Attachment: Fix for gtk-engines-0.12

Comment 5

[Ron]

Ok, after some days/nights of bug hunting I found the bug:
gtk-engines (the package containing the gtk metal theme) fills the scrollbar
thumb with a pixmap. To create the pixmap they use the style graphics contexts
that are provided by mozilla. These contexts may have an offset that is used
for fill operations. If you use them to paint into a pixmap you need to set
these offsets (ts_x_origin and ts_y_origin) to 0. The same for the
clip_x_origin and clip_y_origin. The easiest way was to create new style GCs
for pixmap operations. So this whole thing seems not to be a bug in mozilla
but in gtk-engines. I have made a quick hack that fixes the problem. I will
send it to the maintainer of gtk-engines. Maybe he can optimize the stuff a bit.
For the impatient I attached this patch here.

Comment 6

[Ron]

I forgot something: Why is the horizontal scrollbar of type "VerticalScrollbar"?
If you use the metal theme and look carefully at the texture of the thumb you will
see that it is smaller than the vertical one. The reason is that the top and
bottom margin is larger than the right and left one for a vertical scrollbar type.
Since the horizontal scrollbar is of type "VerticalScrollbar" you will have this
strange effect.

Comment 7

[Ron]

Can someone with the necessary permissions reassign this bug to the maintainer of
the GTK component of mozilla? Maybe he hasn't even noticeded this problem. The
"themes" component is not the right place since it has nothing to do with mozilla
themes.

Thanks!
ron

Comment 8

[timeless]

.

Comment 9

[Brian Ryner (not reading)]

-> me

Comment 10

[Julien "_FrnchFrgg_" RIVAUD]

Is this still relevant ?

Comment 11

[Charles Slivkoff]

Not that I can tell. I'm not sure exactly how I observed this behavior, but I am no longer able to recreate it. This may have been reported under HP-UX running GNOME desktop to which I no longer have access.

Comment 12

[Julien "_FrnchFrgg_" RIVAUD]

Note that the GTK code changed a lot since then, especially native theming, so I wouldn't be surprised if it was long fixed. I think people would have filed duplicates or posted here if it wasn't. Resolving WFM.