Last Comment Bug 274626 - Disabled form controls (buttons, inputs) don't show title tooltip attribute
: Disabled form controls (buttons, inputs) don't show title tooltip attribute
Status: RESOLVED FIXED
: testcase
Product: Core
Classification: Components
Component: Event Handling (show other bugs)
: Trunk
: All All
: -- normal with 19 votes (vote)
: mozilla8
Assigned To: Brian R. Bondy [:bbondy]
:
Mentors:
: 327123 400749 401197 407766 436770 555184 583984 (view as bug list)
Depends on: 329509 218093 234455 725570
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-14 11:53 PST by Nathan Bird
Modified: 2012-02-09 04:42 PST (History)
30 users (show)
mounir: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
some buttons that are disabled and not to show the behavior (518 bytes, text/html)
2004-12-14 11:54 PST, Nathan Bird
no flags Details
Various HTML widgets none showing tooltips on disabled (2.01 KB, text/html)
2011-06-22 18:52 PDT, Brian R. Bondy [:bbondy]
no flags Details
Fix for tooltips showing on disabled HTML items (14.69 KB, patch)
2011-06-22 19:12 PDT, Brian R. Bondy [:bbondy]
bugs: review+
Details | Diff | Splinter Review
My argument for allowing click events (80 bytes, text/html)
2011-06-24 03:52 PDT, neil@parkwaycc.co.uk
no flags Details
Fix for tooltips showing on disabled HTML items with formatting fixes (14.48 KB, patch)
2011-06-28 08:42 PDT, Brian R. Bondy [:bbondy]
no flags Details | Diff | Splinter Review
Fix for tooltips showing on disabled HTML items with changes matching method name (14.47 KB, patch)
2011-06-28 09:13 PDT, Brian R. Bondy [:bbondy]
bugs: review+
mounir: checkin+
Details | Diff | Splinter Review

Description Nathan Bird 2004-12-14 11:53:01 PST
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/0.9.1+ StumbleUpon/1.995
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/0.9.1+ StumbleUpon/1.995

When you mouseover a disabled button, it does not show the title information.
This would be very good to show to give information as to WHY the element is
disabled.

http://www.w3.org/TR/REC-html40/interact/forms.html#adef-disabled  is the spec I
could find defining what should be done when the disabled attribute is set. "How
disabled elements are rendered depends on the user agent. For example, some user
agents "gray out" disabled menu items, button labels, etc."

Note: XUL buttons already display this behavior... is this page done loading?
mouseover the stop button it will show tooltip. This bug
https://bugzilla.mozilla.org/show_bug.cgi?id=245264 is saying that the tooltips
aren't specific enough when disabled. This is not my problem as I am changing
tooltips and disabled at the same time.

Reproducible: Always

Steps to Reproduce:
1. Make a button that is disabled that has a title attribute.
2. Mouseover the button

Actual Results:  
Nothing

Expected Results:  
It should so the title attribute in the tooltip

