| 09:31 | <smaug> | Luke Warlow: in the setAttribute algorithm, isn't it a bit odd that step 5 may create a new attribute, which isn't necessarily used at all |
| 09:33 | <Luke Warlow> | Why would it not be used? |
| 09:33 | <Luke Warlow> | I guess if veriying an attribute value throws? |
| 09:33 | <smaug> | oh wait, I'm missing something |
| 09:34 | <smaug> | step 7 does explicit attribute check |
| 09:34 | <smaug> | hmm, how would I implement that efficiently ... |
| 09:36 | <Luke Warlow> | you can skip steps 6 and 7 if the CSP isn't enabled (in at least report only). And 7 if the attribute is a safe attribute |
| 09:39 | <smaug> | It is just the identity of the attribute I'm pondering |
| 09:41 | <smaug> | Luke Warlow: how does that work in webkit if the TT callback removes the relevant attribute and adds back an attribute with same qname? |
| 09:42 | <Luke Warlow> | it resyncs the attribute index before setting the value (but it only needs to do this when CSP is present AND when the attribute is one that requires a TrustedType) |
| 09:43 | <smaug> | but what does step 7 do? |
| 09:43 | <smaug> | It is not anymore the same attribute |
| 09:46 | <Luke Warlow> | That is true. |
| 09:46 | <smaug> | and I wish we wouldn't need to do identity checks for attributes here |
| 09:47 | <Luke Warlow> | I can probably move step 6 higher up |
| 09:47 | <Luke Warlow> | Maybe even to step 3? |
| 09:48 | <Luke Warlow> | It takes an attribute algorithmically but all it needs is an attributes local name and namespace |
| 09:48 | <smaug> | so you need step 3 first |
| 09:48 | <Luke Warlow> | We have qualifiedName already though right? |
| 09:49 | <Luke Warlow> | And namespace is null |
| 09:49 | <Luke Warlow> | That way all the actual lookups on the element etc happen after the default policy is called? And hopefully the flow looks nicer? |
| 09:50 | <smaug> | the attribute may have non-null namespace |
| 09:50 | <smaug> | if there is existing attribute |
| 09:51 | <Luke Warlow> | Ahhh okay. Hmm in which case maybe we can't move it any earlier? (Side note the default policy was a mistake 😅) |
| 09:51 | <smaug> | There is _some_ reason for the code Gecko has now 🙂 |
| 09:54 | <Luke Warlow> | Could you point me to the Gecko code? I guess to match WebKit (and I believe Chromium in this case), We need to redo step 3 after step 6 |
| 09:55 | <smaug> | This is the setAttribute. |
| 09:56 | <Luke Warlow> | Yeah so I think duplicating step 3 copies Firefox too? |
| 09:56 | <smaug> | Maybe it is quite similar to what webkit does |
| 09:57 | <smaug> | but the spec pr does something else, because of the identity check |
| 10:06 | <Luke Warlow> | This should match what we want right? (with a similar change to setAttributeNS()) |
| 10:06 | <smaug> | Looks like LadyBird stores actual Attr nodes, assuming I'm reading the code correctly |
| 10:06 | <smaug> | looking |
| 10:08 | <smaug> | that looks reasonable |
| 10:18 | <smaug> | Luke Warlow: btw, in webkit, do you need to call synchronizeAttribute again after TT callback? (I was just randomly looking at the code and I'm not sure when synchronizeAttribute is needed) |
| 10:23 | <Luke Warlow> | Hmm I'm not sure quite what it does but possibly yes. |
| 10:24 | <Luke Warlow> | It seems to only care about style for HTML which won't be changed by in a meaningfull way |
| 10:24 | <Luke Warlow> | But SVG might have some wonkiness? Though thinking about it anything weird you do in the default callback will also trigger that to be called by the respective DOM APIs? |
| 17:21 | <Ondřej Žára> | Hello, a quick check: what are the parsing rules for HTML entities inside non-script <script> elements? As in <script type="my/json"> { "url": "http://example.com?a=b&c=d"; } </script> Alternatively, where in the HTML standard can I find the answer, please? |
| 17:24 | <Ms2ger> | https://html.spec.whatwg.org/multipage/parsing.html#scriptTag perhaps |
| 17:25 | <annevk> | Ondřej Žára: they are the same for all script elements. It is extremely rare for the parser to depend on an attribute. |
| 17:26 | <Ondřej Žára> | ...riight, okay. So if I read this correctly -- the insides will be tokenized via https://html.spec.whatwg.org/multipage/parsing.html#script-data-state, so the "&" will produce literally 5 characters, no entity decoding happens, right? |
| 17:27 | <Ondřej Žára> | (in other words: no entity encoding should be performed for data being put into the <script>) |
| 17:27 | <annevk> | Pretty sure that's the case, yes. You can typically trust browsers when it comes to the HTML parser. |
| 17:28 | <Ondřej Žára> | Great, thanks for confirming. It is not always easy to convince 3rd party HTML creators to not entity-encode their strings just because the are being put into a different part of a HTML document (once in <a href>, once in <script>). |
| 17:38 | <annevk> | The thing you want to be careful about is ASCII-case-insensitive matches for </script. |
| 17:52 | <zcorpan> | Also <!-- |
| 19:43 | <jessica long> | Matthew MajorMatthew Major |