Expand disabled form control event handling spec text - #12219
Conversation
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. |
|
moved the normative requirements out of the user interaction task source and into the disabled |
|
I guess if the logic really exists in uievents instead of any of the whatwg specs like anne was saying, then maybe changing whatwg/dom won't be necessary. This change certainly does make things better though, so lgtm |
|
@smaug---- any chances you can take a look? (not sure whats the process is; to move on) |
|
can we merge this? |
|
I'd certainly like to see this get merged. I'll add agenda+ |
|
I think this doesn't need to be on the agenda, but this needs a new pr. @hjanuschka would you have time to update this? |
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
click and dblclick events are never queued on the user interaction task source; they are dispatched synchronously from the task that dispatches mouseup. Keying the requirement on the task source would also wrongly suppress untrusted events fired by script from within that task. Rephrase both the option element and form control requirements to apply to events whose isTrusted attribute is true, matching shipped engine behavior.
2746326 to
236b8aa
Compare
|
updated - both paragraphs now keyed on trusted click/mousedown/mouseup/dblclick events, rebased on main. ptal @smaug---- |
|
@smaug---- or did you mean to close and new PR? |
|
I think updating is fine. Thanks. |
update pushed |
4 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 )