disabled child element doesn't produce mouseout/mouseover pair

VERIFIED FIXED in Firefox 44



DOM: Events
14 years ago
a year ago


(Reporter: Andrew Owseiko, Assigned: bz)


(Depends on: 1 bug, Blocks: 1 bug, {dev-doc-complete, site-compat})

Windows XP
dev-doc-complete, site-compat
Dependency tree / graph

Firefox Tracking Flags

(firefox44 fixed)


(Whiteboard: [firebug-p2], URL)


(5 attachments)



14 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)

disabled form control
generates mouseout event for ancestor event target and doesn't generate
mouseover event. 
At the same time enabled control(and any other child element) generates 
mouseout/mouseover pair

Reproducible: Always

Steps to Reproduce:
1. Demonstration can be seen at http://www.geocities.com/hincubator/test.html

2. moving pointer over enabled control(Ok) produces "OUT TR->SELECT | OVER TD->TR"

3. but moving over disabled control(Problem) produces just "OUT TR->SELECT"
4. mouseover event is LOST


14 years ago
Summary: disabled child element doesn't produce mouseout/mouseover pair → disabled child element doesn't produce mouseout/mouseover pair

Comment 1

14 years ago
Created attachment 130805 [details]
mouseover/mouseout Testcase

mouseover/mouseout event listeners are attached to the second [TR] in the
Descendant [SELECT (Ok)] produces mouseout/mouseover pair, but [SELECT
(Problem)] does not.
See code at
and so forth.

Once we fix event dispatch to not be recursive this problem should go away...
Depends on: 234455

Comment 3

13 years ago
Ah, so this is why composer can't edit disabled controls either...

How would centralized event dispatch handle the case where the form control
needs to be updated before the event dispatch starts?

Would forwarding the disabled event to the superclass work around the problem?


13 years ago
Blocks: 202806

Comment 4

13 years ago
(In reply to comment #3)
>Would forwarding the disabled event to the superclass work around the problem?
This workaround solves bug 202806. Is it worth implementing this now?


13 years ago
Blocks: 274626


13 years ago
Depends on: 127903
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 6

12 years ago
Confirming based on bz's comment 2 (bz, is this still a problem?)
Ever confirmed: true

Comment 7

12 years ago
Bug 190876 Dup of this bug?


12 years ago
Blocks: 190876

Comment 8

12 years ago
I can confirm that this is still a bug in build 20050910 (Seamonkey 1.0a) and
20050908 (Firefox 1.5 Beta).  

Comment 9

12 years ago
Created attachment 197598 [details]
Disabled fields disregard for parentNode events

Adding additional testcase to also show disabled fields total disregard for
parentNode events as well as title attributes.

Comment 10

12 years ago
Might I suggest a summary change to something like this as it applies to more
than just mouseover/mouseout events?

Disabled child element doesn't inherit parentNode events
There is no such thing as a "parentNode event" in the DOM.

Comment 12

12 years ago
Sorry, I guess I'm using the wrong terminology.  Perhaps "attribute" is a better
word for it since it seems it also disables the title attribute?  

Disabled child element doesn't inherit parentNode attributes?
There are also no "parentNode attributes".  There is a parentNode property, but
your testcase doesn't use it.  So really, I don't see what attachment 197598 [details] has
to do with anything.

Comment 14

12 years ago
Testcase 197598 is supposed to show that the disabled form fields affect more
than just onmouseover and onmouseout of their parent elements (td, tr, table,
etc.) which in this case would be the tr element.  None of the attributes for
the parent element, tr, work when moused over the disabled fields.
Ah, I see.  You mean onclick doesn't work.  Everything else in that testcase is
based on mouseover/out.

Comment 16

12 years ago
As far as I can tell nothing works in the tr element when the mouse arrow is
over the disabled fields.  Insert whatever you want there, ondblclick,
onmousedown, onmouseup, title, onclick, onmouseover, onmouseout.  I tried
putting these attributes in the td, they were disabled too when the mouse arrow
was over the the disabled fields.  I even tried surrounding the disabled fields
with span tags.  The attributes in the span tags were not working as well.  
Sorry, I should have been a bit more descriptive with the testcase. 


12 years ago
Blocks: 100085, 297979

Comment 17

11 years ago
This hasn't been commented on in a long time, but this bug is still, in fact, plaguing FireFox.

The following code reproduces the error. You can mouseover the TD, and the textbox will drop it's DISABLED property. As soon as the mouse (while still in the TD) mouses over the textbox, it hits the mouseout effect of the TD, which causes the textbox to go back disabled.

Expected result: while mousing over the TD, when the mouse goes over the disabled textbox, the parent onmouseout effect should NOT be executed, the textbox should STAY enabled until the mouse has left the TD completely.

 onmouseover="document.getElementById('text').disabled = false;"
 onmouseout="document.getElementById('text').disabled = true;"
 style="padding: 5px; border: 1px solid #000000;">
<input type="text" id="text" value="disabled" disabled>
> This hasn't been commented on in a long time, but this bug is still, in fact,
> plaguing FireFox.

Yes.  That's why the bug is still open.  There's no need to comment if nothing has changed.

And the bug already has a testcase that shows the problem....
This bug makes trouble when using DOM Inspector in Firebug (Firebug uses the "mouseover" event to find out the element under the mouse).

See http://code.google.com/p/fbug/issues/detail?id=190

Is there any chance to push this bug forward, so we can fix it also in Firebug?
Is there any workaround that we could use in the meantime?

Assignee: saari → nobody
QA Contact: ian → events
Duplicate of this bug: 190876


8 years ago
Whiteboard: [firebug-p3]
Blocks: 366517
Blocks: 497805
still a bug. Still causing problems for the inspector in Firebug.

Also applies to mousemove events.


8 years ago
Duplicate of this bug: 507096

Comment 23

8 years ago
Created attachment 391303 [details]

Comment 24

8 years ago
disabled child element doesn't produce also event: mousedown
see example above
IE6 behaviour is to inhibit event handlers only on the disabled element itself.
Still no mouseover event thrown by disabled elements so this is still preventing Firebug from being able to inspect disabled elements.
Duplicate of this bug: 530342
Depends on: 329509


8 years ago
Whiteboard: [firebug-p3] → [firebug-p2]

Comment 28

8 years ago
Firebug implemented a workaround for mouseover, but we also need mutation events to update metadata.  I tried to set wanted-next but the UI failed.
Assignee: nobody → netzen
Assignee: netzen → nobody

Comment 29

2 years ago
This issue is regular guest on jQuery tracker - 

It would be cool if you would help us out and deal with it.

Olli, is there a reason nowadays for this behavior?
Flags: needinfo?(bugs)
No one has figured out which all events should fire on disabled form controls :/

But this one certainly should work.

Comment 32

2 years ago
So is there any chance it might be fixed in the near future?
There is. If you have spare time, feel free to provide a patch and I promise a fast code review :)

