You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think this comes from the fact that the form attribute as a property is readOnly. If you use setAttribute('form', 'foobar-form-id') things are properly updated, but the code path that htmlbars takes is setPropertyStrict which is just element[name] = value;.
Seems reproducible, but hopefully this screenshot is enough:
You'll notice there's no form attribute even though it is in the attributeBindings list and has a value.
I thought this might be related to this? #10186 unsure though. Not much context.
To make matters worse, it appears that chrome dev, chrome canary, and chromium all throw an error at this line now (which is how I found this out). I didn't report that as the bug because I'm the one using beta browsers, but I think the error might be correct?
Screenshot of that:
The error message is:
Uncaught TypeError: Cannot set property form of # which has only a getter
Which I mostly just paste here for google-ability for when other people hit this. It's not that helpful :D.
So I think we might need a whitelist of readonly attributes? Are there other ones?
The text was updated successfully, but these errors were encountered:
@mmun - just pinging to see if this premise sounds correct. If so, I might try my hand at patching it. Seems handlebars-y so I chose you, sorry for the direct ping.
Yea, look like the same thing. Though I spose this issue could have saved the first half of the sleuthing on that issue 😄 -- maybe I'll be brave and subscribe.
I agree with the whitelist approach, and I think it'd actually not be crazy to find a list of readOnly attributes which are the attributes that throw.
I think this comes from the fact that the
form
attribute as a property is readOnly. If you usesetAttribute('form', 'foobar-form-id')
things are properly updated, but the code path that htmlbars takes issetPropertyStrict
which is justelement[name] = value;
.Seems reproducible, but hopefully this screenshot is enough:
You'll notice there's no
form
attribute even though it is in theattributeBindings
list and has a value.I thought this might be related to this? #10186 unsure though. Not much context.
Here's a fairly reduced test-case of property setting vs. setAttribute: http://jsbin.com/cujani/edit?js,output (note that only button2 ends up with a
form
attribute). It does seem to be the case that it's intended to be able to be updated, since the spec explicitly outlines how to handle updates.To make matters worse, it appears that chrome dev, chrome canary, and chromium all throw an error at this line now (which is how I found this out). I didn't report that as the bug because I'm the one using beta browsers, but I think the error might be correct?
Screenshot of that:
The error message is:
Which I mostly just paste here for google-ability for when other people hit this. It's not that helpful :D.
So I think we might need a whitelist of readonly attributes? Are there other ones?
The text was updated successfully, but these errors were encountered: