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
At the same time enabled control(and any other child element) generates
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
Created attachment 130805 [details]
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...
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?
(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?
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:
Confirming based on bz's comment 2 (bz, is this still a problem?)
Bug 190876 Dup of this bug?
I can confirm that this is still a bug in build 20050910 (Seamonkey 1.0a) and
20050908 (Firefox 1.5 Beta).
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.
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.
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.
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.
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.
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).
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?
*** Bug 190876 has been marked as a duplicate of this bug. ***
still a bug. Still causing problems for the inspector in Firebug.
Also applies to mousemove events.
*** Bug 507096 has been marked as a duplicate of this bug. ***
Created attachment 391303 [details]
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.
*** Bug 530342 has been marked as a duplicate of this bug. ***
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.
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?
No one has figured out which all events should fire on disabled form controls :/
But this one certainly should work.
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.
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
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)
Created attachment 8674373 [details] [diff] [review]
Whitelist more mouse movement events to apply to disabled form controls
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.
Ok, I created bug 1220048. I guess I should also ask in the public-html mailing list about that, right?
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:
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/