Closed Bug 388131 Opened 18 years ago Closed 17 years ago

No visual indication of disabled state for radios/checkboxes with some GTK themes

Categories

(Core :: Widget: Gtk, defect)

Product:
Core
Component:
Widget: Gtk
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: bzbarsky, Unassigned)

References

(
URL
)

Details

(Keywords: regression, relnote)

Attachments

(3 files, 1 obsolete file)

Tests
7.81 KB, patch
Details | Diff | Splinter Review
The right image
41.93 KB, image/png
Details
Use different GTK functions
1.20 KB, patch
Details | Diff | Splinter Review
The URL in the URL field should show one each enabled and disabled radio and checkbox. The two states look identical... Regression from bug 329846.
Flags: blocking1.9?
WFM in Clearlooks, but they did a terrible job. The disabled one is only slightly lighter than the active one.
I have no idea what theme I'm using (whatever FC4 GNOME defaults to), but they look exactly identical over here, as far as I can tell. We really don't want to ship it this way, imo.
Keywords: regression
Attached patch Tests — — Splinter Review
I'm using Kubuntu with GTK apps set to use the Clearlooks theme (the default theme in a vanilla GNOME) and the disabled radios and checkboxes are greyed out. It must be a theme issue at your end.
<shrug>. I'm pretty definitely using a vanilla GNOME, having never started GNOME as this user. All I can tell is that something that really should work for basic usability and accessibility is broken... Perhaps we need to disable native theming for certain GTK themes or theme versions, if they are commonly broken like this.
I can confirm that XUL has the same problem, by the way, so this is not really HTML-specific, as expected.
Can you attach a screenshot including the problem (and maybe some other form elements too so I can maybe guess what your theme is?)
Attached image Screenshot (obsolete) —
In each pair of checkboxes/radios, one is enabled, one is disabled. If I can poke through dotfiles or some such to get you the info on the theme, please let me know. I'm happy to do that.
(In reply to comment #8) > Created an attachment (id=272293) [details] > Screenshot > > In each pair of checkboxes/radios, one is enabled, one is disabled. > > If I can poke through dotfiles or some such to get you the info on the theme, > please let me know. I'm happy to do that. > I'm only seeing a green square.
Attached image The right image —
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Assignee: bzbarsky → nobody
Status: ASSIGNED → NEW
Attachment #272293 - Attachment is obsolete: true
One question, does your theme display disabled textboxes correctly? If so, this patch might help since it makes changes to use a similar function.
Disabled textboxes display just fine, as do disabled <select>s. I tried the patch, and it doesn't seem to help. :(
The only way I can explain it is that your theme hasn't implemented a look for disabled checkboxes and radios. Every theme I have on my computer seems to work.
I just tried all themes that Ubuntu 7.04 ships with. Using the current nightly, the problem occurs with "Dunst" and "Gray".
I'm not saying it's not a theme problem. I'm saying that users don't really care about it being a theme problem (heck, even I don't). Perhaps we need a GTK theme blacklist (or some sort of smarter setup if possible) to be used in ThemeSupportsWidget to not claim to support things we don't actually support.
mwu, do you have any idea whether what I propose in comment 15 or some other decent approach is implementable?
This shouldn't really block release, especially since this bug isn't our fault.
It doesn't matter whose "fault" it is, really. We made a code change that causes an accessibility regression. When we make code changes that break, say, Flash, it doesn't matter that much whether they're not implementing the NPAPI correctly: we suck it up and make it work again. This isn't really different. At the very least we need to have a way to put this under user preference control, if we're not going to actually fix the problem.
see also bug 204310
(In reply to comment #18) > It doesn't matter whose "fault" it is, really. We made a code change that > causes an accessibility regression. When we make code changes that break, say, > Flash, it doesn't matter that much whether they're not implementing the NPAPI > correctly: we suck it up and make it work again. This isn't really different. > > At the very least we need to have a way to put this under user preference > control, if we're not going to actually fix the problem. > I should've asked this before, do disabled checkboxes look disabled in other GTK apps such as GIMP? If not, its a theme problem, but if so I'll bang my head against the desk for I would have no idea how to fix this especially since I can't reproduce this. I just think that the lackings of certain themes should definitely not be blocking 1.9.
> do disabled checkboxes look disabled in other GTK apps such as GIMP? As far as I can tell, no. > I would have no idea how to fix this One thought I've had so far, if it's possible, is to compare how a disabled and enabled native checkbox/radio look. If they look the same, don't claim to support the widget (or only some of the widget states?). The comparison could be cached until; the theme changes, etc. Does that sound feasible?
(In reply to comment #21) > One thought I've had so far, if it's possible, is to compare how a disabled and > enabled native checkbox/radio look. If they look the same, don't claim to > support the widget (or only some of the widget states?). The comparison could > be cached until; the theme changes, etc. Does that sound feasible? Not really, AFAIK with GTK we can only tell it to draw a widget with a certain property (normal, active, disabled, hovered etc) and pray that the current theme engine does it right. :(
Sure. So you draw them both into offscreen surfaces and compare the resulting bitmaps...
(In reply to comment #21) > > do disabled checkboxes look disabled in other GTK apps such as GIMP? > > As far as I can tell, no. This reminds me of the issues when we switched from the XUL filepicker to the GTK one. I think I side with Michael here. Yes, Gecko got worse, but it just brought us into line with the rest of the applications on the user's desktop. If the user doesn't like that, they need to choose a new desktop or at least a new theme. I don't think it should be our responsibility to provide a better desktop experience than the one the user has chosen. Therefore I don't think this is a regression that we need to fix.
I didn't choose this desktop experience... I'm not using GNOME, and I didn't pick this theme.
Why is this bug listed as blocking 329846, and why is it listed as a regression? That bug may have drawn attention to this problem, but it didn't cause it. I've experienced this same problem in Azureus for the dialog where you can check which files you want to download; the disabled check boxes didn't look any different. Hundreds of applications shouldn't be expected to blacklist bad themes and implement custom widgets. This is a problem that Firefox should not try to work around.
> why is it listed as a regression? Because this bug is about HTML rendering, which we switched from code that works to code that sometimes works. That would usually be called a regression.
(In reply to comment #27) > > why is it listed as a regression? > > Because this bug is about HTML rendering, which we switched from code that > works to code that sometimes works. Except that the code does work, not only sometimes. But arguing about a keyword will lead to nothing. FWIW, this should be an evangelism bug. Contacting a small number of theme authors or those who are responsible for accessibility at Gnome, Ubuntu, Fedora [..] potentially requires less energy than adding a dirty hack to the Mozilla codebase and would actually fix the problem (instead of working around it) -- not only for Mozilla but for all Gtk apps.
Version: unspecified → Trunk
While contacting the theme authors is an excellent idea, I suspect that in the usual charming desktop Linux way they won't backport their fixes to anything past the most recent OS release, if that. So from my point of view as a user, it'll only help after my next OS upgrade...
At the very least we should relnote this.
Keywords: relnote
> I didn't choose this desktop experience... I'm not using GNOME, and I didn't > pick this theme. Nevertheless we are effectively a GNOME app and if you want GNOME apps to work properly, you need to chose a different theme. Yes, that sucks, but that's the current state of the Linux desktop.
s/GNOME/GTK2 if that makes it sound better.
I agree about relnoting; the options are either disable gtk native theme or not -- there's nothing that we can do to actually fix this on our end.
Flags: blocking1.9? → blocking1.9-
Well... Theming is per-widget, not all-or-nothing. So those are not in fact the only options. In any case, someone who's familiar with the gtk/gnome mess should push this upstream.
So does that make this WONTFIX/INVALID? Proposed relnote is: "Some GTK themes fail to properly render the disabled state of checkboxes and radiobuttons (see <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=388131">bug 388131</a>, resolution is to pick another theme or turn off gtk-native)"
> or turn off gtk-native We don't have a way of allowing users to do that, sadly. Otherwise I'd be there in a flash.
For what it's worth, I've added "-moz-appearance: none" to my userContent.css for all the form controls, which solves the problem for me, as well as various other issues (performance, etc).
Summary: No visual indication of disabled state for radios/checkboxes → No visual indication of disabled state for radios/checkboxes with some GTK themes
Hm, is this whole bug about some buggy GTK themes that don't implement insensitive checkbuttons? At least for the "Mist" theme ("Dunst" mentioned in comment #14) this is the case.
As far as I can tell from comment 22 and comment 33 this should either be Tech Evangelism or RESO INVALID. I'll keep the relnote for now, I think, but we appear to be doing the right thing and there's no other way to fix this without gaining some insight into what the GTK theme is and isn't capable of doing. Resolving INVALID for now, if someone wants to move this to Tech Evangelism, please feel free to open and do so.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: