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

Status: RESOLVED DUPLICATE of bug 1653882

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

Description

[Sebastian Zartner [:sebo]]

Attachment: 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

Comment 1

[Boris Zbarsky [:bzbarsky]]

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.

Comment 2

[Sebastian Zartner [:sebo]]

#3 can be observed on the other browsers, too.

Sebastian

Comment 3

[Boris Zbarsky [:bzbarsky]]

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....

Comment 4

[Sebastian Zartner [:sebo]]

(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

[Chris Morgan]

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!

Comment 7

[Thomas Wisniewski [:twisniewski]]

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

Comment 8

[Firefox Bug Husbandry Bot]

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

Comment 9

[Firefox Bug Husbandry Bot]

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

Comment 10

[David Bachmann]

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

[Emilio Cobos Álvarez [:emilio]]

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.

Comment 12

[Kagami Rosylight [:saschanaz] (they/them) (inactive until 2025-11-14)]

There's newer bug with more information: