1653882 - <input> doesn't fire document mouse events when disabled

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[jeum]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

<input type="text" disabled="disabled">
or
<input type="text" disabled="true">

js :
document.addEventListener( 'mousedown', myfunction)
document.addEventListener( 'mouseup', myfunction)
document.addEventListener( 'click', myfunction)

Actual results:

myfunction is not fired when I click on a disabled input (only in an enabled text field)

Expected results:

myfunction should be triggered like it is within Chrome and Edge ?

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Kagami Rosylight [:saschanaz] (they/them)]

I can repro this. The spec says:

A form control that is disabled must prevent any click events that are queued on the user interaction task source from being dispatched on the element.

I think it implies that the event should still be dispatched on document, am I correct?

Comment 3

[Anne (:annevk)]

This is https://github.com/whatwg/html/issues/2368.

Comment 4

[jeum]

May be should I explain the purpose : to detect a user click anywhere in order to retract (unexpand) a div, just like a <SELECT> does for instance. Moreover disabled <INPUT> allow to display AND rename (with a toggle button), that's why I need to detect it.

I thought that a diabled <INPUT> would triggers just because it's visible... It seems that it's also what 'think' other browsers.

Comment 5

[Thomas Wisniewski [:twisniewski]]

As per https://webcompat.com/issues/65773, this is breaking the newsletter subscription link at www.hrvatskitelekom.hr by outright disabling it, not just the disabled input inside of it covering its size.

Comment 6

[Kagami Rosylight [:saschanaz] (they/them)]

Can we possibly contact them to fix it or should we admit it's too late to fix https://github.com/whatwg/html/issues/2368 ?

Comment 7

[Ksenia Berezina [:ksenia]]

This is affecting Aliexpress search on mobile as well ( https://m.aliexpress.com/). I'll try to contact them

Comment 8

[Thomas Wisniewski [:twisniewski]]

This is also affecting sites.google.com, as they have disabled inputs as the text-labels for sub-pages: https://github.com/webcompat/web-bugs/issues/72988

Comment 9

[Karl Dubost💡 :karlcow]

Thomas, do you know if we can create catch all or specific site interventions until this is fixed in by the DOM Core team later in 2022?

Comment 10

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Kagami :saschanaz from comment #6)

Can we possibly contact them to fix it or should we admit it's too late to fix https://github.com/whatwg/html/issues/2368 ?

Referring to James' comment https://github.com/whatwg/html/issues/2368#issuecomment-866798324 it is suggested that we don't have other options than changing our behavior to align with others.

Comment 11

[Thomas Wisniewski [:twisniewski]]

Karl, unfortunately any "global" fix I have considered so far would end up being causing a performance regression, so I don't believe so. But we should be able to at least create a one-size-fits-all intervention that we only apply to specific sites, to save us time and effort (that would avoid perf regressions).

Comment 12

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Talked with Jens and Kagami, Kagami has cycle to tackle this. Thanks! :)

Comment 13

[Kagami Rosylight [:saschanaz] (they/them)]

Attachment: WIP: Bug 1653882 - Skip disabled form elements when dispatching events

Comment 14

[Kagami Rosylight [:saschanaz] (they/them)]

Attachment: 1653882.html

After additional investigation while writing tests, I found Chrome behavior is super inconsistent.

1. <select disabled></select>. It does not bubble to parents and thus no listener fires.
   • <select disabled><option>Foo</option>/select>`. It suddenly bubbles to parents, unless you click the arrow.
2. <fieldset disabled>Text</fieldset>. It does not bubble to parents and thus no listener fires.
   • <fieldset disabled><span>Span</span></fieldset>. It suddenly bubbles to parents.
3. <button disabled>Text</button>. It does not bubble to parents an thus zero events.
   • <button disabled><span>Span</span></button>. It suddenly bubbles to parents.
4. Any <textarea disabled>s. It bubbles to parents.
5. <input disabled>s:
   1. type=button does not bubble.
   2. type=checkbox does not bubble.
   3. type=color does bubble. Why?
   4. type=date/datetime-local/month/time/week does bubble if you click the text part, and does not bubble if you click the right empty part. wtf?
   5. type=email does bubble.
   6. type=file does bubble if you click the button part and does not bubble if you click the right text part. aoeutaneohusa
   7. type=number does bubble.
   8. type=password does bubble.
   9. type=radio does not bubble.
   10. type=range does bubble unless you click the slider button. 🙃
   11. type=reset does not bubble.
   12. type=search does bubble.
   13. type=submit does not bubble.
   14. type=tel does bubble.
   15. type=text does bubble.
   16. type=url does bubble.

What should I do? 😥

Sorry Hsin-Yi, this was much more weird than I expected and I think it deserves more discussion.

Comment 15

[Kagami Rosylight [:saschanaz] (they/them)]

Safari behavior is mostly same except:

• <select> never bubbles
• type=file never bubbles regardless of where the click happens.

Comment 16

[Kagami Rosylight [:saschanaz] (they/them)]

My take is that we should allow all of them to bubble, as failing to bubble caused several webcompat issues. But then I think bubbling for all also can cause another webcompat issue, hmm.

Edit: Maybe we can try bubble-for-all behind a flag and see any issue happens?

Comment 17

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Kagami :saschanaz from comment #14)

Created attachment 9254233 [details]
1653882.html

After additional investigation while writing tests, I found Chrome behavior is super inconsistent.

1. <select disabled></select>. It does not bubble to parents and thus no listener fires.
   • <select disabled><option>Foo</option>/select>`. It suddenly bubbles to parents, unless you click the arrow.
