Closed Bug 1211892 Opened 9 years ago Closed 8 years ago

[gtk3, Ubuntu] Borders/Separators thickness is too pronounced

Categories

(Core :: Widget: Gtk, defect)

All
Linux
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla48
Tracking Status
firefox42 --- unaffected
firefox43 + wontfix
firefox44 - unaffected
firefox45 --- disabled
firefox46 --- verified
firefox47 --- verified
firefox48 --- verified

People

(Reporter: vtamas, Assigned: karlt)

References

Details

(Keywords: regression)

Attachments

(4 files, 2 obsolete files)

Reproducible on Firefox 44.0a1, Firefox 43.0a2 and Firefox 42 Beta 1 under Ubuntu

STR
1.Launch Firefox with clean profile.
2.Focus your attention on borders and separators.

AR
Borders/Separators are more prominent. 
See screenshot: http://i.imgur.com/3yRWX0Z.png


Additional notes:
- This issue is reproducible on Firefox 44.0a1 (2015-10-06), Firefox 43.0a2 (2015-10-06), Firefox 42 Beta 1 (20150921151815) under Ubuntu 12.04 64-bit
- This is a regression because it is not reproducible on Firefox 41 (20150917150946)
- This issue is *not* reproducible on Firefox 42 Beta 2, Firefox 42 Beta 3 and Firefox 42 Beta 4

- Graphics:
+---------------------------------+-----------------------------------+
| Adapter Description             | X.Org -- Gallium 0.4 on AMD RS780 |
+---------------------------------+-----------------------------------+
| Asynchronous Pan/Zoom           | wheel input enabled               |
+---------------------------------+-----------------------------------+
| Device ID                       | Gallium 0.4 on AMD RS780          |
+---------------------------------+-----------------------------------+
| Driver Version                  | 3.0 Mesa 9.1.7                    |
+---------------------------------+-----------------------------------+
| GPU Accelerated Windows         | 0/1 Basic (OMTC)                  |
+---------------------------------+-----------------------------------+
| Supports Hardware H264 Decoding | No; Failed to create H264 decoder |
+---------------------------------+-----------------------------------+
| Vendor ID                       | X.Org                             |
+---------------------------------+-----------------------------------+
| WebGL Renderer                  | X.Org -- Gallium 0.4 on AMD RS780 |
+---------------------------------+-----------------------------------+
| windowLayerManagerRemote        | true                              |
+---------------------------------+-----------------------------------+
| AzureCanvasBackend              | cairo                             |
+---------------------------------+-----------------------------------+
| AzureContentBackend             | cairo                             |
+---------------------------------+-----------------------------------+
| AzureFallbackCanvasBackend      | none                              |
+---------------------------------+-----------------------------------+
| AzureSkiaAccelerated            | 0                                 |
+---------------------------------+-----------------------------------+
| CairoUseXRender                 | 1                                 |
+---------------------------------+-----------------------------------+
[Tracking Requested - why for this release]:
Serious visual regression on a tier-1 platform.
Blocks: ship-gtk3
Component: Theme → Widget: Gtk
Product: Firefox → Core
Summary: [Ubuntu] Borders/Separators thickness is too pronounced → [gtk3, Ubuntu] Borders/Separators thickness is too pronounced
Regression range: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=1ee54e043b9b05d69e6a9f981aa6c4ef0dd65be3&tochange=939320b957c588ad809e9b4a64b7f232dd4d9b72

--> Regression from the initial GTK3 enabling.

Calling Fx42 unaffected since GTK3 was disabled on Beta in https://hg.mozilla.org/releases/mozilla-beta/rev/2ad882095986 (42b2 was the first to contain the disabling, so the results for Fx42 in comment 0 are expected)

Vasilica, it would probably be good to confirm that later Fx42 beta versions are indeed unaffected, though :)
Blocks: 1186003
Flags: needinfo?(vasilica.mihasca)
I confirm that Firefox 42 Beta 2, Firefox 42 Beta 3 and Firefox 42 Beta 4 are not affected but I’ve already provided this information in description :)
Flags: needinfo?(vasilica.mihasca)
Whoopsie, missed that line :P
See Also: → 1213600
Hm, Is that Ubuntu 12.04 only? I installed Ubuntu 15.04 and it looks as expected as well as Fedora with the Ambiance theme.
There are more glitches on the Ubuntu 12.4 (and only there - 14 and 15 are fine). Some menu separators are missing and someone are rendered as solid lines.
The dark menu separators are caused by too dark sFrameOuterLightBorder.
URL/Search entry boxes should be white but those are gray - it's sMozFieldBackground.

