Bug 265071 – Don't fire dblclick on disabled form control elements

• Status: RESOLVED
• Resolution: FIXED
• Component: DOM

[Tim Nguyen (:ntim)]

See:
https://github.com/whatwg/html/issues/2368#issuecomment-1791704780
https://chromium-review.googlesource.com/c/chromium/src/+/5007308
https://github.com/web-platform-tests/wpt/pull/42976

[Radar WebKit Bug Importer]

<rdar://problem/118584431>

[Ahmad Saleem]

Something to do here?

https://searchfox.org/wubkat/rev/114aa2c8594807cbc34dd5dff48a9e2addfd1e00/Source/WebCore/dom/EventDispatcher.cpp#160

if (node.document().settings().sendMouseEventsToDisabledFormControlsEnabled() && event.isTrusted() && event.isMouseEvent()
        && (event.type() == eventNames().mousedownEvent || event.type() == eventNames().mouseupEvent || event.type() == eventNames().clickEvent)) {
        eventPath.adjustForDisabledFormControl();
    }

[Ahmad Saleem]

Adding:

|| event.type() == eventNames().dblclickEvent

[Ahmad Saleem]

NOTE - this compiles and after importing new tests and running on patch build, we pass all tests.

@Tim - do you want me to do PR? I might do separate bug first to update all tests.

[Ahmad Saleem]

PASS Testing dblclick events when clicking child of disabled button.
PASS Testing dblclick events when clicking child of disabled my-control.
PASS Testing dblclick events when clicking disabled button.
PASS Testing dblclick events when clicking disabled my-control.

^ All passes.

[Abrar Rahman Protyasha]

@[e-mail] go for it. Let's start with a PR syncing `wpt:html/semantics/` and then a PR for the fix you're proposing.

[Abrar Rahman Protyasha]

Ah, spoke a minute too late, I see the WPT sync PR is up.

[EWS]

Committed 270951@main (74ae3ea8d68e): <https://commits.webkit.org/270951@main>

Reviewed commits have been landed. Closing PR #20723 and removing active labels.