Disabled child element doesn't produce mousedown, mouseup and click events
Categories
(Core :: DOM: Events, defect, P3)
Tracking
()
Webcompat Priority | P3 |
Tracking | Status | |
---|---|---|
firefox45 | --- | affected |
People
(Reporter: sebo, Unassigned)
References
Details
Attachments
(1 file)
424 bytes,
text/html
|
Details |
+++ 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
Reporter | ||
Updated•9 years ago
|
Comment 1•9 years ago
|
||
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.
Reporter | ||
Comment 2•9 years ago
|
||
#3 can be observed on the other browsers, too. Sebastian
Comment 3•9 years ago
|
||
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....
Reporter | ||
Comment 4•9 years ago
|
||
(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
Comment 5•7 years ago
|
||
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!
Updated•6 years ago
|
Comment 7•5 years ago
|
||
This is now causing breakage on Yahoo Mail's account settings page.
Comment 8•5 years ago
|
||
Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.
Comment 9•5 years ago
|
||
See bug 1547409. Migrating whiteboard priority tags to program flags.
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•3 years ago
|
Comment 10•2 years ago
|
||
I can't speak for the standard, but the current state seems ridiculus. Things like "click anywhere else to close" are very common and with this, the document just gets a blind spot for clicks on any disabled component. Not even window recieves that mousedown anymore.
It even breaks other expectations of event order. E.g. the focus still moves, without a chance to preventDefault on the mousedown.
Either it should behave like chrome or just flatout dispatch the event on the closest non disabled parent, or at the very least on the element that would receive focus.
FFs behavior might be the most consistent out of the available browsers, but it is the one that breaks my code that expects to capture mousedown events regardless of what its children are doing, chrome doesn't.
My current workaround is to capture the focus event, too. But that only works because I happen to have another focusable element below.
Comment 11•2 years ago
|
||
See https://github.com/web-platform-tests/interop-2022/issues/11, there's probably going to be ongoing interop work in this area across all engines.
There's newer bug with more information:
Description
•