2. <fieldset disabled>Text</fieldset>. It does not bubble to parents and thus no listener fires.
   • <fieldset disabled><span>Span</span></fieldset>. It suddenly bubbles to parents.
3. <button disabled>Text</button>. It does not bubble to parents an thus zero events.
   • <button disabled><span>Span</span></button>. It suddenly bubbles to parents.
4. Any <textarea disabled>s. It bubbles to parents.
5. <input disabled>s:
   1. type=button does not bubble.
   2. type=checkbox does not bubble.
   3. type=color does bubble. Why?
   4. type=date/datetime-local/month/time/week does bubble if you click the text part, and does not bubble if you click the right empty part. wtf?
   5. type=email does bubble.
   6. type=file does bubble if you click the button part and does not bubble if you click the right text part. aoeutaneohusa
   7. type=number does bubble.
   8. type=password does bubble.
   9. type=radio does not bubble.
   10. type=range does bubble unless you click the slider button. 🙃
   11. type=reset does not bubble.
   12. type=search does bubble.
   13. type=submit does not bubble.
   14. type=tel does bubble.
   15. type=text does bubble.
   16. type=url does bubble.

What should I do? 😥

Sorry Hsin-Yi, this was much more weird than I expected and I think it deserves more discussion.

Thanks for more tests! It deserves more time and discussion, also see https://github.com/web-platform-tests/interop-2022/issues/27# :)

Comment 18

[Anne (:annevk)]

In reply to comment 2, what HTML means there is that the event is not dispatched. And when it's not dispatched no event path is created. That also means that parent nodes do not get to see it either. You can also see this by having a capture listener on the document in addition to a bubble listener. That might be worthwhile adding just in case.

---

In reply to comment 14, strangely enough on macOS I cannot get Chrome to fire a click event for any of the constructs you list. So there it appears to follow the HTML standard. (Safari does seem to fire it for a bunch of them.)

So we probably need to create a largish table with your constructs in the left-most column and then have columns for Chrome (macOS), Chrome (Windows), ... And given the behavior I see on macOS I suspect we want to break down each browser column into 3 and list the behavior for all three events listed in OP, because it seems click does not work across platforms for any construct, but maybe mousedown and mouseup do?

With that data it will hopefully be more obvious what to recommend to the HTML Workstream.

Does that seem reasonable?

Comment 19

[Kagami Rosylight [:saschanaz] (they/them)]

I and Anne made a table for different browser behaviors: https://docs.google.com/document/d/18OEhfqA7yYJWcvHKlzldkrg7SzseFGqKZNFlL0CBiec/preview

(Cross-posted to https://github.com/whatwg/html/issues/2368#issuecomment-989838979)

In reply to comment 14, strangely enough on macOS I cannot get Chrome to fire a click event for any of the constructs you list.

Turns out this is specific to Experimental Web Platform features flag, so no additional columns for OSes.

Comment 21

[James Graham [:jgraham]]

I created a wpt draft https://github.com/web-platform-tests/wpt/pull/32381 PR. I don't think it covers all the cases (in particular it doesn't handle clicking on different parts of the control), but at the moment it all passes in Chrome and all fails in Firefox, so it's at least showing some interop issues.

Comment 22

[James Graham [:jgraham]]

I've updated the test in that PR to cover more cases including synthetic events. (It still doesn't cover the case of clicking on different parts of UI controls, and I don't know how to cover that without really browser-specific hacks in the test, so probably won't be able to).

Comment 23

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 11 See Also bugs.
:saschanaz, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 24

[Kagami Rosylight [:saschanaz] (they/them)]

Yeah, but still not "Major functionality/product severely impaired or a high impact issue".

Comment 25

[James Graham [:jgraham]]

I think there's an inconsistency between the assessment that this is Webcompat Priority P1 and the assessment that it doesn't count as a "high impact issue". If we're triaging all the Webcompat Priorities correctly anything that's triaged as P1 should also meet the criteria to be S2.

