Open Bug 1220048 Opened 4 years ago Updated 5 months ago

Disabled child element doesn't produce mousedown, mouseup and click events

Categories

(Core :: DOM: Events, defect, P3)

defect

Tracking

()

Webcompat Priority revisit
Tracking Status
firefox45 --- affected

People

(Reporter: sebo, Unassigned)

References

Details

Attachments

(1 file)

Attached file Test case
+++ This bug was initially created as a clone of Bug #218093 +++

When clicking a disabled element mousedown, mouseup and click events are not triggered by ancestor elements.

Chrome 46.0, Opera 33.0, IE 11 and Edge (can't test Safari) however *do* trigger events in this case.
Their behavior may be contrary to the HTML 5.1 spec, though.[1]

Sebastian

[1] http://www.w3.org/html/wg/drafts/html/master/semantics.html#concept-fe-disabled
See Also: 497805218093
Yeah, it's not quite clear to me what the HTML spec is saying to do here, nor exactly what other UAs implement.  If you look at the behavior in Chrome, at least, more carefully, we have the following situation:

1)  The click event handler fires on the document.
2)  The event target is the HTMLInputElement.
3)  A click event handler on the <input> itself does NOT fire.

#3 suggests that there is certainly some sort of weirdness going on here.
#3 can be observed on the other browsers, too.

Sebastian
OK.  So what is the actual behavior, then?  Is the event set up with target = X and then dispatched to some other node Y?  If so, how is Y determined?  Which events is this behavior happening for?  Chrome, at least, won't fire an mouseover event on the disabled input itself....
(In reply to Boris Zbarsky [:bz] from comment #3)
> Is the event set up with target = X and then dispatched to some other node Y? If so, how is Y determined? 

What I could observe from my tests is that the event target is always the input while the event handler was set to one of its ancestors.

> Which events is this behavior happening for?  Chrome, at least, won't fire
> an mouseover event on the disabled input itself....

mouseover, mouseout, mousemove, mousedown, mouseup and click events are not fired on the disabled input, though all are fired when they are set on an ancestor.

Regarding the spec. I'm asking here:
https://lists.w3.org/Archives/Public/public-html/2015Oct/0010.html

Sebastian
After encountering the behaviour described herein I set about diagnosing it more precisely.

The behaviour in Chrome and Edge is the same, and seriously wacky; take a button with only a text node, and no mousedown/mouseup/click events will be fired on it. But wrap the contents of the button in a span, and click inside the span, and an event will be fired on the span, then *skip* the disabled button, and resume above it. (Click in the padding of the button rather than inside the span, and no event will be fired, as the button is the target.)

So the behaviour implemented seems to be:

- If the event target is a disabled button, throw it away;
- During capture and bubbling, if a node is a disabled button, *skip that node* and resume with whichever comes next (its parent for bubbling or its child for capture).

As I say, Chrome and Edge are doing the same screwy thing on buttons, while Firefox is doing its own thing which seemed less convenient at first but at least makes more sense.

When it comes to disabled text inputs: on Chrome they fire, on Edge they don’t. Relating it to the earlier remarks on buttons, it’s as though Chrome is treating the text field as a pseudoelement inside the disabled input, while Edge treats it as the disabled input and thus throws away the events.

There is clearly no definite and specific action to be taken to restore parity with other browsers: everyone does their own screwy thing, and Firefox’s, while commonly less useful (I encountered this while trying to make clicking on a disabled button draw attention to the reason the button was disabled, and I simply can’t do that in Firefox as it stands), generally makes the most sense!
See Also: → 1443148
Priority: -- → P3
Duplicate of this bug: 1525207

This is now causing breakage on Yahoo Mail's account settings page.

Flags: webcompat?
Whiteboard: [webcompat]
See Also: → 1520869

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Webcompat Priority: --- → ?

See bug 1547409. Migrating whiteboard priority tags to program flags.

Whiteboard: [webcompat] → [webcompat-revisit]
Webcompat Priority: ? → revisit
Whiteboard: [webcompat-revisit]
You need to log in before you can comment on or make changes to this bug.