Open Bug 1220048 Opened 4 years ago Updated 5 months ago
Disabled child element doesn't produce mousedown, mouseup and click events
+++ 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. Sebastian  http://www.w3.org/html/wg/drafts/html/master/semantics.html#concept-fe-disabled
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: → https://webcompat.com/issues/24628
Webcompat Priority: --- → ?
Whiteboard: [webcompat] → [webcompat-revisit]
Webcompat Priority: ? → revisit
You need to log in before you can comment on or make changes to this bug.