Beginning on October 25th, 2016, Persona will no longer be an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 218093 - disabled child element doesn't produce mouseout/mouseover pair
: disabled child element doesn't produce mouseout/mouseover pair
: dev-doc-complete, site-compat
Product: Core
Classification: Components
Component: DOM: Events (show other bugs)
: Trunk
: x86 Windows XP
: -- normal with 9 votes (vote)
: mozilla44
Assigned To: Boris Zbarsky [:bz] (still a bit busy)
: Andrew Overholt [:overholt]
: 190876 507096 530342 (view as bug list)
Depends on: 329509 127903 234455
Blocks: 968240 100085 190876 202806 274626 297979 366517 497805
  Show dependency treegraph
Reported: 2003-09-02 10:12 PDT by Andrew Owseiko
Modified: 2016-04-23 21:09 PDT (History)
27 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

mouseover/mouseout Testcase (1.69 KB, text/html)
2003-09-02 23:36 PDT, Andrew Owseiko
no flags Details
Disabled fields disregard for parentNode events (3.66 KB, text/html)
2005-09-27 11:37 PDT, Matthew Schultz
no flags Details
example (821 bytes, text/html)
2009-07-29 02:27 PDT, bugzilla33
no flags Details
Seems like this should work for mouseout/mouseover (1.12 KB, patch)
2015-10-14 16:04 PDT, Boris Zbarsky [:bz] (still a bit busy)
bugs: feedback+
Details | Diff | Splinter Review
Whitelist more mouse movement events to apply to disabled form controls (1.61 KB, patch)
2015-10-15 10:48 PDT, Boris Zbarsky [:bz] (still a bit busy)
bugs: review+
Details | Diff | Splinter Review

Description Andrew Owseiko 2003-09-02 10:12:38 PDT
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

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
Comment 1 Andrew Owseiko 2003-09-02 23:36:24 PDT
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.
Comment 2 Boris Zbarsky [:bz] (still a bit busy) 2004-08-06 11:21:28 PDT
See code at
and so forth.