I know it doesn't work in Firefox, and have had other people tell me the
behavior is the same in Galeon and Mozilla.
Comment 1 Nathan Bird 2004-12-14 11:54:15 PST
Created attachment 168714 [details]
some buttons that are disabled and not to show the behavior
Comment 2 Boris Zbarsky [:bz] 2005-01-17 20:22:42 PST
I'm pretty sure this is not handled in the layout engine (Neil, is that right?),
and also pretty sure that this is done on purpose...
Comment 3 neil@parkwaycc.co.uk 2005-01-18 01:21:02 PST
(In reply to comment #2)
>pretty sure that this is done on purpose...
No, it's a bug in the event system, see bug 218093 and bug 163269. As a
workaround try wrapping the element in a span and setting the title on that.
Comment 4 neil@parkwaycc.co.uk 2005-01-18 01:22:23 PST
(In reply to comment #3)
>try wrapping the element in a span and setting the title on that.
Sorry, I wasn't thinking; that won't work either.
Comment 5 Gabriel Sjoberg 2005-09-07 12:02:14 PDT
Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8b4) Gecko/20050906
Firefox/1.4 ID:2005090605

This behavior persists in the above nightly.  Confirming and moving to
Core/Event System per comments 2 and 3.  I don't personally think this is a bug,
but we'll let the devs decide.
Comment 6 Keith Lynch 2005-11-15 11:20:45 PST
I would disagree entirely. This is a bug. It is useful to provide the user with feedback as to why a button is disabled. Also this is the behaviour in "other" browswer and it would be good to have it for consistency.
Comment 7 Steve England [:stevee] 2007-06-04 04:57:12 PDT
*** Bug 327123 has been marked as a duplicate of this bug. ***
Comment 8 Steve England [:stevee] 2007-10-26 03:37:13 PDT
*** Bug 401197 has been marked as a duplicate of this bug. ***
Comment 9 Steve England [:stevee] 2007-10-26 07:30:38 PDT
*** Bug 401197 has been marked as a duplicate of this bug. ***
Comment 10 Phil Ringnalda (:philor) 2007-12-10 11:21:33 PST
*** Bug 400749 has been marked as a duplicate of this bug. ***
Comment 11 Phil Ringnalda (:philor) 2007-12-10 11:22:03 PST
*** Bug 407766 has been marked as a duplicate of this bug. ***
Comment 12 Steve 2007-12-10 11:41:29 PST
For usability and user friendliness, I feel that this is definately a bug.
Comment 13 Armand Turpel 2008-04-24 01:47:02 PDT
(In reply to comment #5)
> Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8b4) Gecko/20050906
> Firefox/1.4 ID:2005090605
> 
> This behavior persists in the above nightly.  Confirming and moving to
> Core/Event System per comments 2 and 3.  I don't personally think this is a bug,
> but we'll let the devs decide.

Hi,
So what the devs have decided? I see this bug still in firefox3 beta5.

Thanks,
Armand

Comment 14 kimb 2008-05-02 14:12:06 PDT
Yep, I just found this a problem as well, logic tells me that it should still show a title tag even if it's disabled. Irritatingly it does work in IE.

SCENARIO:
I want to disable the submit button on a form unless certain fields are validated using a bit of js. The user rolls over the button and it pops up a tooltip explaining why it is disabled.

Someone pleeeez get my favourite browser to support this.

Cheers

kimb
Comment 15 Duane 2009-07-29 12:11:51 PDT
This is still a problem in Firefox 3.0.11.  Any word if the fix is even on the radar?  

Any known workarounds?
Comment 16 Duane 2009-07-30 13:09:35 PDT
I found a workaround that worked for me.
I use PHP, so when the visitor is using FireFox, I made the button not disabled, but gave it a class that makes it appear disabled -- even when pressed and hovered.

-------------------------
Here's the HTML:
-------------------------

<input type='button' class='buttons disabled' value='Click Me' title="Please first agree to the Service Agreement" onclick="ProcessForm();" />

-------------------------
And the CSS:
-------------------------

form input.buttons[disabled], form input.buttons[disabled]:hover, form input.disabled, form input.disabled[active]{
	color: #DDDDDD;
	background-color: #555555; 
	
	/*this stuff is only because of Firefox not showing titles for disabled items */
	border-style: outset;
	margin: 0px 6px 0px 0px;
	padding: 0px 6px;
}

-------------------------

However, I hope this bug is still fixed because it works properly in IE and Chrome, but we know that FireFox is the best :)
Comment 17 David Viner 2009-11-03 03:53:38 PST
It is not only buttons that don't show tooltips when they are disabled, input text fields do so as well. This is definitely a bug - all other browsers do this properly (yeah, even IE!). Please fix this ASAP - it has been a known bug for far too long.
Comment 18 drhowarddrfine 2010-01-09 13:00:02 PST
I'm not so sure it is a bug but an interpretation of the docs that state disabled inputs don't receive focus. I don't know if that would include hovering over the element. Just because other browsers do it that way doesn't make it a bug.
Comment 19 Ryan Alberts 2010-01-09 19:30:00 PST
I agree that the documentation states that disabled inputs don't receive focus.  Though, receiving focus is very different from hovering your mouse over the component to get the tooltip.  My guess is that other browsers have interpreted it that way as well since the tooltip is still displayed.  