I don't know if the Webcompat priority criteria are well documented, but for P1 we try to use something like "either serious breakage on a high traffic site, or significant, hard to work around, breakage affecting many sites". In this case it's a bit of both; there are multiple webcompat reports, and affected sites include aliexpress. Typically the failure mode is that user input fails to work in a way that can entirely break the page. So I'd probably stand by that assessment of the bug as "high impact".

Comment 26

[Kagami Rosylight [:saschanaz] (they/them)]

Thanks, that makes sense.

Comment 28

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Hi Kagami, any updates here?

Comment 29

[Kagami Rosylight [:saschanaz] (they/them)]

Google expects to have the added use counter to reach the stable channel today and gather the data from there for 1 or 2 weeks: https://github.com/whatwg/html/issues/5886#issuecomment-1189861050

It seems it already reached 0.9+ though: https://chromestatus.com/metrics/feature/timeline/popularity/4296

More discussion will probably happen on September.

Comment 30

[Kagami Rosylight [:saschanaz] (they/them)]

Short update: Google just published an intent to ship to mock our behavior. We'd still have to patch Gecko to fire pointerup/down since the current consensus is to limit the behavior to mouseup/down/click.

Comment 31

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Kagami :saschanaz from comment #30)

Short update: Google just published an intent to ship to mock our behavior. We'd still have to patch Gecko to fire pointerup/down since the current consensus is to limit the behavior to mouseup/down/click.

That is great news! Thank you for driving to make this happen, Kagami. :)
About to fire pointerup/down, am I right that there's no blocker against us starting to patch Gecko? Would you have bandwidth to work on a patch in the rest of this quarter?

Comment 32

[Kagami Rosylight [:saschanaz] (they/them)]

I believe it should be as simple as adding ePoitnerUp/Down to this list, unless there are other hidden issues.

Would you have bandwidth to work on a patch in the rest of this quarter?

I'll try.

Comment 33

[Thomas Wisniewski [:twisniewski]]

:saschanaz, we're still failing some WPTs that were added as per the spec discussion around this in https://github.com/whatwg/html/issues/5886:

• https://wpt.fyi/results/html/semantics/disabled-elements/fieldset-event-propagation.tentative.html?label=master&label=experimental&aligned
• https://wpt.fyi/results/html/semantics/selectors/pseudo-classes/disabled.html?label=experimental&label=master&aligned

WebKit and Blink now pass the related WPTs, so it would be good to match sooner than later and not cause other webcompat issues. Maybe we ought to at least set a priority here?

Comment 34

[Kagami Rosylight [:saschanaz] (they/them)]

That's https://bugzilla.mozilla.org/show_bug.cgi?id=1829874 and I'm on it.

Comment 36

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Hi Kagami,
Per this GH comment, Chrome shipped the new behavior into their stable channel about 5 months ago. And some tweaks on our end (bug 1799565 and bug 1829874) were enabled on nightly more than 6 months. I just verified the see-also webcompat issues; all of them are either no longer reproducible or resolved on the latest Firefox nightly 124.
So I wonder what the next step or remaining blocker here, before we close this bug and deploy to our release channel by default. Thanks!

Comment 37

[Kagami Rosylight [:saschanaz] (they/them)]

(In reply to Hsin-Yi Tsai (she/her) [:hsinyi] from comment #36)

Hi Kagami,
Per this GH comment, Chrome shipped the new behavior into their stable channel about 5 months ago. And some tweaks on our end (bug 1799565 and bug 1829874) were enabled on nightly more than 6 months. I just verified the see-also webcompat issues; all of them are either no longer reproducible or resolved on the latest Firefox nightly 124.
So I wonder what the next step or remaining blocker here, before we close this bug and deploy to our release channel by default. Thanks!

I can confirm the Chrome side change, we can ship the features and then ultimately close the upstream issue. I'll send a patch.

Comment 38

[Kagami Rosylight [:saschanaz] (they/them)]

Attachment: Bug 1653882 - Ship dom.forms.always_allow_pointer_events.enabled by default r=#dom-core

Both Chrome and Safari have been shipping the behavior dy default for some months and haven't been reporting regressions, now we can ship it too.

• https://chromium-review.googlesource.com/c/chromium/src/+/4629594
• https://github.com/WebKit/WebKit/commit/5d9f4aa0c0961d878fb5c00d676e857ed37904f8

Comment 39

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/87db82da5ead
Ship dom.forms.always_allow_pointer_events.enabled by default r=dom-core,edgar

Comment 40

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/87db82da5ead

Comment 41

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Hooray! Kagami, thank you very much for driving this to completion. :)

Comment 42

[Kagami Rosylight [:saschanaz] (they/them)]

🎉🎉