Closed Bug 218093 Opened 21 years ago Closed 9 years ago

disabled child element doesn't produce mouseout/mouseover pair

Categories

(Core :: DOM: Events, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla44
Tracking Status
firefox44 --- fixed

People

(Reporter: hincubator, Assigned: bzbarsky)

References

(Blocks 1 open bug, )

Details

(Keywords: dev-doc-complete, site-compat, Whiteboard: [firebug-p2])

Attachments

(5 files)

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.
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?
Blocks: 202806
(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?
Blocks: 274626
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/
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?
Blocks: 190876
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. 
Blocks: 100085, 297979
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
Whiteboard: [firebug-p3]
Blocks: 366517
Blocks: 497805
still a bug. Still causing problems for the inspector in Firebug.

Also applies to mousemove events.
Attached file example
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.
Depends on: 329509
Whiteboard: [firebug-p3] → [firebug-p2]
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
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?
Flags: needinfo?(bugs)
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)
Flags: needinfo?(bugs)
Attachment #8673968 - Flags: feedback?(bugs) → feedback+
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Attachment #8674373 - Flags: review?(bugs) → review+
https://hg.mozilla.org/mozilla-central/rev/59f9af445e72
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
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.
See Also: → 1220048
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
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.
See Also: → 1653882
You need to log in before you can comment on or make changes to this bug.