Just my $0.02.
Comment 20 Kristian Luck 2010-01-09 20:05:45 PST
I also agree that tooltips being displayed by a browser for a given input is very different than the input having focus. If you're focused on a text field and hover your mouse pointer over a different input, focus will not shift to the other input, but its tooltip will appear.
Comment 21 stauv 2010-01-25 16:29:48 PST
I agree that this is a bug. It needs to be fixed for firefox as it works in IE.
Comment 22 arcadius 2010-03-29 03:47:39 PDT
*** Bug 555184 has been marked as a duplicate of this bug. ***
Comment 23 (mostly gone) XtC4UaLL [:xtc4uall] 2010-08-03 18:19:28 PDT
*** Bug 436770 has been marked as a duplicate of this bug. ***
Comment 24 (mostly gone) XtC4UaLL [:xtc4uall] 2010-08-03 18:19:37 PDT
*** Bug 583984 has been marked as a duplicate of this bug. ***
Comment 25 Mounir Lamouri (:mounir) 2011-01-21 06:32:24 PST
Opera, Safari, Chrome and IE (according to comment 21) have this working. Maybe we should too :)
Comment 26 Olli Pettay [:smaug] (vacation Aug 25-28) 2011-01-21 06:59:59 PST
See the bugs this one depends on.
Comment 27 fricke 2011-04-05 02:38:11 PDT
For me it is a bug, too. 

It would be nice to show the user why an input field is disabled.
Comment 28 Brian R. Bondy [:bbondy] 2011-06-22 18:52:47 PDT
Created attachment 541257 [details]
Various HTML widgets none showing tooltips on disabled

Added HTML tests for the major form elements that have the problem:
input textboxes, input buttons, input checkboxes, html buttons, textarea, select, and fieldsets.
Comment 29 Brian R. Bondy [:bbondy] 2011-06-22 19:12:28 PDT
Created attachment 541260 [details] [diff] [review]
Fix for tooltips showing on disabled HTML items

How it should work:
-------------------
- Regarding disabled HTML items and tooltips:
  The way it should work is that disabled items should have tooltips (to display reasoning of why it is disabled for example)
  The way I just described is how it works in IE, Chrome/Safari, Opera
  The way it used to work before the fix in Firefox (for as far back as I could find) is that disabled HTML elements would not show tooltips.
  The way it works after the fix in Firefox is the same as how it works in IE, Chrome/Safari, Opera

Development notes:
------------------
The problem was that PreHandleEvent was suppressing the NS_MOUSE_MOVE events which are used by a tooltip listener to display tooltips.  The problem was present in the following items: input textboxes, input buttons, input checkboxes, html buttons, textarea, select, and fieldsets.

Other notes:
------------
- Ran the fix through content/base and content/html and toolkit/content tests and they pass (including the test introduced in this patch). Tested on win7x64.
- I could not find a way to detect if a title attribute's tooltip is shown in HTML via automated mochitest so what I did was add an automated mochitest to make sure it handles the mouse move events for each form element.  In the failing FF versions (FF5 and below) this test fails, in the patched version, this test passes.
- This fix also fixes Bug 595161 in full (since XUL textboxes use an HTML:input) and Bug 559176 in part (since that bug also covers click events which work different for disabled items by design in XUL and HTML).
Comment 30 Brian R. Bondy [:bbondy] 2011-06-22 19:14:52 PDT
Forgot to mention, but you will see from code review, that this patch also refactors some previous duplicated code across different HTML elements into a common function.
Comment 31 neil@parkwaycc.co.uk 2011-06-23 14:16:36 PDT
I don't claim to be an expert on form control event handling but by a cursory glance at nsHTMLInputElement.cpp my preference would be for the IsDisabled() check to be moved into the calculation for outerActivateEvent i.e.

