406140 - The inner-border style property of GtkButton is not read

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect)

Description

[Benjamin Berg]

User-Agent:       Mozilla/5.0 (X11; U; Linux ppc; en; rv:1.8.1.9) Gecko/20071101 (Debian-1.8.1.9-2) Epiphany/2.20
Build Identifier: 

Since GTK+ 2.10 there is a inner-border style property for GtkButton. This style property replaces the old hard coded "child_spacing".

Reproducible: Always

Comment 1

[Reed Loden [:reed]]

Maybe Ventron or twanno can look into this.

Comment 2

[Teune van Steeg]

Attachment: patch

Use the inner-border style property instead of using the hard coded child_spacing.

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 300649 [details] [diff] [review]
patch

moz_gtk_button_get_metrics should be called moz_gtk_button_get_inner_border instead?

Comment 4

[Teune van Steeg]

Attachment: patch v1.1

Updated patch, addresses comment #3

This makes the buttons drawn in Firefox follow GTK Theme configuration more closely.

Comment 5

[Reed Loden [:reed]]

Checking in widget/src/gtk2/gtk2drawing.c;
/cvsroot/mozilla/widget/src/gtk2/gtk2drawing.c,v  <--  gtk2drawing.c
new revision: 1.72; previous revision: 1.71
done
Checking in widget/src/gtk2/gtkdrawing.h;
/cvsroot/mozilla/widget/src/gtk2/gtkdrawing.h,v  <--  gtkdrawing.h
new revision: 1.52; previous revision: 1.51
done

Comment 6

[Robert [minotaur 11]]

With this bugfix included i get a empty browser window (just the menu bar) under Debian Etch (GTK 2.8).
(Gecko:5683): Gtk-WARNING **: gtkwidget.c:7322: widget class `GtkButton' has no property named `inner-border'

I don't now if this is a valid bug (runtime requirement seems to be GTK 2.10), but in a blog entry about a crash when trying to print under GTK 2.8, Michael Ventnor mentioned that the problem would be taken into account.

Comment 7

[cris]

just think I would mention that ASUS EEE has above mentioned "empty window problem". Since Its quite impossible for EEE user to update gtk. I would suggest this problem being investigated again.

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Will EEE users actually be able to install FF3 (when it's done)?

Comment 9

[cris]

I don't know, but mozilla.com always offer direct extractable packages, so if its offered from official website, it should run properly, even if no *.deb from ASUS.

Comment 10

[Ian Spence]

Would it be that hard to add a check for gtk version?  I'm all for requiring 2.10, but I think it'd be best to actually require it (that is, throw an error on boot, not just break) or at least insert a workaround.  With the parts that I've introduced that have required 2.10, they have only removed little lines.  They never broke the browser

[Sidebar: I also think we should consider adding small things from 2.12 by using checks. This would allow for things like arrow-scaling]

Comment 11

[Teune van Steeg]

(In reply to comment #10)
> Would it be that hard to add a check for gtk version?
>
No, I can create a patch if that is desired.

> [Sidebar: I also think we should consider adding small things from 2.12 by
> using checks. This would allow for things like arrow-scaling]
> 
That is being implemented in bug 415163

Comment 12

[cris]

I don't know if GTK 2.10 is going to be officially required to run firefox 3.

Im fine either way, I can jut run 20080206 nightly, or try a new distro, Maybe ASUS will compile a version of firefox 3 for gtk 2.8 (which I doubt). Im just saying ASUS EEE pc is a significant linux market that has very impressive future, if its not very hard, developers might want to find a work around here.

Comment 13

[Ed Lee :Mardak]

Will discussion continue here about getting Firefox 3 working on EEE PC or is there a better bug for that?

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

We should probably file a new bug on that.

Comment 16

[Jonathan Leet]

See bug 418885 for discussion of eliminating/reducing the GTK+ 2.10 dependency. A patch has already been proposed that fixes the "inner-border" issue (amongst other things) introduced here.