Version: unspecified (using KDE 4.5.4) OS: Linux Using the latest Firefox 4.0 beta (currently 8), I see no focus indicator on checkboxes or radio buttons. This also happens in Thunderbird 3.1. Hover indicator works fine. Normal GTK apps seem okay (I checked GIMP, gnome-mplayer, and the Widget Factory). Reproducible: Always
Forgot to mention that I am using the git version of oxygen-gtk.
your talking about checkboxes in web pages ? Anyway. There are many (new) issues with firefox 4.0 (e.g: colors, scrolbar arrows, etc.) Mostly because of *their* crap (as you mentionned, it does work well with normal gtk apps). I'll postpone the fixing to when they actually have a stable release. Did I mention I hate the way firefox deals with gtk ? :)
I mean checkboxes/radios throughout the app, both in web pages and in the rest of the UI (e.g. the preference dialogs). As I mentioned, this is an issue also with Thunderbird 3.1, which uses the previous, stable version of Gecko, so I assume that Firefox 3.6 is also affected. And yes, I don't like Firefox's use of GTK either. Seems like something is always breaking. :)
I think we should encourage users to use this firefox theme instead of default one: http://kde-look.org/content/show.php/Oxygen+KDE+(Firefox+Theme)?content=117962 It has some features we can't provide via gtk engine, and is native. Dunno about Thunderbird et al. though.
I think that oxygen-gtk work really well with Firefox. We can't provide advanced features (focus glow, gradients, ...) but it's not really a problem for a normal user. >so I assume that Firefox 3.6 is also affected. Here it works... Will give a look to firefox 4.0
After some investigation, it might be because we (oxygen-gtk) don't handle focus in a very correct way. Basically we draw nothing in the "draw_focus" method, and handle focus in the main drawing method directly (here: draw_check and draw_radio). This works well for normal gtk apps because we retrieve the focus state (in the main drawing method) via gtk_widget_has_focus(). But this trick does not work for firefox. Unfortunately, it seems to me very hard to paint the focus and the widget itself in different methods, notably because it conflicts with highlight (well: prelight). I'll investigate a bit more though.
Maybe, for firefox (and possibly other 'gtk-dirty' apps), we can redo the full painting of the widget (with proper focus flag), in draw_focus. The widget will effectively be painted twice, but I don't see any other way.
Created attachment 55556 [details] expected focus rect for firefox screenshot above shows (in red) where firefox actually forces us to draw the focus. So this is obviously inconsistent with how oxygen draws focus (on the checkbox itself) and can therefore not be fixed. This is a Firefox (not at Gtk) issue. To make the situation even more messy, in some html pages the rect is actually well centered on the checkbox mark. There is no way we, as a style can deal with this mess. Closing the bug as upstream (sorry). Basically firefox makes (incorrect) assumption on how a style 'should' work, in order to make its own crap, and oxygen can't deal with that. Note that this is also true for other widgets, such as TabWidgets/Notebooks, and note also that this is very frustrating.
It's too bad there is such a mess with Firefox. :( I just checked QtCurve and it draws a focus rectangle as you indicated in your screenshot, which is definitely not ideal. Out of curiosity, you say in some HTML pages the focus rectangle is centered. I've never seen one in an HTML page where it isn't. Do you have an example? Or do you mean regular web pages vs. Firefox's dialogs? Do you know if there is an upstream bug filed already? If not, I'd like to go file one.
Wait before filing an upstream bug in fact. It might well be that the focus rect placed over the checkbox text is actually a gtk feature, which justifies that we paint the focus inside the "main" checkbox function, and not in the dedicated focus method, because that's the only place where we know the actual "button" (not text) geometry. Sad thing is that we can't do the same trick with firefox. Now the fact that gtk_widget_has_focus() does not work in firefox might really be a bug. After all, it does work well for other buttons (pushbuttons notably, in the "preference" dialog), and for which we use the same trick. So it should be possible also for checkboxes and radio buttons. I don't know whether there already is a bug on this to firefox. https://bugzilla.mozilla.org/ should be the right place (I think). Now the bug report should be quite specific. e.g. gtk_widget_has_focus does not work for checkboxes or radiobuttons, whereas it works for regular buttons, which in turn prevents some style to draw a proper focus indicator around the button itself, as opposed to its text. Something like that. Concerning checkboxes in HTML pages, when I draw the same focus rect around checkboxes on *this* page (the bug report page), this time it is drawn on the checkbox itself (like for the "remove selected ccs" checkbox above.
I have filed an upstream bug at https://bugzilla.mozilla.org/show_bug.cgi?id=622902
Looks like I accidentally filed the bug twice (wouldn't you know it, Firefox crashed when I hit submit and I thought the bug wasn't submitted, but it was). The bug number I posted above was marked as a duplicate of the first submission, which is at https://bugzilla.mozilla.org/show_bug.cgi?id=622899 Anyway, I had a look at the GTK theming in Firefox's source code last night (I was hoping to get an idea of how to fix the scrollbar issue) and it appears that the focus behavior in the dialogs is intentional. From the FF 4 beta 8 source tarball, in mozilla-cental/widget/src/gtk2/nsNativeThemeGTK.cpp at about line 282 there is a comment that says: In XUL, checkboxes and radios shouldn't have focus rings, their labels do and the focus state is explicitly set to false. I think that all the preference dialogs, etc. are XUL. I don't know if there is a way for the GTK theme to determine XUL dialogs in Mozilla apps or not. It would be nice to at least have the focus indicator be avaiable for "normal" checkboxes, i.e. those in web pages.
> Anyway, I had a look at the GTK theming in Firefox's source code last night > (I was hoping to get an idea of how to fix the scrollbar issue) and it > appears that the focus behavior in the dialogs is intentional. From the > FF 4 beta 8 source tarball, in > mozilla-cental/widget/src/gtk2/nsNativeThemeGTK.cpp at about line 282 > there is a comment that says: > > In XUL, checkboxes and radios shouldn't have focus rings, their labels do > > and the focus state is explicitly set to false. Well, thats an issue. Obviously Firefoxs / XUL HIG (human interface guidelines) simply contradicts KDE's for that matter (and our oxygen-gtk's theme follows kde's guidelines). Well ... That's too bad. > I think that all the preference dialogs, etc. are XUL. yes they are. > I don't know if > there is a way for the GTK theme to determine XUL dialogs in Mozilla apps > or not. Don't think they can. Gtk knows nothing about XUL ... > It would be nice to at least have the focus indicator be avaiable > for "normal" checkboxes, i.e. those in web pages. Agreed. Since the text is usually 'detached' from the checkboxes, and so won't get focus. That's definitely a firefox bug (or incorrect guidelines).
Another approach to solving this (not ideal fix though) is to draw underlining focus indicator like that in Oxygen-Qt which is draw in lists (and still unimplemented in Oxygen-GTK). This would at least provide user with information on what widget is focused, still looking more or less oxygenized.
(In reply to comment #14) > Another approach to solving this (not ideal fix though) is to draw underlining > focus indicator like that in Oxygen-Qt which is draw in lists (and still > unimplemented in Oxygen-GTK). This would at least provide user with information > on what widget is focused, still looking more or less oxygenized. (In reply to comment #10) > It might well be that the focus rect placed over the checkbox text is actually > a gtk feature, which justifies that we paint the focus inside the "main" > checkbox function, and not in the dedicated focus method, because that's the > only place where we know the actual "button" (not text) geometry. Is it possible, for Mozilla apps, to check whether the focus area geomtery is the same as (or within a few pixels of) the "button" geometry and draw either the standard focus indicator or underlining focus?
When i tried to draw true-oxygen focus in draw_focus(), the focus ring got drawn with wrong geometry (varying for different cases so that i couldn't find one good geometry), which looked really ugly. I'd rather just draw underlining focus everywhere (for the widgets in question) in mozilla apps.
@Ruslan I would strongly disagree with your suggestion. QtCurve does precisely what you say, and it looks rather bad in my opinion. Besides, that is not what oxygen-qt does. (notably it does not do it for "normal" dialogs, otherwise also used by firefox, like "open file" or "print page". So as far as I'm concerned, its a "no" and should be fixed at firefox level. On your concern about not drawing (on option) the focused item in lists, I have not implemented it (yet) because draw_focus is actually never called for lists (and it is hard to figure which item has focus otherwise). And that's the only place where oxygen's designers (Nuno notably) conceded (while disagreeing) to draw a focus line.
> So as far as I'm concerned, its a "no" and should be fixed at firefox level. I don't think it will ever be fixed at firefox level if it's really because of their HIG. OTOH, there *has* to be some focus indication (e.g. for the case when focus is moved from widget to widget by keyboard), thus my suggestion. > On your concern about not drawing (on option) the focused item in lists, I have > not implemented it (yet) because draw_focus is actually never called for lists Strange, it seemed to me that it is. I'll look into it.
> > On your concern about not drawing (on option) the focused item in lists, > > I have not implemented it (yet) because draw_focus is actually never > > called for lists > > Strange, it seemed to me that it is. I'll look into it. I think its on the list, not on the "cell" in the list. Maybe I remember incorrecly though.