Once we fix event dispatch to not be recursive this problem should go away...
Comment 3 2004-08-06 11:41:28 PDT
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?
Comment 4 2004-08-09 07:26:30 PDT
(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?
Comment 5 Gervase Markham [:gerv] 2005-09-27 02:03:33 PDT
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:
Comment 6 Kathleen Brade 2005-09-27 05:59:49 PDT
Confirming based on bz's comment 2 (bz, is this still a problem?)
Comment 7 Matthew Schultz 2005-09-27 10:35:19 PDT
Bug 190876 Dup of this bug?
Comment 8 Matthew Schultz 2005-09-27 11:00:42 PDT
I can confirm that this is still a bug in build 20050910 (Seamonkey 1.0a) and
20050908 (Firefox 1.5 Beta).  
Comment 9 Matthew Schultz 2005-09-27 11:37:34 PDT
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 Matthew Schultz 2005-09-27 11:43:12 PDT
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
Comment 11 Boris Zbarsky [:bz] (still a bit busy) 2005-09-27 11:45:37 PDT
There is no such thing as a "parentNode event" in the DOM.
Comment 12 Matthew Schultz 2005-09-27 15:19:26 PDT
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?
Comment 13 Boris Zbarsky [:bz] (still a bit busy) 2005-09-27 19:38:24 PDT
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 Matthew Schultz 2005-09-27 23:18:37 PDT
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.
Comment 15 Boris Zbarsky [:bz] (still a bit busy) 2005-09-28 05:44:39 PDT
Ah, I see.  You mean onclick doesn't work.  Everything else in that testcase is
based on mouseover/out.
Comment 16 Matthew Schultz 2005-09-28 08:17:39 PDT
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. 
Comment 17 James Wagoner 2007-03-02 14:32:21 PST
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>
Comment 18 Boris Zbarsky [:bz] (still a bit busy) 2007-03-02 14:35:51 PST
> 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....
Comment 19 Jan Honza Odvarko [:Honza] 2008-06-09 06:33:55 PDT
This bug makes trouble when using DOM Inspector in Firebug (Firebug uses the "mouseover" event to find out the element under the mouse).


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?

Comment 20 Nochum Sossonko [:Natch] 2009-01-28 11:43:42 PST
*** Bug 190876 has been marked as a duplicate of this bug. ***
Comment 21 Rob Campbell [:rc] (:robcee) 2009-07-24 10:17:02 PDT
still a bug. Still causing problems for the inspector in Firebug.

Also applies to mousemove events.
Comment 22 Mardeg 2009-07-29 01:15:32 PDT
*** Bug 507096 has been marked as a duplicate of this bug. ***
Comment 23 bugzilla33 2009-07-29 02:27:46 PDT
Created attachment 391303 [details]
Comment 24 bugzilla33 2009-07-29 03:07:17 PDT
disabled child element doesn't produce also event: mousedown
see example above
Comment 25 2009-07-29 03:50:08 PDT
IE6 behaviour is to inhibit event handlers only on the disabled element itself.
Comment 26 Michael Ratcliffe [:miker] [:mratcliffe] 2009-11-17 13:19:24 PST
Still no mouseover event thrown by disabled elements so this is still preventing Firebug from being able to inspect disabled elements.
Comment 27 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2009-11-22 09:07:50 PST
*** Bug 530342 has been marked as a duplicate of this bug. ***
Comment 28 John J. Barton 2009-12-28 18:12:21 PST
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.
Comment 29 Oleg 2015-09-14 10:08:58 PDT
This issue is regular guest on jQuery tracker -

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

Comment 30 Boris Zbarsky [:bz] (still a bit busy) 2015-09-15 14:28:23 PDT
Olli, is there a reason nowadays for this behavior?
Comment 31 Olli Pettay [:smaug] 2015-09-15 14:41:19 PDT
No one has figured out which all events should fire on disabled form controls :/

But this one certainly should work.
Comment 32 Oleg 2015-09-18 09:08:25 PDT
So is there any chance it might be fixed in the near future?
Comment 33 Olli Pettay [:smaug] 2015-09-18 09:17:42 PDT
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 Oleg 2015-09-21 09:11:42 PDT
Unfortunately, i'm not that kind of developer :-(. Nevertheless, thank you Olli!
Comment 35 Boris Zbarsky [:bz] (still a bit busy) 2015-10-14 16:04:00 PDT
Created attachment 8673968 [details] [diff] [review]
Seems like this should work for mouseout/mouseover
Comment 36 Olli Pettay [:smaug] 2015-10-14 16:35:30 PDT
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 37 Olli Pettay [:smaug] 2015-10-15 07:54:21 PDT
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)
Comment 38 Boris Zbarsky [:bz] (still a bit busy) 2015-10-15 10:48:50 PDT
Created attachment 8674373 [details] [diff] [review]
Whitelist more mouse movement events to apply to disabled form controls
Comment 40 Phil Ringnalda (:philor) 2015-10-17 10:22:35 PDT
Comment 41 Sebastian Zartner [:sebo] 2015-10-29 15:16:19 PDT
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?

Comment 42 Boris Zbarsky [:bz] (still a bit busy) 2015-10-29 16:21:44 PDT
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.
Comment 43 Sebastian Zartner [:sebo] 2015-10-30 00:09:16 PDT
Ok, I created bug 1220048. I guess I should also ask in the public-html mailing list about that, right?

Comment 44 Oleg 2015-11-04 09:04:18 PST
Thank you for the fix!
Comment 45 Sebastian Zartner [:sebo] 2016-01-03 08:33:46 PST
(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

I've also documented this change here:

Comment 47 Kohei Yoshino [:kohei] 2016-04-23 21:09:44 PDT
Learned this bug in Bug 1265909. Posted the site compatibility doc:

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