GNOME Bugzilla – Bug 534611
Text boxes have an extra border around them
Last modified: 2016-03-25 17:13:29 UTC
Please describe the problem: Mainly noticeable in Firefox 3 (beta 5), but all text entry boxes in GNOME 2.22 (under Fedora 9 using the Nodoka theme) have an extra square border behind them. In Firefox, this is a white border which is clearly visible - in other GNOME applications, it is a dark grey border that isn't as visible but is still there. Steps to reproduce: 1. Load Firefox and go to a page with a non-white background and a text box Actual results: You should see a white border around the text box Expected results: The white border would not be visible - just the rounded edges of the text box Does this happen every time? Yes Other information:
Created attachment 111451 [details] Screenshot illustrating the issue in Firefox 3 beta 5
Created attachment 111452 [details] Screenshot illustrating the issue in Nautilus
Some other reports: https://bugzilla.redhat.com/show_bug.cgi?id=439541 - Bugzilla Bug 439541: Native textboxes ugly under Nodoka https://bugzilla.mozilla.org/show_bug.cgi?id=387036 - Bug 387036 – additional border around native GTK button widgets
Looks like an interaction between firefox and the theme(s), to me.
GTK+ bug 513471 is about exactly this issue. There are also mozilla bugs about this. (Mozilla is currently even filling in the whole area, to emulate GTK+, even though there are no non-transparent windows involved.)
The issue is also present in native GNOME applications such as Nautilus though (as per my Nautilus screenshot). Admittedly, it is less noticeable in Nautilus, but it is still present.
...and it is still a theme issue. This border is drawn by nodoka, clearlooks or whatever theme you choose.
The border is drawn by the theme, that is true. However the reason for drawing the border is GTK+. This is because the GtkEntry has a GdkWindow over the whole entry area, and it is not transparent because of that. Also GTK+ sets the background of the window to base[NORMAL]. Because of this the engines (to implement rounded corners) fill the area with bg[NORMAL] on top of the base[NORMAL] fill. The fill from the engine is what you are seeing. But the reason for the fill is that it is the only way to do rounded corners for entries in themes.
Right, since I don't understand the background the GTK+, where does the responsibility for this issue lie? It is a problem in GTK+? Or a problem in the specific program (Firefox and Nautilus)? Or a problem in the theme (Nodoka)?
To fix it one will need changes in GTK+, mozilla (as it emulates GTK+) and the theme engines ...
*** Bug 536121 has been marked as a duplicate of this bug. ***
I can confirm this issue. (just telling because it's status is still : "UNCONFIRMED")
Don't want to rush but now (2 months after my last reply) the status is still UNCONFIRMED while it's in this bug alone confirmed by a few people let alone the other reports about the same issue. What is the progress on this report anyway? @Matthias Clasen - Why do you say it's a issue of the theme engines? your a GTK programmer so you can tell the engine developers what they do wrong and how to fix it. But because big distributions like Fedora (you know all about it ^_^) and Ubuntu are released with those ugly borders and while they both have more then enough resources to adjust the theme engine to show those borders normally.. So How to fix this issue that all theme engine developers encounter and can't fix when they use rounded borders?
The GTK+ theming api doesn't support rounding random corners. Its as simple as that... Benjamin explained the details above.
Oke, i didn't gave this a try but would it work to remove the following 2 lines from gtkentry.c? (line 1349 and 1350 from gtk 4.14.3) gdk_window_set_background (widget->window, &widget->style->base[GTK_WIDGET_STATE (widget)]); gdk_window_set_background (entry->text_area, &widget->style->base[GTK_WIDGET_STATE (widget)]); And remove the same 2 lines on: 2262, 2263, 2449 and 2550. Those 2 lines are put in the gtkentry.c file 3 times in case you wonder. The way it should behave is be fully transparent bu default and let the theme engine draw whatever it wants to draw on it. So don't set a default background like is the case here. (Just my opinion) If my guess is right then a transparent window is created. If a background color needs to be set then perhaps set it in RGBA (if RGBA is not implemented for gdk_window_set_background (specifically GdkColor) then perhaps implement that) then afterwards you can set a color with full transparency in the alpha channel... just guessing here in an attempt to find a solution to this annoying issue.
And a little more ideas.. In the GtkWindow.c file you can find the following lines: gtk_style_set_background (widget->style, widget->window, GTK_STATE_NORMAL); if (window->frame) gtk_style_set_background (widget->style, window->frame, GTK_STATE_NORMAL); /* This is a bad hack to set the window background. */ gtk_window_paint (widget, NULL); There the "gtk_window_paint()" is the one that will case trouble.. it seems to force a paint on a window. If you get that "restriction" out of the window part then it should (if i understand the code correctly) be transparent. Perhaps a setting like : gtk_window_force_paint(true) can be handy.. then let it default to true and let the GtkEntry file change the default to false. I will see if i can find some time to try this stuff out. Kinda hard for me because the compile will take long with GTK and besides that there are more places where this can go wrong (gtkentry.c and gtkwindow.c).
Created attachment 120657 [details] [review] attempt to create transparent windows After taking a good look at the source code together with the gtk manual i found this: http://library.gnome.org/devel/gtk/stable/GtkWidget.html#gtk-widget-set-app-paintable there the comment states that transparency can be simply achieved by adding the line: gdk_window_set_back_pixmap (window->window, NULL, FALSE); So i added that line everywhere where a new window was being created in the gtkentry.c file. I didn't test this myself (not running linux at the moment) but i hope someone else can test it and report there finding here. With a little luck those 2 line edits is all that's needed to patch this annoying issue.
Created attachment 120659 [details] [review] fixed something i forgot in the last one Sorry, i forgot to use the right names.. the previous one would have never worked. This one might just work.
This is now tunable with CSS.