GTK location bar drop-down button arrow is misaligned

RESOLVED FIXED in mozilla1.9beta5

Status

()

RESOLVED FIXED
11 years ago
11 years ago

People

(Reporter: ori, Assigned: frnchfrgg)

Tracking

Trunk
mozilla1.9beta5
x86
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 11 obsolete attachments)

(Reporter)

Description

11 years ago
Using GTK and the Ubuntu Human theme, the button is 20 pixels wide, while the arrow is 11 pixels wide.
This means that the arrow can never truly center inside the button.

If most theme arrows have an uneven width, the button should be wider by a pixel.

Comment 1

11 years ago
Created attachment 301153 [details] [diff] [review]
patch

This patch updates the dropdown button size and arrow size calculation, so it is exactly like GTK's calculations. This fixes the arrow position in QTCurve at least (mentioned in bug 405210 comment #34).

But because the dropdown button is currently broken in QTCurve (caused by bug 413084), this patch includes a fix for that too: In contrary to other themes QTCurve needs a gtk_widget_realize for the dropdown button, and an arrow can not be added to the drop down button or the button's child (QTCurve paints its own arrow as part of painting the button). 

Coincidentally this patch also updates the arrow calculations for the scrollbar buttons to mimic GTK's calculations.

As a side effect of this patch the location bar will be 1px higher, which makes the larry button 1px too small. That should have been prevented by the fix for bug 401893, but it seems gnomestripe needs an additional change in browser.css to fix it correctly on Linux, which is included in this patch.

Finally this patch requires the fix for bug 406140, because it makes use of moz_gtk_button_get_inner_border which is added there. And also this patch assumes the patch for bug 414748 has been applied.
Assignee: nobody → twanno
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #301153 - Flags: superreview?(roc)
Attachment #301153 - Flags: review?(roc)

Updated

11 years ago
Depends on: 406140

Comment 2

11 years ago
Comment on attachment 301153 [details] [diff] [review]
patch

Asking additional review for the browser.css change which is based on the fix for bug 401893
Attachment #301153 - Flags: review?(rflint)

Updated

11 years ago
Component: Theme → Widget: Gtk
Product: Firefox → Core
QA Contact: theme → gtk

Comment 3

11 years ago
Created attachment 301395 [details] [diff] [review]
patch that actually applies

The previous patch was kind of broken.

It still assumes code is present from the patch on bug 414748, so it needs to be added on top of that patch.
And it needs the inner_border property implemented by the patch in bug 406140
Attachment #301153 - Attachment is obsolete: true
Attachment #301395 - Flags: superreview?(roc)
Attachment #301395 - Flags: review?(roc)
Attachment #301153 - Flags: superreview?(roc)
Attachment #301153 - Flags: review?(roc)
Attachment #301153 - Flags: review?(rflint)

Comment 4

11 years ago
Comment on attachment 301395 [details] [diff] [review]
patch that actually applies

Asking additional review for browser.css part. See comment #2
Attachment #301395 - Flags: review?(rflint)
Attachment #301395 - Flags: review?(rflint) → review+
Comment on attachment 301395 [details] [diff] [review]
patch that actually applies

Can you rerequest review when the patches this depends on have landed?
Attachment #301395 - Flags: superreview?(roc)
Attachment #301395 - Flags: review?(roc)
(Assignee)

Updated

11 years ago
Depends on: 414748
(Assignee)

Comment 6

11 years ago
I set blocking on 414748 even if it doesn't really need that patch's functionnality to better track when this patch can land.
(Assignee)

Updated

11 years ago
Blocks: 416003
(Assignee)

Comment 7

11 years ago
Note that your patch removes all calls to calculate_arrow_dimensions yet modifies it... Is this normal ?
(Assignee)

Comment 8

11 years ago
I think you need a

calculate_arrow_dimensions(&arrow_rect, &real_arrow_rect, direction);

between the arrow_rect calculus and the gtk_paint_arrow in the dropdown_arrow_paint function

Comment 9

11 years ago
Created attachment 301946 [details] [diff] [review]
updated patch

