Expand disabled form control event handling spec text#12219
Expand disabled form control event handling spec text#12219hjanuschka wants to merge 3 commits intowhatwg:mainfrom
Conversation
Expand the spec text for disabled form controls to describe the complete set of events affected (click, mousedown, mouseup, dblclick) and the event path truncation behavior that prevents these events from bubbling through disabled form controls to ancestor elements. Add a note clarifying that pointer events are unaffected. This matches the behavior shipped in Chrome M120 (Nov 2023) via EventPath::AdjustForDisabledFormControl(), and aligns with Firefox's direction. The following WPT tests already verify this behavior but are marked .tentative pending this spec change: - html/semantics/disabled-elements/disabled-event-dispatch.tentative.html - html/semantics/disabled-elements/event-propagate-disabled.tentative.html - html/semantics/disabled-elements/disabled-event-dispatch-additional.tentative.html - html/semantics/disabled-elements/fieldset-event-propagation.tentative.html Once this lands, these tests can be renamed to remove the .tentative suffix. Closes: whatwg#5886 Closes: whatwg#2368 Fixes: https://issues.chromium.org/issues/41302618
hjanuschka
force-pushed
the
disabled-form-control-events
branch
from
1f34452 to
aa0143d
Compare
|
This looks reasonable, but eventually this kind of requirement should really live in UI Events (perhaps with some kind delegation to let HTML decide what elements it applies to) or whatever specification ends up defining the algorithm that will eventually call DOM's dispatch for these events. |
|
@annevk thanks, pushed update. |
josepharhar
left a comment
josepharhar
left a comment
There was a problem hiding this comment.
Thanks for starting this!
|
Thanks, I think the new paragraph explains the nuance. However, I wonder if it would be better to implement this directly in the event dispatching algorithms in the dom spec - if I were interested in reading the spec about this behavior, I probably wouldn't come across this area about the user interaction task source since it doesn't seem very related. The implementation in chromium is basically just this: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/events/mouse_event.cc;l=398-402;drc=75a48e0642c9e236aeebac88e338741f7a4a39ab I don't see anything about event paths in the UIEvents spec. |
3 participants
The current spec text for disabled form controls says only:
This is incomplete. This PR expands it to describe:
click,mousedown,mouseup, anddblclickare all prevented on disabled form controls (not justclick)pointerdown,pointerup, etc. are dispatched normallyAll three major engines have shipped this behavior.
Chrome - shipped M120 (Nov 2023)
Safari - shipped Safari 17 (Sep 2023)
Firefox - shipped Firefox 124 (Jan 2024)
dom.forms.always_allow_pointer_events.enabledshipped by default (Jan 2024)WPT tests
The following WPT tests already verify this behavior but are marked
.tentativepending this spec change:html/semantics/disabled-elements/disabled-event-dispatch.tentative.htmlhtml/semantics/disabled-elements/event-propagate-disabled.tentative.htmlhtml/semantics/disabled-elements/disabled-event-dispatch-additional.tentative.htmlhtml/semantics/disabled-elements/fieldset-event-propagation.tentative.htmlOnce this lands, these can be renamed to remove
.tentative.Closes
/form-control-infrastructure.html ( diff )
/form-elements.html ( diff )
/webappapis.html ( diff )