Closed Bug 1659218 Opened 2 years ago Closed 2 years ago

<input disabled> incorrectly responds to dispatchEvent()

Categories

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

defect

Tracking

()

RESOLVED FIXED
84 Branch
Webcompat Priority ?
Tracking Status
firefox84 --- fixed

People

(Reporter: saschanaz, Assigned: saschanaz)

References

Details

Attachments

(2 files)

<input disabled> must not respond to dispatchEvent(new MouseEvent("click")) unless they are checkboxes or radio buttons, but they do.

Assignee: nobody → krosylight
Severity: -- → S3
Priority: -- → P2

Context: https://phabricator.services.mozilla.com/D87151#inline-498464

The type changing behavior differs between Firefox and Chrome. On Firefox the original radio button does remain checked, while on Chrome the target input remains checked even when it's not a radio button anymore, with .checked === true.

The spec currently seems to support Chrome one, as it requires the legacy cancelation behavior only if its current type is radio button.

Should I file a spec issue, or should we follow Chrome behavior? My personal preference is the current Firefox behavior, though.

Flags: needinfo?(bugs)

Hmm, Chrome's behavior feels odd. Can you think of reason for that?

Flags: needinfo?(bugs)

No reason I can think of. Probably a new spec issue?

yeah. I think keeping checked==true feels a bit odd.

Duplicate of this bug: 1671332
Webcompat Priority: --- → ?
Duplicate of this bug: 1671332
Pushed by krosylight@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c0a950708a15
Prevent activating disabled inputs via dispatchEvent r=smaug
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/26302 for changes under testing/web-platform/tests
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 84 Branch
Upstream PR merged by moz-wptsync-bot
Blocks: 1774035
You need to log in before you can comment on or make changes to this bug.