Otherwise I'll try to find some time and fix this.

Comment 34

2 years ago
Unfortunately, i'm not that kind of developer :-(. Nevertheless, thank you Olli!
Created attachment 8673968 [details] [diff] [review]
Seems like this should work for mouseout/mouseover
Attachment #8673968 - Flags: feedback?(bugs)
Oh, you got to this before me (this was next in my todo list after a session history issue).
I'll look at the patch tomorrow.
Comment on attachment 8673968 [details] [diff] [review]
Seems like this should work for mouseout/mouseover

Yes, and add also eMouseEnter and eMouseLeave
and ePointerMove, ePointerOut, ePointerOver, ePointerEnter, ePointerLeave
to be at least somewhat consistent.

(It would be possibly better to explicitly have event for which the handling is disabled, but figuring out all the cases is non-trivial)
Flags: needinfo?(bugs)
Attachment #8673968 - Flags: feedback?(bugs) → feedback+
Created attachment 8674373 [details] [diff] [review]
Whitelist more mouse movement events to apply to disabled form controls
Attachment #8674373 - Flags: review?(bugs)
Assignee: nobody → bzbarsky


2 years ago
Attachment #8674373 - Flags: review?(bugs) → review+
Blocks: 968240

Comment 39

2 years ago
Last Resolved: 2 years ago
status-firefox44: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla44
Congrats for fixing this after that long time! I can confirm that it's working now.

Did you consider to also add mousedown, mouseup and click events (see the related 'example' test case attached to this bug)? I tested this on Chrome Canary, Opera Developer and Edge right now and they trigger all three events.
Should I open a new bug for this?

I believe enabling click there would require a lot of care to make sure default actions didn't trigger.  Enabling mouseup and mousedown without click would be quite odd.

New bug is fine, but might end up as wontfix.
See Also: → bug 1220048
Ok, I created bug 1220048. I guess I should also ask in the public-html mailing list about that, right?


Comment 44

2 years ago
Thank you for the fix!
(In reply to Sebastian Zartner [:sebo] from comment #43)
> I guess I should also ask in the public-html mailing list about that, right?

For reference, I asked at http://lists.w3.org/Archives/Public/public-html/2015Oct/0010.html.

I've also documented this change here:

Keywords: dev-doc-complete
Missed some events. Updated the following pages now:


Learned this bug in Bug 1265909. Posted the site compatibility doc: https://www.fxsitecompat.com/en-CA/docs/2016/disabled-form-controls-now-trigger-mouseover-and-similar-mouse-events/
Keywords: site-compat
You need to log in before you can comment on or make changes to this bug.