Fix form checkValidity(), remove vnode.dom === .activeElement from setAttr() (Continued from #2257)

[kfule]

Remove vnode.dom === activeElement(vnode.dom) from setAttribute() to fix validityCheck(), to fix #2256

Description

This is #2257 reopened. (#2257 is for the next branch and may not be reopened as is.)
I cherry-picked commit #2257 with additional comments and refactoring.

Motivation and Context

It appears that #2257 was incorrectly closed due to a typo (with 2557, #2257 (comment)).
#2257 actually fixes #2256.

How Has This Been Tested?

• npm run test
• The following flems were tested using this PR build bundle.
  flems (input)
  flems (textarea)

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• My code follows the code style of this project.
• I have added tests to cover my changes.
• All new and existing tests passed.
• My change requires a documentation update, and I've opened a pull request to update it already:
• I have read https://mithril.js.org/contributing.html.

[kfule]

Please let me know if any additional test code is needed.
In my opinion, it seems difficult to reproduce the behavior of checkValidity() using domMock for testing.

[dead-claudia]

Verified by mirroring the changes in your input and textarea examples.

I would like to see a manual render test at minimum, though. Here's some smaller test cases for you:

• input
• textarea

I couldn't get the minlength constraint to work because it's specified to only validate user input, not script input. I tried instead just doing <input type="url"> as it's possible to force constraint errors that way, but I couldn't trigger the bug.

Unfortunately, what's really going on is a counterintuitive interaction I've explained in a comment, and unless you feel like wiring up Puppeteer and everything, there's no real way to test this without some exceptionally awkward mocking.

[dead-claudia]

The precise issue is this: minlength and maxlength constraints in form controls are only checked against values generated from user edits, not from script edits. When a user edits it and a script reads and writes the same previous value, the current value is considered to be last edited by script, and thus minlength and maxlength constraints are no longer checked.

I'll leave it to you how to distill this into a comment. Here's the relevant spec links:

• https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#attr-fe-maxlength
• https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#attr-fe-minlength

[kfule]

@dead-claudia
Thanks for your kind review comments.
As you suggested, I will add some manual rendering tests and change the comments to be more accurate.

[dead-claudia]

Just that one nit and it's ready to merge.

[dead-claudia]

Sorry for the noise. Didn't realize the merge rule was stopping me over my comment edit.