PRBool outerActivateEvent =
  !IsDisabled() &&
  (NS_IS_MOUSE_LEFT_CLICK(aVisitor.mEvent) ||
   (aVisitor.mEvent->message == NS_UI_ACTIVATE &&
    !GET_BOOLBIT(mBitField, BF_IN_INTERNAL_ACTIVATE)));
Comment 32 Brian R. Bondy [:bbondy] 2011-06-23 18:42:30 PDT
Thanks for the feedback Neil.  I'll try this and submit a new patch.
Comment 33 Brian R. Bondy [:bbondy] 2011-06-23 20:03:13 PDT
I tried to remove the disabled check and instead set outerActivateEvent as you mentioned.  
This will show the tooltip as expected but will also handle click events still, which it shouldn't.

I also tried aVisitor.mDOMEvent->StopPropagation(); in the PostHandleEvent for mouse down but this doesn't help.  
For clicking it will show the event message box even before it hits PostHandleEvent as expected.

Perhaps I could allow all events except a specific list like click events from PreHandleEvent, instead of only allowing mouse move.
Bug 218093 is another similar bug that this approach would fix.

Any more suggestions are welcome, please let me know how I should proceed.
Comment 34 neil@parkwaycc.co.uk 2011-06-24 03:52:16 PDT
Created attachment 541653 [details]
My argument for allowing click events

(In reply to comment #33)
> This will show the tooltip as expected but will also handle click events
> still, which it shouldn't.
In IE, clicking the disabled input alerts. Don't know about Chrome/Safari.
Comment 35 Brian R. Bondy [:bbondy] 2011-06-24 03:55:22 PDT
using onclick="alert('click event');" on all HTML elements in IE, Chrome, Safari and Opera do not alert.

I'm using IE9 by the way and latest of the others as well.
Comment 36 Brian R. Bondy [:bbondy] 2011-06-24 04:03:26 PDT
Sorry just seen your attachment, ya it is strange :)
I'm using the attachment 541257 [details] for my tests.

In the below link it shows disabled all by itself, but I do not know what is correct/incorrect usage of the disabled attribute.
http://www.w3.org/TR/html5/forms.html#attr-fieldset-disabled
Comment 37 Brian R. Bondy [:bbondy] 2011-06-24 04:10:24 PDT
I found a better reference here:
http://www.w3.org/TR/html401/interact/forms.html#h-17.12.1

> In this example, the INPUT element is disabled. Therefore, it cannot receive user input nor will its value be submitted with the form.
>   <INPUT disabled name="fred" value="stone">

And then this shows the differences from HTML4
http://www.w3.org/TR/html5-diff/
Comment 38 Brian R. Bondy [:bbondy] 2011-06-24 04:12:07 PDT
I found a better reference here:
http://www.w3.org/TR/html401/interact/forms.html#h-17.12.1

> In this example, the INPUT element is disabled. Therefore, it cannot receive user input nor will its value be submitted with the form.
>   <INPUT disabled name="fred" value="stone">
Comment 39 Boris Zbarsky [:bz] 2011-06-24 07:34:45 PDT
> I'm using the attachment 541257 [details] for my tests.

Looks like IE dispatches the event but doesn't fire the input's listeners?

As for usage, the "disabled" attribute is a boolean attribute.  If it's set, to any value at all (and just saying <input disabled> sets it to the empty string) then the input is disabled.
Comment 40 Brian R. Bondy [:bbondy] 2011-06-24 07:50:37 PDT
Seems that way.  Ya I realized that about the disabled attribute after. 

The problem seems to date back to mid 2007 with Bug 329509.
Comment 41 Olli Pettay [:smaug] (vacation Aug 25-28) 2011-06-26 13:26:37 PDT
The problem is way older ;)
Comment 42 Olli Pettay [:smaug] (vacation Aug 25-28) 2011-06-27 11:16:05 PDT
Comment on attachment 541260 [details] [diff] [review]
Fix for tooltips showing on disabled HTML items


> 
>+PRBool 
>+nsGenericHTMLFormElement::IsMessageAllowedPreHandle(PRUint32 message, 
>+                                                    nsIFrame* frame)
Message?
Perhaps IsElementDisabledForEvents(aMessage, aFrame)
Note, parameter should start with lowercase 'a'



>+{
>+  // Do not process any DOM events if the element is disabled
>+  // XXXsmaug This is not the right thing to do. But what is?
>+  if(IsDisabled())
>+    return message == NS_MOUSE_MOVE;
if (expr) {
  stmt;
}


Maybe 

PRBool disabled = IsDisable();
if (!disabled && frame) {
  const nsStyleUserInterface* uiStyle = frame->GetStyleUserInterface();
  disabled = uiStyle->mUserInput == NS_STYLE_USER_INPUT_NONE ||
             uiStyle->mUserInput == NS_STYLE_USER_INPUT_DISABLED;
    
  }
}

return !disabled || message == NS_MOUSE_MOVE;

(this isn't still perfect since I think we want to add more event types here, and perhaps
disable only trusted events, but all that could be done in followup bugs.)



>+  // Returns false if the message should not be handled from PreHandleEvent
>+  virtual PRBool IsMessageAllowedPreHandle(PRUint32 message, nsIFrame* frame);
Why is this virtual


