Closed Bug 274626 Opened 20 years ago Closed 13 years ago

Disabled form controls (buttons, inputs) don't show title tooltip attribute

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla8

People

(Reporter: birdman, Assigned: bbondy)

References

Details

(Keywords: testcase)

Attachments

(4 files, 2 obsolete files)

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.
OS: Windows XP → All
Hardware: PC → All
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...
(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.
Depends on: 234455
(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.
Depends on: 218093
Keywords: testcase
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.
Assignee: nobody → events
Status: UNCONFIRMED → NEW
Component: Layout → Event Handling
Ever confirmed: true
QA Contact: layout → ian
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.
Summary: Disabled buttons don't show title tooltip attribute → Disabled form controls (buttons, inputs) don't show title tooltip attribute
For usability and user friendliness, I feel that this is definately a bug.
(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

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
This is still a problem in Firefox 3.0.11.  Any word if the fix is even on the radar?  

Any known workarounds?
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 :)
Assignee: events → nobody
QA Contact: ian → events
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.
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.
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.
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.
I agree that this is a bug. It needs to be fixed for firefox as it works in IE.
Opera, Safari, Chrome and IE (according to comment 21) have this working. Maybe we should too :)
See the bugs this one depends on.
For me it is a bug, too. 

It would be nice to show the user why an input field is disabled.
Assignee: nobody → netzen
Added HTML tests for the major form elements that have the problem:
input textboxes, input buttons, input checkboxes, html buttons, textarea, select, and fieldsets.
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).
Attachment #541260 - Flags: review?(Olli.Pettay)
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.
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)));
Thanks for the feedback Neil.  I'll try this and submit a new patch.
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.
(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.
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.
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
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/
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">
> 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.
Seems that way.  Ya I realized that about the disabled attribute after. 

The problem seems to date back to mid 2007 with Bug 329509.
The problem is way older ;)
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.
Attachment #541260 - Flags: review?(Olli.Pettay) → review+
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.
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.
Attachment #541260 - Attachment is obsolete: true
Attachment #542486 - Flags: review?(Olli.Pettay)
(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 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.
Attachment #542486 - Flags: review?(Olli.Pettay)
Oops didn't notice that method was doing opposite of the name, code is updated to match method name logic now.
Attachment #542486 - Attachment is obsolete: true
Attachment #542496 - Flags: review?(Olli.Pettay)
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.
Attachment #542496 - Flags: review?(Olli.Pettay) → review+
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.
Just add checking-needed keyword, or checkin? to the patch.
Attachment #542496 - Flags: checkin?(Olli.Pettay)
Attachment #542496 - Flags: checkin?(Olli.Pettay) → checkin?
Pushed to try. I will push to mozilla-inbound after if it's green.
Status: NEW → ASSIGNED
Thanks I should have try access soon myself.
Comment on attachment 542496 [details] [diff] [review]
Fix for tooltips showing on disabled HTML items with changes matching method name

Pushed to mozilla-inbound.
Attachment #542496 - Flags: checkin? → checkin+
Flags: in-testsuite+
http://hg.mozilla.org/mozilla-central/rev/ea5865c2e9b7
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla8
Depends on: 725570
The fix for this is already integrated in the current FF version, isn't it?
Yes it should be.
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.