I'm not sure how to handle in 12.04 which has pretty old Gtk 3.4.
Attached patch patch (obsolete) — Splinter Review
Fetch border/text/background color from GtkEntry for Gtk3 < 3.8 as we did before.
Seems nice to fix, tracking since it's a regression. 
The fix may need to just ride with 44 though, since 43 only has a week left on aurora.
Attached patch patch v.2 (obsolete) — Splinter Review
Fixed patch. Uses text colors (foreground/background) from TextView in gtk3.4. Tested on Ubuntu 12.04 and looks okay.
Attachment #8677113 - Attachment is obsolete: true
Attachment #8678849 - Flags: review?(karlt)
Comment on attachment 8678849 [details] [diff] [review]
patch v.2

I just realized that the textView is attached early and the frame for 3.8 only. That should be unified in the final patch.
Comment on attachment 8678849 [details] [diff] [review]
patch v.2

Thanks for looking at this Martin.

(In reply to Martin Stránský from comment #8)
> Fetch border/text/background color from GtkEntry for Gtk3 < 3.8 as we did
> before.

Were these really from GtkEntry before?  If so, when?
eColorID_threedhighlight was from a button prior to
https://hg.mozilla.org/mozilla-central/rev/6d06526b4d4a

The comment says "entry" but the patch is using a text view for field and
textselected.

>+    if(!gtk_check_version(3, 8, 0)) {
>+        style = create_context(path);
>+        gtk_style_context_add_class(style, GTK_STYLE_CLASS_VIEW);
>+    } else {
>+        style = gtk_widget_get_style_context(textView);
>+    }

Can the < 3.8 code be used with GTK version >= 3.8?

>+    if(!gtk_check_version(3, 8, 0)) {
>+        GtkWidget *frame = gtk_frame_new(nullptr);
>+        gtk_container_add(GTK_CONTAINER(parent), frame);
>+        style = gtk_widget_get_style_context(frame);
>+    } else {
>+        style = gtk_widget_get_style_context(entry);
>+    }

Is there something that changed in GTK 3.8 or is this just a heuristic for
changes in Ubuntu themes?

Switching from frame to entry seems at least as likely to cause regressions as
improvements in other themes.

Here, a frame makes sense to me for getting 3d border colors, but why choose
entry?

The border color seems a separate issue to the field and textselected colors
and so should be addressed in a separate patch.  GtkTextView for field and
textselected sounds good, but that is a separate issue from the border and so
should be addressed in a separate bug report.

(In reply to Martin Stránský from comment #7)
> The dark menu separators are caused by too dark sFrameOuterLightBorder.

Can't -moz-appearance:menu-separator be used for these?
Attachment #8678849 - Flags: review?(karlt)
(In reply to Karl Tomlinson (ni?:karlt) from comment #12)

Well, this patch is just for Ubuntu 12.04 with gtk 3.4. There's no other distro I'm aware of which uses so old Gkt3 version. The themes in 3.4 are so much different from what we have now (> 3.12 and so) so we need to treat it differently and just for this compatibility reasons.

For instance all new Gtk3 themes use widgets with transparent background, image borders and so. There's just a few base colors which are inherit across the widgets. But the old one sets colors for many widgets exactly below firefox recognition.

For that I think we just need to make sure FF works on Ubuntu 12.04 with basic theme there and don't expect much more.

> >+    if(!gtk_check_version(3, 8, 0)) {
> >+        style = create_context(path);
> >+        gtk_style_context_add_class(style, GTK_STYLE_CLASS_VIEW);
> >+    } else {
> >+        style = gtk_widget_get_style_context(textView);
> >+    }
> 
> Can the < 3.8 code be used with GTK version >= 3.8?

No. The textView does have a transparent background color in new themes.
 
> >+    if(!gtk_check_version(3, 8, 0)) {
> >+        GtkWidget *frame = gtk_frame_new(nullptr);
> >+        gtk_container_add(GTK_CONTAINER(parent), frame);
> >+        style = gtk_widget_get_style_context(frame);
> >+    } else {
> >+        style = gtk_widget_get_style_context(entry);
> >+    }
> 
> Is there something that changed in GTK 3.8 or is this just a heuristic for
> changes in Ubuntu themes?

That means 3.4/3.6 in fact. That's just my guess, IMHO we need to recognize < 3.12 and >= 3.12 but < 3.12 may be very rare.
 
> Switching from frame to entry seems at least as likely to cause regressions
> as
> improvements in other themes.
> 
> Here, a frame makes sense to me for getting 3d border colors, but why choose
> entry?

Well, we just need a widget which is close enough and has defined border color. We used GtkEntry before here (before upgrade to 3.14) so I just reuse the old behavior here.

> The border color seems a separate issue to the field and textselected colors
> and so should be addressed in a separate patch.  GtkTextView for field and
> textselected sounds good, but that is a separate issue from the border and so
> should be addressed in a separate bug report.
> 
> (In reply to Martin Stránský from comment #7)
> > The dark menu separators are caused by too dark sFrameOuterLightBorder.
> 
> Can't -moz-appearance:menu-separator be used for these?

The dark sFrameOuterLightBorder also affects other borders (we fixed that for >=3.14) so we need to correct that anyway. But different menus have different separators which may be worth to unify - looks like toplevel menu uses moz-appearance and bookmars has the separators somehow styled.
There's the textarea patch, Thanks!
Attachment #8678849 - Attachment is obsolete: true
Attachment #8679430 - Flags: review?(karlt)
> > (In reply to Martin Stránský from comment #7)
> > > The dark menu separators are caused by too dark sFrameOuterLightBorder.
> > 
> > Can't -moz-appearance:menu-separator be used for these?

Actually what do you mean here? To use -moz-appearance separators for the themed ones in bookmark?
(In reply to Martin Stránský from comment #15)
> > > (In reply to Martin Stránský from comment #7)
> > > > The dark menu separators are caused by too dark sFrameOuterLightBorder.
> > > 
> > > Can't -moz-appearance:menu-separator be used for these?
> 
> Actually what do you mean here? To use -moz-appearance separators for the
> themed ones in bookmark?

I don't know.  I was confused.

I had assumed from the mention of separators that the expectation was that the
bookmarks doorhanger would look like a native menu, but it is not styled like
a native menu.  It is styled for consistency with the hamburger doorhanger.

(In reply to Vasilica Mihasca, QA [:vasilica_mihasca] from comment #0)
> 2.Focus your attention on borders and separators.
> 
> AR
> Borders/Separators are more prominent. 
> See screenshot: http://i.imgur.com/3yRWX0Z.png

I think we should focus the bookmarks doorhanger in this bug.

I'm not clear whether or not the borders around the location and search bars
are also not rendering as intended, but, if not, then the appropriate solution
there is different and should be addressed in a separate bug.

(In reply to :Gijs Kruitbosch (at OSCON, limited availability) from comment #1)
> [Tracking Requested - why for this release]:
> Serious visual regression on a tier-1 platform.

The native widget corresponding to the doorhanger is the popover, as indicated
in https://bugzilla.mozilla.org/show_bug.cgi?id=978172#c11.

However, that was only introduced in GTK+-3.12.
There is no such native widget in Ubuntu 14.04 or 12.04.

Is there an appropriate native widget on these older systems?
Would rendering them in the same way as popup menus be appropriate.
Running gtk3-widget-factory provides a nice set of samples, but newer versions
at least request CSD so it is probably hard to work with in most desktop
environments.

Do you still think this is serious if it affects only systems older than 18
months?

How this looks compared to GTK2 firefox is irrelevant because GTK2 apps and
GTK3 apps use different themes.  The GTK3 firefox should use the GTK3 theme
and look like other GTK3 apps.

We don't have the proper popover solution in place for more recent systems,
but comment 5 suggests things look fine on more recent systems.  If that is
the case (and probably even if things are not quite perfect), then I don't
think this needs to be a blocker on shipping the gtk3 port.
No longer blocks: ship-gtk3
Comment on attachment 8679430 [details] [diff] [review]
text background patch

Please move this patch to a new bug.  Feel free to link to the screenshot and
discussion in this bug.

(In reply to Martin Stránský from comment #13)
> (In reply to Karl Tomlinson (ni?:karlt) from comment #12)
> 
> For instance all new Gtk3 themes use widgets with transparent background,

> For that I think we just need to make sure FF works on Ubuntu 12.04 with
> basic theme there and don't expect much more.

I don't care so much for a small color tweak with heuristics for an old theme
that has been superseded, but this has detected a problem in our attempts to
imitate GTK, which will likely also affect other themes now and/or in the
future.  We can fix this properly.

> > >+    if(!gtk_check_version(3, 8, 0)) {
> > >+        style = create_context(path);
> > >+        gtk_style_context_add_class(style, GTK_STYLE_CLASS_VIEW);
> > >+    } else {
> > >+        style = gtk_widget_get_style_context(textView);
> > >+    }
> > 
> > Can the < 3.8 code be used with GTK version >= 3.8?
> 
> No. The textView does have a transparent background color in new themes.

Getting the style context from a textview is going to be more consistent with
what GTK does than using a style context from a GTK_TYPE_WINDOW path with
GTK_STYLE_CLASS_VIEW.  (The latter misses GtkTextView CSS selectors and
https://bugzilla.mozilla.org/show_bug.cgi?id=1206516#c4 says that
inheritance does not work on style contexts created from paths.)

However GTK_STYLE_CLASS_VIEW still needs to be explicitly added when getting
the colors, even when using GtkTextView, because GtkTextView does not add this
class until it gets the colors.

3.18 Adwaita has opaque backgrounds set in two places:
https://git.gnome.org/browse/gtk+/tree/gtk/theme/Adwaita/gtk-contained.css?h=3.18.2#n69
https://git.gnome.org/browse/gtk+/tree/gtk/theme/Adwaita/gtk-contained.css?h=3.18.2#n112

Without GTK_STYLE_CLASS_VIEW, only the GtkTextView selector matches and the
background looks similar to the window background.

If some themes are really setting the textview background to transparent, then
we can detect that work out how to deal with that, but I doubt that is
necessary.

GtkTextView does not call gtk_widget_set_has_window (widget, FALSE), and so it
has its own window, and so the parent window background will not be visible.
A transparent background would indicate that the window manager compositor
should draw inferior toplevel windows behind the textview.
Attachment #8679430 - Flags: review?(karlt) → review-
ni? for comment 16.
Flags: needinfo?(gijskruitbosch+bugs)
(In reply to Karl Tomlinson (ni?:karlt) from comment #18)
> ni? for comment 16.

I'm not sure what the question is.

I'm fine with dealing with the url/search bars in a separate bug.

The notification bars I believe are already fixed in current trunk by bug 1162635.

I don't really understand what the before/after looks like in 12.04/14.04 for the bookmarks menu. I haven't checked, but I *think* that's all custom styling, so I also don't know how the native stuff comes into it - if we're now applying native styling in more places than before then perhaps we need to sprinkle moz-appearance: none in the places where we don't want the native styling. OTOH it is confusing to me that you're both saying that we apply native styling and that the old themes don't have appropriate native styling - that makes it sound like we shouldn't be styling these things natively on those old versions in the first place.

Am I missing something? If I didn't respond to the question, please re-request needinfo and make it explicit what you're asking me about. :-)
Flags: needinfo?(gijskruitbosch+bugs)
Is there anything left to do here?  
Can you file a new bug for the url/search bar issue if that's what's left?
It's also still unclear if we're enabling gtk3 for the 43 release (from discussion in bug 1207310).
Flags: needinfo?(stransky)
Flags: needinfo?(karlt)
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #20)
> Is there anything left to do here?  

The issue originally reported in comment 0 has not been resolved, but I'm not
clear what kind of resolution is expected because I don't know what the
expected colors would be.  I also don't think the darkness of color on these
themes is a big enough issue to block shipping the GTK3 port.

IIUC the CSS for the dropdown is requesting some colors from the GTK theme and
we are getting some colors from the theme, but according to this report those
colors are not as expected with this native theme.  I don't know what colors
are expected.

If the colors are wrong, then either the CSS is requesting the wrong colors or
we are getting the wrong colors from the theme.

> Can you file a new bug for the url/search bar issue if that's what's left?

We're not able to file such a bug because we don't know what the expected
appearance would be.
Flags: needinfo?(stransky)
Flags: needinfo?(karlt)
To make progress here, the following would be helpful:

 * Identify the CSS involved in the dropdown borders and separators.

 * Identify a native widget, if any, for which the appearance should be
   copied for the dropdowns.

 * The border-style property used on frames in this theme on these versions of
   Ubuntu.

Based on sFrameOuterLightBorder from comment 7, it sounds like either
threedhighlight or buttonhighlight color is being used for the borders, but
the screenshot in comment 0 indicates that another color is used with that for
the menu separators.

threedhighlight is currently the same as threedshadow.  These colors derive
from the days when toolkits used square frames with colors indicating light
from a particular direction.  Modern themes don't draw frames this way, but if
these older themes use GTK_BORDER_STYLE_INSET/OUTSET/GROVE/RIDGE then I think
it is clear what we can do to improve that.
https://bugzilla.mozilla.org/show_bug.cgi?id=978172#c25

When the themes use a consistent border color for frames, then it is less
clear whether we should be fudging a lighter color, because a frame with
different colors on different borders would be inconsistent with the native
theme.
Wontfix for 43. I'm not sure we need to track this.
Vasilica, is this still a real issue on Ubuntu?
Flags: needinfo?(vasilica.mihasca)
(In reply to Ritu Kothari (:ritu) from comment #24)
> Vasilica, is this still a real issue on Ubuntu?

gtk3 got disabled again in bug 1227024 so I expect it isn't an issue for either 43 or 44.
Setting this to unaffected(In reply to :Gijs Kruitbosch from comment #25)
> (In reply to Ritu Kothari (:ritu) from comment #24)
> > Vasilica, is this still a real issue on Ubuntu?
> 
> gtk3 got disabled again in bug 1227024 so I expect it isn't an issue for
> either 43 or 44.

Thanks Gijs! Marking this unaffected for 44.
I confirm that this issue is no longer reproducible on Firefox 44 beta 4, but Firefox 46.0a1 (2016-01-03) and Firefox 45.0a2 (2016-01-03) are still affected under Ubuntu 12.04 64-bit.
Flags: needinfo?(vasilica.mihasca)
Karl, can you drive this one home? We need to figure out what's going on here so we don't ship this regression with 46, assuming GTK3 ships in 46.
Assignee: nobody → karlt
(In reply to :Gijs Kruitbosch from comment #25)
> gtk3 got disabled again in bug 1227024 so I expect it isn't an issue for
> either 43 or 44.

(It got disabled in 45 as well, in bug 1245476 -- I'm updating the firefox45 status flag to reflect this.)
This is the look we want to aim for.

Comparing with https://bugzilla.mozilla.org/attachment.cgi?id=8720131 it can be seen that the dark frame borders come from not using the unico engine.
Setting the following prefs highlights in blue where these colors are used.

ui.threedshadow;#00007f
ui.threedhighlight;#0000ff

threedhighlight in on the bottom of the separator in the bookmarks dropdown.

menuseparator has -moz-appearance:none
and border-top: 1px solid hsla(210,4%,10%,.15);
 from chrome://browser/skin/customizableui/panelUIOverlay.css
and border-bottom: 1px sold ThreeDHighlight
 from chrome://global/skin/menu.css

threedshadow is on the borders.  I guess this comes from

#nav-bar {
	--urlbar-border-color: ThreeDShadow;
}
in chrome://browser/skin/browser.css

ThreeDHighlight
    Highlight color for three-dimensional display elements. 

ThreeDShadow
    Dark shadow for three-dimensional display elements. 

nsLookAndFeel gets these colors from the border color of a frame.

draw_border() in Unico uses -unico-border-gradient if that and border-style
are not none.

Ambiance in Precise has

.button,
.frame,
.notebook {
    border-style: solid;

    -unico-border-gradient: -gtk-gradient (linear, left top, left bottom,
                                           from (shade (@bg_color, 0.8)),
                                           to (shade (@bg_color, 0.76)));
}
Attached image Appearance with patch
The patch is quite a bit of code just to support an old engine, but other themes may use a gradient in border-image and we can reuse for that.
Comment on attachment 8731922 [details]
MozReview Request: bug 1211892 read -unico-border-gradient of early Unico versions for ThreeDHighlight and ThreeDShadow r?acomminos

https://reviewboard.mozilla.org/r/40939/#review37521

Looks good to me!

::: widget/gtk/nsLookAndFeel.cpp:131
(Diff revision 1)
> +    // providing its own border code.  Ubuntu 14.04 has
> +    // Unico-1.0.3+14.04.20140109, which does not override render_frame, and
> +    // so does not need special attention.  The earlier Unico is assumed to
> +    // occur only with GTK version 3.4 because that is the version on Ubuntu
> +    // 12.04.  (gtk_render_frame() of GTK+ 3.16 ignores the engine altogether.)
> +    if (gtk_check_version(3, 6, 0) == nullptr)

Should we replace this with a check for "-unico-border-gradient" being set in the context? I think it's a bit more readable, and might better handle "frankenubuntus" with mismatching GTK+ and libunico versions.
Attachment #8731922 - Flags: review?(andrew) → review+
https://reviewboard.mozilla.org/r/40939/#review37521

> Should we replace this with a check for "-unico-border-gradient" being set in the context? I think it's a bit more readable, and might better handle "frankenubuntus" with mismatching GTK+ and libunico versions.

Yes, that was a bit awkward.  This version checks engine properties instead of gtk version.
Asking from the property from the context would warn when it did not exist, so another function is used.
Comment on attachment 8731922 [details]
MozReview Request: bug 1211892 read -unico-border-gradient of early Unico versions for ThreeDHighlight and ThreeDShadow r?acomminos

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/40939/diff/1-2/
Comment on attachment 8731922 [details]
MozReview Request: bug 1211892 read -unico-border-gradient of early Unico versions for ThreeDHighlight and ThreeDShadow r?acomminos

Different enough for another look, if you can please.
Attachment #8731922 - Flags: review+ → review?(andrew)
Attachment #8731922 - Flags: review?(andrew) → review+
Comment on attachment 8731922 [details]
MozReview Request: bug 1211892 read -unico-border-gradient of early Unico versions for ThreeDHighlight and ThreeDShadow r?acomminos

https://reviewboard.mozilla.org/r/40939/#review37691
https://hg.mozilla.org/mozilla-central/rev/ea2b3a89986e
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
Comment on attachment 8731922 [details]
MozReview Request: bug 1211892 read -unico-border-gradient of early Unico versions for ThreeDHighlight and ThreeDShadow r?acomminos

Approval Request Comment
[Feature/regressing bug #]:
GTK3 bug 627699
[User impact if declined]:
Looks a little different from other GTK3 apps on Ubuntu 12.04.
I guess there are not many GTK3 apps on Ubuntu 12.04, but this probably makes us
look even more different from GTK2 apps.
Aesthetic only.
The biggest problem is that it will count in someone's tally of regressions.
[Describe test coverage new/current, TreeHerder]:
None.
[Risks and why]: 
Low but non-zero risk.
The main reason to consider not taking a fix on Beta is that this is not
something that we really need to take.
[String/UUID change made/needed]:
None.
Attachment #8731922 - Flags: approval-mozilla-beta?
Attachment #8731922 - Flags: approval-mozilla-aurora?
Comment on attachment 8731922 [details]
MozReview Request: bug 1211892 read -unico-border-gradient of early Unico versions for ThreeDHighlight and ThreeDShadow r?acomminos

Let's try this for beta 5, it would be nice to get it out the door, and we want to look proper on gtk3.
Attachment #8731922 - Flags: approval-mozilla-beta?
Attachment #8731922 - Flags: approval-mozilla-beta+
Attachment #8731922 - Flags: approval-mozilla-aurora?
Attachment #8731922 - Flags: approval-mozilla-aurora+
Depends on: 1260178
Flags: qe-verify+
QA Contact: vasilica.mihasca
This bug is verified fixed on:
- 46.0b6-build1 (20160328182534),
- 47.0a2 (2016-03-30),
- 48.0a1 (2016-03-30),
using Ubuntu 14.04 x86 and Ubuntu 14.04 x64.
I have tested b9 from https://ftp.mozilla.org/pub/firefox/releases/ in arch linux with:

local/gtk2 2.24.30-1
    GObject-based multi-platform GUI toolkit (legacy)
local/gtk3 3.20.3-1
    GObject-based multi-platform GUI toolkit

and borders are still too thick.

https://i.imgsafe.org/162262f.png
Same thing with b11. My gtk theme is adwaita:

community/firefox-theme-adwaita 45.1-1
    Adwaita theme for Firefox (Matches the default GNOME Shell theme)

Seems all pretty standard to me. These awful borders appeared after a recent update, the only way I was able to get rid of them was by customizing the style in userChrome.css.
Carlos, could you file a new bug for your remaining issue? This bug is fixed for some environments at least, based on verification in comment 45.

So the issue that's causing trouble for you is likely different from the issue that was originally targeted here (even though the symptoms are the same).

Link to file a new bug in this same component:
  https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Widget:%20Gtk
Flags: needinfo?(carlosjosepita)
See Also: → 1266914
Flags: needinfo?(carlosjosepita)
You need to log in before you can comment on or make changes to this bug.