Re: [whatwg/dom] Trusted types attributes (PR #1268)

@fred-wang commented on this pull request.



> @@ -7382,7 +7437,13 @@ string <var>value</var>, run these steps:
  <li><p>If <var>attribute</var>'s <a for=Attr>element</a> is null, then set <var>attribute</var>'s
  <a for=Attr>value</a> to <var>value</var>.
 
- <li><p>Otherwise, <a lt="change an attribute">change</a> <var>attribute</var> to <var>value</var>.
+ <li><p>Otherwise:
+  <ol>
+    <li><p>Let <var>verifiedValue</var> be the result of calling <a>verify attribute value</a>
+    <var>value</var> for <var>attribute</var>, with <a>this</a>.
+
+   <li><p><a lt="change an attribute">Change</a> <var>attribute</var> to <var>verifiedValue</var>.

I see Chromium / WebKit just call their element's "set attribute", which takes care of applying TT policy default:

https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/dom/attr.cc;drc=003b43cb850a2fb81bb482cd95381338b7205933;l=73
https://searchfox.org/wubkat/rev/446d00e44d23eba2d8c1c1c92bf0171472dee385/Source/WebCore/dom/Attr.cpp#97

They both store the element in a strong reference (RefPtr and Member) so it won't get destroyed by the callback. And they will modify the attribute value of that element.

But the spec does not check whether the attribute's element become null. And if it is attached it to a different element, then it will just run the "handle attribute changes" on that new element:
https://dom.spec.whatwg.org/#concept-element-attributes-change
https://dom.spec.whatwg.org/#handle-attribute-changes


-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/pull/1268#discussion_r1946104543
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/pull/1268/review/2601037880@github.com>