Closed Bug 30644 Opened 25 years ago Closed 24 years ago

make 'disabled' really work for XUL widgets

Categories

(Core :: XUL, defect, P3)

Product:
Core
Component:
XUL
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: bugzilla, Assigned: hyatt)

References

Details

(Keywords: polish, Whiteboard: [nsbeta3+]) 

The gray disabled buttons that appear in Mozilla (ex. in the Sidebar Customize) 
is not really disabled.

When moving the mouse cursor over the disabled button the text gets underlined.
This should NOT be the case.

Expected:
A disabled button should be "really" disabled, meaning that both when moving the 
mouse over the button and pressing the button should do NOTHING!
I don't mind the underlining, but you can e.g. dismiss the customize sidebar
window by clicking on the greyed out "save" button (it is greyed out until you
change something).
_A greyed out button should never lead to some action!_

The following diff will fix the first part of it... All the push dialog buttons.

1106a1107
>   text-decoration: none;
1114a1116
>   text-decoration: none;
1123a1126
>   text-decoration: none;
Assignee: pierre → hyatt
...
Assignee: hyatt → ben
not a priority, pushing out as far as possible.
Status: NEW → ASSIGNED
Target Milestone: --- → M20
I think this is a dup of bug 7552.

CCing Hyatt, who is the dup-meister for that bug and can tell us for certain.

not really, different time, different namespace. 

I think this bug referred to certain styles not being applied to disabled 
buttons. 
hyatt muttered something about this recently, saying he wanted to do something 
in particular with it (I offered a suggestion that I could implement, he seemed 
to have something better in mind), so resummarizing and bouncing back to him. 
teehee.
Assignee: ben → hyatt
Status: ASSIGNED → NEW
Component: Style System → XP Toolkit/Widgets
Summary: Disabled buttons is not entirely disabled → make 'disabled' really work for XUL widgets
Mass-moving all M20-M30 XPToolkit bugs to Future
Target Milestone: M20 → Future
Shouldn't this be scheduled sometime sooner?
This is 4xp and should be in release notes for any product where it isn't 
implemented.  nsbeta3 includes polish bugs.  Restoring first milestone.

Hyatt, you haven't accepted this bug yet; ben hinted that you had plans for 
this bug.  If you don't have the time to work on this bug simply describing the 
work that needs to be done here would allow it to be marked helpwanted and 
for someone else to fix it.
Keywords: 4xp, nsbeta3, polish, relnote2, rtm
Target Milestone: Future → M20
This also affects AIM. In Instant Messenger Privacy prefs, the Add Name button 
is grayed but still invokes it's add name dialog when clicked.
I assume this bug covers radio buttons and checkboxes as well.  cc myself since 
Composer is getting bitten by this bug as well.

*** Bug 40212 has been marked as a duplicate of this bug. ***
*** Bug 43006 has been marked as a duplicate of this bug. ***
Blocks: 43006
nsbeta3+ to at least prevent commands from disabled items from being executed.
Whiteboard: [nsbeta3+]
QA Contact: jrgm
Fixed. If you find specific widgets that are in violation now, please do not
reopen this bug.  File new separate bugs for any specific cases you encounter
(unless I failed to fix any of them, in which case reopening this bug is ok).
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
2000080120
Status: RESOLVED → VERIFIED
I think the "checkbox" widget is not fixed....:(
Filed bug 81180 about disabled dual menubuttons responding to mouseover.
You need to log in before you can comment on or make changes to this bug.