(in reply to comment #8)
> I think you need a
> 
> calculate_arrow_dimensions(&arrow_rect, &real_arrow_rect, direction);
> 
> between the arrow_rect calculus and the gtk_paint_arrow in the
> dropdown_arrow_paint function
>
Yes, thanks, that got lost somehow. It has been added again in this patch.
Attachment #301395 - Attachment is obsolete: true

Comment 10

11 years ago
Created attachment 302458 [details] [diff] [review]
patch updated to tip
Attachment #301946 - Attachment is obsolete: true
Attachment #302458 - Flags: superreview?(roc)
Attachment #302458 - Flags: review?(roc)
+        if (GTK_IS_HBOX(buttonChild)) {

Is this really a reliable way to detect the QTCurve theme and the need for this workaround?

+    if (state_type == GTK_STATE_ACTIVE) {
+        gtk_widget_style_get(gDropdownButtonWidget,
+                             "child-displacement-x", &x_displacement,
+                             "child-displacement-y", &y_displacement,
+                             NULL);
+        arrow_rect.x += x_displacement;
+        arrow_rect.y += y_displacement;
+    }

This code should be shared.

Can you get review from Ian Spence or something else who knows GTK better than I do?
(Assignee)

Comment 12

11 years ago
This is not a reliable way to detect QtCurve. This is a reliable way to detect a theme which forces the alternative layout of ComboBoxe(Entry)s. The thing is that there are 2 different possible layouts for comboboxes (and two sublayouts for each), and one doesn't have an inner hbox in the button. Even in the GTK code there's a comment saying that the combobox code is strange and hackish due to these two possible layouts; so when we don't have an inner hbox, we cannot add our arrow to it so it will correctly be themed, but we still need to attach it to a widget/window so we can paint with it.

> This code should be shared.

What do you mean by shared ? Scrollbars use "arrow-displacement", non editable comboboxes seem not to use any displacement at all (not that it matters in native GTK since the list pops up over the widget, so it is not visible, except when the popup is empty). In my patch for bug 415830 I use the function calculating this arrow rect in two places, but one doesn't have any displacement.

Note also that currently the borders advertized don't change when ACTIVE, so the inner gecko frames won't move, which can look strange next to a native rendering which will do. This is also an argument in favor of not using displacement for non editable menulists.

While writing patches for bug 416003 and bug 415830 I dived in the (not always shiny) internals of gtk, helped by Benjamin Berg on #gtk, and I think that the code added mimics what gtk does (modulo what I change in those bugs); using gtk_widget_size_request is a great way to get the good size without having to rewrite the sometimes hairy gtk sizing code.

If the patch suits you mozilla wise, I think I can grant review for the gtk part (unless you think there is a conflict of interest since a lot of my recent work bases upon this patch)
(Assignee)

Comment 13

11 years ago
NB: QtCurve is one of such themes (the only I know of currently)
+        if (GTK_IS_HBOX(buttonChild)) {

I guess you want to test the "appears-as-list" style property with that? Instead of poking at private implementation details that may change, why not simply use gtk_widget_style_get to get the property's value?
(Assignee)

Comment 15

11 years ago
Christian: Why not, but are we sure that as long as "appears-as-list" is false there will be an inner HBOX ?

Is there a different way, more robust against internal GTK changes, to get the arrow widget of ComboBoxes and ComboBoxeEntries ?
(Assignee)

Comment 16

11 years ago
(or to attach a new arrow to the ComboBox like is done now)
(Assignee)

Comment 17

11 years ago
Created attachment 303294 [details] [diff] [review]
Use a more robust way to retrieve the arrow

Does that suit you better, christian ? Teune, what do you think ?
Attachment #302458 - Attachment is obsolete: true
Attachment #303294 - Flags: review?(chpe)
Attachment #302458 - Flags: superreview?(roc)
Attachment #302458 - Flags: review?(roc)
(Assignee)

Comment 18

11 years ago
Comment on attachment 303294 [details] [diff] [review]
Use a more robust way to retrieve the arrow

I'd like to put a warning when we encounter the "last resort" case for us to be notified when we need to adapt since gtk has changed, but NS_WARNING is not defined here. Robert, what should I do ?
Attachment #303294 - Flags: review?(twanno)
(Assignee)

Comment 19

11 years ago
Created attachment 303296 [details] [diff] [review]
Only the difference with previous attachment

For those who want, this is only what changed from Teune's patch.
(In reply to comment #18)
> (From update of attachment 303294 [details] [diff] [review])
> I'd like to put a warning when we encounter the "last resort" case for us to be
> notified when we need to adapt since gtk has changed, but NS_WARNING is not
> defined here. Robert, what should I do ?

Add #include "nsDebug.h" for NS_WARNING ?

Comment 21

11 years ago
(In reply to comment #17)
The problem is that we make use of internal children that may change per theme:

I did some testing with toggling the appears-as-list value, it turns out we are crashing when changing from one GTK theme to another when appears-as-list is different in the new theme.

With the current code, we probably crash because the gArrowWidget is not longer valid, because the children of the drop down button are destroyed and readded. But we still crash if gArrowWidget is a child of protoLayout (GtkFixed). In that case it turns out that we crash when trying to get the xthickness of gDropdownButtonWidget. My assumption is that gDropdownButtonWidget does not longer point to a GtkWidget at that moment either, and has been remove from the GtkComboBoxEntry widget too, and after that recreated.

If my assumption is true, setting gDropdownButtonWidget to NULL on theme change, and - with the current code - gArrowWidget too, would probably prevent the crash.

Maybe it is even possible to destroy the protowindow on theme change so that all widgets can be reinitialized (that would fix bug 411091).
(Assignee)

Comment 22

11 years ago
If I'm not tollally off-track, I think that even with the previous method we will crash, since the added widget will be a child of the hbox, which will be destroyed, along with it's children... Perhaps indeed we should reinitialize all our widgets on theme change. Could this be another bug ?

The other solution (to this problem only) is perhaps to test for GTK_IS_WIDGET(widget), and not (!widget) in our ensure_functions...

Comment 23

11 years ago
Comment on attachment 303294 [details] [diff] [review]
Use a more robust way to retrieve the arrow

Checking for GTK_IS_WIDGET, would solve the crash,
> static gint
>-ensure_arrow_widget()
>+ensure_combo_box_entry_widgets()
> {
but you have to ensure every widget individually, to make sure the widget you are using is available

>+            /* appears-as-list = FALSE, the button contains a cell renderer,
>+             * a separator, and an arrow (the first two are there because
>+             * ComboBoxEntry inherits from ComboBox, but are unused here) */
To make things complicated, there doesn't seem to be a separator in the HBox for ComboBoxEntries, only an arrow.
 
>-    ensure_arrow_widget();
>-    ensure_dropdown_entry_widget();
>-    gtk_widget_set_direction(gDropdownButtonWidget, direction);
>+    ensure_combo_box_entry_widgets();
ensure_arrow, ensure_dropdown_entry and ensure_dropdown_button here individually (see above)

>-        ensure_dropdown_entry_widget();
>+        ensure_combo_box_entry_widgets();
ensure_dropdown_button here
>+    GtkRequisition requisition;
>+    ensure_arrow_widget();
same here

>-        ensure_dropdown_entry_widget();
>+        ensure_combo_box_entry_widgets();
ensure_dropdown_entry_widget here

Since you can't include nsDebug.h, maybe use a GTK warning if that is possible?

Comment 24

11 years ago
(In reply to comment #22)
> Perhaps indeed we should reinitialize
> all our widgets on theme change. Could this be another bug ?
>
That would be bug 411091 then.
(Assignee)

Comment 25

11 years ago
Created attachment 303329 [details] [diff] [review]
Use a more robust way to retrieve the arrow, v1.1

This time with checks to avoid crashing if the inner layout of the ComboBox has changed.
Attachment #303294 - Attachment is obsolete: true
Attachment #303329 - Flags: review?(twanno)
Attachment #303294 - Flags: review?(twanno)
Attachment #303294 - Flags: review?(chpe)

Comment 26

11 years ago
Comment on attachment 303329 [details] [diff] [review]
Use a more robust way to retrieve the arrow, v1.1

Thanks for your work on this Julien, this patch doesn't crash on changing the themes.

>+    if (!(GTK_IS_WIDGET(gDropdownEntryWidget) &&
>+          GTK_IS_WIDGET(gDropdownButtonWidget) &&
>+          GTK_IS_WIDGET(gArrowWidget))) {
I'd rather see !... || !... || !... here, because that makes the code easier to read IMHO. 

>+            /* appears-as-list = FALSE, the button contains an hbox. This hbox 
>+             * is there because ComboBoxEntry inherits from ComboBox which
>+             * needs to place a cell renderer, a separator, and an arrow in
>+             * the button when appears-as-list is FALSE. Here the hbox should
>+             * only contain an arrow, since a ComboBoxEntry doesn't need all
>+             * those widgets in the button, but we loop over the children
>+             * anyway, to be on the side of safety */
AFAIK the standard way to get a child of a hbox/vbox is to loop over the children anyway (by using a GList) :) 

>+        ensure_combo_box_entry_widgets();
>         w = gDropdownEntryWidget;
>         break;
>     case MOZ_GTK_DROPDOWN_ARROW:
>         ensure_arrow_widget();
Use ensure_combo_box_entry_widgets() here and below too.

>+    GtkRequisition requisition;
>+    ensure_arrow_widget();
Attachment #303329 - Flags: review?(twanno) → review+
(Assignee)

Comment 27

11 years ago
Created attachment 303390 [details] [diff] [review]
Patch v1.2

With comments addressed
Attachment #303296 - Attachment is obsolete: true
Attachment #303329 - Attachment is obsolete: true
Attachment #303390 - Flags: superreview?(roc)
Attachment #303390 - Flags: review+
(Assignee)

Comment 28

11 years ago
The comment regarding "appears-as-list" is a little wrong in last patch, there are two settings: "appears-as-list" and "cell-view", and only if appears-as-list is false and cell-view is true there is an HBOX, else the arrow is directly contained by the button.
(Assignee)

Comment 29

11 years ago
I'll post an updated patch with the right comment later
+        buttonChild = GTK_BIN(gDropdownButtonWidget)->child;

Here, we crash if we failed to find gDropdownButtonWidget. That seems unnecessarily fragile. If something changes in GTK it would be better to draw the wrong arrow than crash.
(Assignee)

Comment 31

11 years ago
It's currently not possible for the ComboBoxEntry not to contain a toggle button, but indeed if that changes, we crash.
I think gtk cannot change such a thing in subsequent versions, it would break a lot of themes at least, but if you feel more comfortable, let's do it.

Note that in some other places, like when we gtk_widget_style_get, if the value doesn't exist anymore we also crash since the pointer is then left untouched.

We could also crash if a widget disappears behind our back (that's why I think it would be better to replace all !widget tests by GTK_IS_WIDGET(test), or even GTK_IS_WHATWEWANT(widget) in the ensure functions.
> let's do it.

Thanks.

I'm less concerned about themes dynamically changing their widgets and styles. GTK_IS_WIDGET() checks wouldn't really help anyway. Let's not worry about that.
(Assignee)

Comment 33

11 years ago
Robert: The second case already exists, when a theme is changed, the inner layout of ComboBoxes change. Granted, gtk should never invalidate a non internal widget (which we asked for explicitely), so the problem should only exist for gDropdownButtonWidget and gArrowWidget. I'll rewrite the code so I get fallbacks every time.
I think I could fallback to the tooglebutton for gDropdownButtonWidget, what do you think ?

The risk, though, is that if one time we use the fallback, then this widget will never more be invalidated and won't ever adapt to theme changes, even if the user goes back to a theme which have an inner button (currenlty it is impossible not to, but it could change during Firefox 3 life). It's better than crashing, but I don't see a reliable solution to avoid this problem, apart from destroying the protoWindow each theme change (which should be done no matter what to solve other bugs)
(Assignee)

Comment 34

11 years ago
I meant fallbacks every time for those two widgets. Note that the inner button of a ComboBox *is* a toogle button, that's why I think it's a good fallback.
(Assignee)

Comment 35

11 years ago
Created attachment 303569 [details] [diff] [review]
patch v1.3

Is that better ? (I also ensured that we don't crash if we don't succeed in retrieving the inner entry widget)
Attachment #303390 - Attachment is obsolete: true
Attachment #303569 - Flags: superreview?(roc)
Attachment #303390 - Flags: superreview?(roc)
(Assignee)

Comment 36

11 years ago
Created attachment 303630 [details] [diff] [review]
Patch v1.4

Slightly updated
Attachment #303569 - Attachment is obsolete: true
Attachment #303630 - Flags: superreview?(roc)
Attachment #303630 - Flags: review?
Attachment #303569 - Flags: superreview?(roc)
> I'll rewrite the code so I get fallbacks every time.

What did you mean by that? I thought you were going to change the code so we search the internals of the combobox every time we need one of those internal widgets, but you haven't done that.

Who did you mean to request review from?
Attachment #303630 - Flags: review? → review?(twanno)
(Assignee)

Comment 38

11 years ago
I think that searching the internals of the combobox every time we paint a part of it is too expensive. The current way ensures that if the internal layout changes, the widgets will be destroyed and thus our pointers will be invalid, which will trigger a new fetch of them.

ventnor would be great for the review, or twanno (but since this patch is based on his work, I'm not sure it's correct to request review from him)
You can't rely on GTK_IS_WIDGET(widget) returning false after widget has been destroyed. GTK might create a new widget with the same address, so you'd just carry on and use the wrong widget. Or maybe the memory would look like it's a real widget but it's mostly just garbage, and then you crash in very hard to reproduce ways.

Comment 40

11 years ago
I could be missing the point of this, but why not just catch the notify-theme-change signal and set the widgets to null accordingly?
That sounds like the right idea.
(Assignee)

Comment 42

11 years ago
Isn't there a reliable mean to check if a pointer is still valid ? Using GTK_IS_<thing> would address the problem of a new widget at the same address, but not of widget-looking garbage...

I'm not sure it is wanted to correct the "destroy the protowindow and NULL the pointers on notify-theme-change instead of just on shutdown" bug here; I'll happily write a patch for it, but I'd rather not jam that in existing patches here (which are already rather big). I also think that that bug would be fairly independent of this one, and not bitrot it (it would be just a matter of calling the cleanup function more often, IIUC)

The global structure of the added ensure functions is still correct, I can just revert to != NULL checks at the right places. What do you think ?
(In reply to comment #42)
> Isn't there a reliable mean to check if a pointer is still valid ?

No.

> I'm not sure it is wanted to correct the "destroy the protowindow and NULL the
> pointers on notify-theme-change instead of just on shutdown" bug here; I'll
> happily write a patch for it, but I'd rather not jam that in existing patches
> here (which are already rather big). I also think that that bug would be fairly
> independent of this one, and not bitrot it (it would be just a matter of
> calling the cleanup function more often, IIUC)

Maybe we should do that one first then. I don't want to land something unsafe here.
(Assignee)

Comment 44

11 years ago
Created attachment 305775 [details] [diff] [review]
Patch v1.5

Does this patch suit you better ? Gtk automatically NULLs our pointers when they are becoming invalid... I only did that for widgets without an explicit controlable reference (GTK holds itself a reference to each window, and a parent holds a reference to each of its children).

Note that the part about making our widget code react to theme change may still be needed to enable gecko not to stay stuck in the "fallback to a common widget" mode. Currently, as soon as we use such an emergency fallback, the widget is ensured to stay valid (and we hope so!) so that means that even when changing back to a non problematic theme, the fallback will be used. It's not a real problem, though, since this emergency fallback is only to be sure we won't crash if ever gtk internals change, which is rather unlikely (and would probably mean more would break graphically-wise anyway).
Assignee: twanno → frnchfrgg-mozbugs
Attachment #303630 - Attachment is obsolete: true
Attachment #305775 - Flags: superreview?(roc)
Attachment #305775 - Flags: review?(ventnor.bugzilla)
Attachment #303630 - Flags: superreview?(roc)
Attachment #303630 - Flags: review?(twanno)
That'll do. But don't we have to remove the weak pointer when we shut down?
(Assignee)

Comment 46

11 years ago
I don't think so, since the weak pointer just means that Gtk will automatically NULL our pointer when it becomes invalid, and since we destroy all our widgets at shutdown, the worst that can (and will) happen is that the pointer will be NULLed two times in a row.
But after nulling out the pointer, does GTK forget about it? I guess it must. OK.
(Assignee)

Comment 48

11 years ago
It's not a gtk facility, it's a gobject (glib) one. And it doesn't matter if it forgets about it, a widget cannot be released several times; in fact, it is certain that it forgets about it, else it wouldn't make sense, and it's far more easier to attach the weak ref list to the object which would ensure the list is forgotten along with the widget.
Attachment #305775 - Flags: superreview?(roc) → superreview+

Updated

11 years ago
Attachment #305775 - Flags: review?(ventnor.bugzilla) → review+
Attachment #305775 - Flags: approval1.9?
(Assignee)

Comment 49

11 years ago
I'll attach a patch with a summary of comments 44, 46, and 48 too. Coming soon, but not tonight.
(In reply to comment #49)
> I'll attach a patch with a summary of comments 44, 46, and 48 too. Coming soon,
> but not tonight.

Code freeze for b4 is tonight. Any possible way you could get it done sooner?
Comment on attachment 305775 [details] [diff] [review]
Patch v1.5

a=beltzner for 1.9
Attachment #305775 - Flags: approval1.9? → approval1.9+
(Assignee)

Comment 52

11 years ago
Created attachment 305970 [details] [diff] [review]
patch v1.6, for checkin

When I wrote "not tonight", I meant that it was 2oclock in the morning where I live, and so I decided to continue after a bit of sleep. I hope it's not too late.

Be sure to credit Teune also, he wrote the major part of this patch.
Attachment #305775 - Attachment is obsolete: true
Thanks for all the hard work on this, guys!

Checking in browser/themes/gnomestripe/browser/browser.css;
/cvsroot/mozilla/browser/themes/gnomestripe/browser/browser.css,v  <--  browser.css
new revision: 1.196; previous revision: 1.195
done
Checking in widget/src/gtk2/gtk2drawing.c;
/cvsroot/mozilla/widget/src/gtk2/gtk2drawing.c,v  <--  gtk2drawing.c
new revision: 1.85; previous revision: 1.84
done
Checking in widget/src/gtk2/nsNativeThemeGTK.cpp;
/cvsroot/mozilla/widget/src/gtk2/nsNativeThemeGTK.cpp,v  <--  nsNativeThemeGTK.cpp
new revision: 1.145; previous revision: 1.144
done
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9beta4
I backed this out to try to fix centos5 orange:

*** 11897 ERROR FAIL | window.open has correct height dimensions | got 201, expected 200 | /tests/docshell/test/test_bug344861.html
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I verified in my local build that this patch is responsible for that failure.
(Assignee)

Comment 56

11 years ago
The part responsible for the failure is the change in moz_gtk_get_dropdown_arrow_size(gint* width, gint* height)

I tend to think that this change just revealed a bug elsewhere... What should we do ?
(Assignee)

Comment 57

11 years ago
If I hardcode the size of the dropdown button to 100, I get a 76 pixels offset (276 instead of 200). I think that the window creating code doesn't correctly take the chrome size into account. The interesting thing is that changing the gtk theme can make this test fail without this patch applied.

Should this bug be held while waiting for a solution to that other bug ?
(Assignee)

Comment 58

11 years ago
I was wrong, for common themes changing the theme doesn't make the test fail. The toolbars probably have a minimum height, and it's from a certain size of the toolbar widgets that the chrome begins to be too tall.
Is the dropdown button being hidden dynamically? That could explain it. We start by computing an outer window height based on the inner window height plus chrome height. If the chrome height then decreases, the inner window is then too big.
(Assignee)

Comment 60

11 years ago
You mean that on popup windows the urlbar has no dropdown (just an entry), but that it's hidden after the chrome height is calculated ?
That's my hypothesis. Someone needs to check it :-)
(Assignee)

Updated

11 years ago
Depends on: 419990
(Assignee)

Comment 62

11 years ago
Checked, and corrected (if the patch is good). It's bug 419990.
Keywords: checkin-needed
Checking in browser/themes/gnomestripe/browser/browser.css;
/cvsroot/mozilla/browser/themes/gnomestripe/browser/browser.css,v  <--  browser.css
new revision: 1.200; previous revision: 1.199
done
Checking in widget/src/gtk2/gtk2drawing.c;
/cvsroot/mozilla/widget/src/gtk2/gtk2drawing.c,v  <--  gtk2drawing.c
new revision: 1.88; previous revision: 1.87
done
Checking in widget/src/gtk2/nsNativeThemeGTK.cpp;
/cvsroot/mozilla/widget/src/gtk2/nsNativeThemeGTK.cpp,v  <--  nsNativeThemeGTK.cpp
new revision: 1.149; previous revision: 1.148
done
Status: REOPENED → RESOLVED
Last Resolved: 11 years ago11 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: mozilla1.9beta4 → mozilla1.9beta5

Updated

11 years ago
Depends on: 426498
You need to log in before you can comment on or make changes to this bug.