Form attribute not set in custom element

[Maicol Battistini]

Mithril.js version: 2.2.2
Browser and OS: Microsoft Edge 116 on Windows 11

Code

https://codesandbox.io/s/mithril-form-bug-custom-elements-mwv4z5

Steps to Reproduce

1. Use a custom element with form attribute support
2. Try to render it with Mithril
3. See error

Expected Behavior

Custom element with form attribute is created without errors

Current Behavior

Error:

TypeError: Cannot set property form of #<Button> which has only a getter
    at setAttr (render.js:744:19)
    at setAttrs (render.js:720:4)
    at createElement (render.js:122:4)
    at createNode (render.js:63:14)
    at createNodes (render.js:50:5)
    at createElement (render.js:130:5)
    at createNode (render.js:63:14)
    at createComponent (render.js:158:4)
    at createNode (render.js:66:8)
    at createNodes (render.js:50:5)
    at updateNodes (render.js:273:45)
    at eval (render.js:973:4)
    at Function.mount (mount-redraw.js:44:4)
    at $csb$eval (index.ts:5:3)
    at H (eval.js:31:28)
    at K.evaluate (transpiled-module.js:715:29)
    at ge.evaluateTranspiledModule (manager.js:340:33)
    at c (transpiled-module.js:697:31)
    at loadResources (index.html:3:2)
    at $csb$eval (index.html:9:3)
    at H (eval.js:31:28)
    at K.evaluate (transpiled-module.js:715:29)
    at ge.evaluateTranspiledModule (manager.js:340:33)
    at ge.evaluateModule (manager.js:311:34)
    at compile.ts:834:31
    at c (runtime.js:45:40)
    at Generator._invoke (runtime.js:274:22)
    at forEach.t.<computed> [as next] (runtime.js:97:21)
    at e (asyncToGenerator.js:3:20)
    at a (asyncToGenerator.js:25:9)

[Claudia Meadows]

We intentionally bypass our usual form-related hacks for custom elements and just use properties for everything for them, as they might have non-standard semantics for attributes. And yes, I've seen custom element libraries that treat setAttribute completely differently from property assignment and even give it unusual semantics. So we really can't assume anything on our end, and setAttribute itself could have unusual interactions (such as with the above linked library), so properties are the safer default in practice.

I recommend using setAttribute directly in oncreate/onupdate as needed. Feel free to implement that workaround in a wrapper component - it could come in handy abstracting the inconvenient bits away.