> nsHTMLButtonElement::PreHandleEvent(nsEventChainPreVisitor& aVisitor)
> {
>-  // Do not process any DOM events if the element is disabled
>+  nsIFormControlFrame* formControlFrame = GetFormControlFrame(PR_FALSE);
>+  nsIFrame* formFrame = NULL;
>+  if (formControlFrame)
>+    formFrame = do_QueryFrame(formControlFrame);
if (expr) {
  stmt;
}

> nsHTMLSelectElement::PreHandleEvent(nsEventChainPreVisitor& aVisitor)
> {
>+  nsIFormControlFrame* formControlFrame = GetFormControlFrame(PR_FALSE);
>+  nsIFrame* formFrame = NULL;
nsnull

>+  if (formControlFrame)
>+    formFrame = do_QueryFrame(formControlFrame);
if (expr) {
  stmt;
}

>+    // Mouse move events are what causes tooltips to show up. 
>+    // Before this fix we would not allow mouse move events to go through
>+    // which in turn did not allow tooltips to be displayed.
>+    // This test will ensure that all HTML elments hanlde mouse move events
handle


Would be great to get some tests for tooltips. We should have some tests for those,
perhaps you could just add tests for disabled form elements to those tests.
Comment 43 Brian R. Bondy [:bbondy] 2011-06-27 21:11:17 PDT
Thanks for the review and help with formatting.  
I'm away for a few days but will submit a new patch as soon as I get a chance.

Regarding the virtual, it was just because I thought the derived types should be able to override it, and when a base type holds a derived type it should call the correct function.

Regarding the nsnull, is this for consistency? On the style guide:
https://developer.mozilla.org/En/Developer_Guide/Coding_Style 
> In new code, use NULL for pointers. In old code, using nsnull or 0 for consistency is allowed.
Comment 44 Brian R. Bondy [:bbondy] 2011-06-28 08:42:17 PDT
Created attachment 542486 [details] [diff] [review]
Fix for tooltips showing on disabled HTML items with formatting fixes

I attached a new patch with the changes you mentioned. Please advise if I missed anything else.

Regarding the nsnull:
I see that every other instance in that file is nsnull so I put it as you said for consistency.

Regarding the extra tooltip tests:
Are you envisioning XUL tooltip tests?  Perhaps in test_tooltip.xul which is inside toolkit\content\tests\widgets?
If not, do you know of any HTML DOM events for tooltips? I could not find any HTML related events.

Thanks again for the guidance on this bug.
Comment 45 Olli Pettay [:smaug] (vacation Aug 25-28) 2011-06-28 08:52:19 PDT
(In reply to comment #44)
> Regarding the extra tooltip tests:
> Are you envisioning XUL tooltip tests?  Perhaps in test_tooltip.xul which is
> inside toolkit\content\tests\widgets?
Yeah, sounds right.
Comment 46 Olli Pettay [:smaug] (vacation Aug 25-28) 2011-06-28 08:58:02 PDT
Comment on attachment 542486 [details] [diff] [review]
Fix for tooltips showing on disabled HTML items with formatting fixes

>+PRBool 
>+nsGenericHTMLFormElement::IsElementDisabledForEvents(PRUint32 aMessage, 
>+                                                    nsIFrame* aFrame)
>+{
>+  PRBool disabled = IsDisabled();
>+  if (!disabled && aFrame) {
>+    const nsStyleUserInterface* uiStyle = aFrame->GetStyleUserInterface();
>+    disabled = uiStyle->mUserInput == NS_STYLE_USER_INPUT_NONE ||
>+      uiStyle->mUserInput == NS_STYLE_USER_INPUT_DISABLED;
>+
>+  }
>+  return !disabled || aMessage == NS_MOUSE_MOVE;
>+}
Oops, sorry, my mistake. This should return true if element is disabled for events.
return disabled && aMessage != NS_MOUSE_MOVE
Update the comment in .h and remove ! when this method is called.
Comment 47 Brian R. Bondy [:bbondy] 2011-06-28 09:13:19 PDT
Created attachment 542496 [details] [diff] [review]
Fix for tooltips showing on disabled HTML items with changes matching method name

Oops didn't notice that method was doing opposite of the name, code is updated to match method name logic now.
Comment 48 Olli Pettay [:smaug] (vacation Aug 25-28) 2011-06-28 09:30:51 PDT
Comment on attachment 542496 [details] [diff] [review]
Fix for tooltips showing on disabled HTML items with changes matching method name

Could you file a followup bug about mouseover and mouseout handling.
Comment 49 Brian R. Bondy [:bbondy] 2011-06-28 18:17:21 PDT
Bug 218093 already exists which covering disabled mouseout/mouseover handling, and I just took that bug.

I will implement the tooltip XUL tests inside Bug 595161 which I also have assigned to me.

I think this bug needs to be marked as needs commit if there's nothing else needed here.  Please advise.
Comment 50 Olli Pettay [:smaug] (vacation Aug 25-28) 2011-06-29 03:53:08 PDT
Just add checking-needed keyword, or checkin? to the patch.
Comment 51 Mounir Lamouri (:mounir) 2011-07-18 12:24:15 PDT
Pushed to try. I will push to mozilla-inbound after if it's green.
Comment 52 Brian R. Bondy [:bbondy] 2011-07-18 12:25:22 PDT
Thanks I should have try access soon myself.
Comment 53 Mounir Lamouri (:mounir) 2011-07-18 16:23:25 PDT
Comment on attachment 542496 [details] [diff] [review]
Fix for tooltips showing on disabled HTML items with changes matching method name

Pushed to mozilla-inbound.
Comment 54 Marco Bonardo [::mak] 2011-07-19 08:14:45 PDT
http://hg.mozilla.org/mozilla-central/rev/ea5865c2e9b7
Comment 55 fricke 2012-02-09 00:20:45 PST
The fix for this is already integrated in the current FF version, isn't it?
Comment 56 Brian R. Bondy [:bbondy] 2012-02-09 04:42:25 PST
Yes it should be.

Note You need to log in before you can comment on or make changes to this bug.