1.69 KB, text/html
3.66 KB, text/html
821 bytes, text/html
1.12 KB, patch
|Details | Diff | Splinter Review|
1.61 KB, patch
|Details | Diff | Splinter Review|
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 (http://www.w3.org/TR/1998/REC-html40-19980424/interact/forms.html#h-17.12.1) 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
Summary: disabled child element doesn't produce mouseout/mouseover pair → disabled child element doesn't produce mouseout/mouseover pair
mouseover/mouseout event listeners are attached to the second [TR] in the [TABLE]. Descendant [SELECT (Ok)] produces mouseout/mouseover pair, but [SELECT (Problem)] does not.
See code at http://lxr.mozilla.org/seamonkey/source/content/html/content/src/nsHTMLInputElement.cpp#1232 and http://lxr.mozilla.org/seamonkey/source/content/html/content/src/nsHTMLSelectElement.cpp#1781 and so forth. Once we fix event dispatch to not be recursive this problem should go away...
Depends on: 234455
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: 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/
Confirming based on bz's comment 2 (bz, is this still a problem?)
Status: UNCONFIRMED → NEW
Ever confirmed: true
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).
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. <table> <tr> <td 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> </td> </tr> </table>
> 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? Honza
Assignee: saari → nobody
QA Contact: ian → events
still a bug. Still causing problems for the inspector in Firebug. Also applies to mousemove events.
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
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 - https://github.com/jquery/jquery/issues/2558 https://github.com/jquery/jquery/issues/2592 It would be cool if you would help us out and deal with it. Thanks!
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!
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)
Attachment #8673968 - Flags: feedback?(bugs) → feedback+
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Last Resolved: 4 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? Sebastian
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? Sebastian
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: https://developer.mozilla.org/en-US/docs/Web/Events/mouseover https://developer.mozilla.org/en-US/docs/Web/Events/mouseout https://developer.mozilla.org/en-US/Firefox/Releases/44 Sebastian
Status: RESOLVED → VERIFIED
Missed some events. Updated the following pages now: https://developer.mozilla.org/en-US/docs/Web/Events/mouseenter https://developer.mozilla.org/en-US/docs/Web/Events/mouseleave https://developer.mozilla.org/en-US/docs/Web/Events/pointerover https://developer.mozilla.org/en-US/docs/Web/Events/pointerout https://developer.mozilla.org/en-US/docs/Web/Events/pointermove https://developer.mozilla.org/en-US/docs/Web/Events/pointerenter https://developer.mozilla.org/en-US/docs/Web/Events/pointerleave Sebastian
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/
I have come across this problem under slightly different circumstances, which causes some highly inconsistent functionality. When developing a Rails app that listens for click events on links with attributes like <a data-remote="true ...> to fire Ajax requests rather than a standard page navigation I have spotted the following... If the link tag is inside a disabled fieldset (or according to this bug, any disabled container) then the click event does not bubble up, breaking event listener functionality. The form markup in question is: <form> <fieldset disabled="true"> <a data-remote="true" href="/tests/new">test</a> </fieldset> </form> Worse than nothing happening, (which one might argue is reasonable for things like mouseover events), click events cause a standard page navigation. A document level listener can not be employed to prevent the default action from occurring. A messy workaround (in a reactive app or any single page application really) requires event listeners to be attached to links inside disabled containers by hand. Possible, but messy. A demonstration is here: https://jsfiddle.net/phil_ayres/fupbhrvL/3/ It works as expected in Chrome but not in Firefox (current or old versions). I understand that a disabled fieldset might prevent clicks on form input elements, but for links this seems to be a stretch. Or at least the link should be disabled completely and should not cause a page navigation to occur. If you think this is better as a new issue, let me know. I have been led here via Rails and JQuery projects.
phil.ayres, that sounds related to bug 1220048, not this bug per se. But it also seems clearly broken. I filed bug 1428838 on the specific issue you're seeing with fieldsets, in case you want to follow along.
Thanks for taking a look at this Boris. I must admit that I looked at 1220048 but it seemed to be too specific to field input elements, and those being disabled directly, rather than in a container. Since you have created a new report, I'll take the liberty of linking my original comment over there, in case it adds any value.
You need to log in before you can comment on or make changes to this bug.