WHATWG
2025-10-30
plaintext logs
prev next
source on github
08:15
<nicolo-ribaudo>
Question about https://github.com/whatwg/html/issues/10673: would those modules also be importable through JS import ... with { type: "css" }? Or is the reason we are talking about the import map something else?
08:54
<smaug>
Andreu Botella: remind me, was there some good solution for the sync cross-origin asyncContext case?
08:54
<annevk>
nicolo-ribaudo: I think the idea is that they would be when you use the specifier, yes
08:55
<Andreu Botella>
Andreu Botella: remind me, was there some good solution for the sync cross-origin asyncContext case?
The solution so far would be to switch to an empty context before firing the cross-origin event, but I still need to investigate this in more detail
08:56
<smaug>
hmm, how do we know something is cross-origin event?
08:58
<smaug>
I guess one could have something on stack and when trying to access it do some check. Maybe that works.
08:59
<smaug>
and the new realm would effectively need to push something to stack and once done, pop
10:30
<annevk>
Is this about same-site-cross-origin or cross-origin due to process limitations on certain platforms?
10:32
<Andreu Botella>
So far when considering the interaction with origins, we've only been considering the "same origin" spec check and ignoring sites, so both
10:33
<Andreu Botella>
But I guess the interaction with sites is far from settled
10:45
<Luke Warlow>

annevk: and smaug

Given the below html what do we think the end result should be:

<head>
    <meta http-equiv="content-security-policy" content="require-trusted-types-for 'script'">
</head>
<div id="div1" onclick="alert(1)"></div>
<span id="div2"></span>
<script>
    let count = 0;
trustedTypes.createPolicy('default', {
    createScript: (a, b, c) => {
        count++;
        if (count > 1) {
            return a;
        }
        const attr = div1.attributes.getNamedItem('onclick');
        div1.removeAttributeNode(attr);
        div2.attributes.setNamedItem(attr);
        return a;
    }
});

div1.attributes[1].value = 'alert(2)';
</script>
10:46
<Luke Warlow>

Chrome stable results in

<div id="div1" onclick="alert(2)"></div>
<span id="div2" onclick="alert(1)"></span>

Firefox Nightly in:

<div id="div1"></div>
<span id="div2" onclick="alert(2)"></span>

WebKit Trunk and Spec in:

<div id="div1"></div>
<span id="div2" onclick="alert(1)"></span>
10:47
<smaug>
annevk: it is not limitation on certain platforms. It is because of .domain. So, same-site. But perhaps it could apply to some platforms in different-site case too.
10:50
<smaug>
annevk: Background being cases like https://github.com/WICG/scheduling-apis/issues/114#issuecomment-2674911489 where focus() can do interesting things. Scheduler API had a somewhat major bug where cross-origin pages could affect scheduling of tasks in the other origin.
10:50
<Luke Warlow>
Oli has a preference for Firefox Nightly's behaviour. I'm open to either, so I think if Anne agrees I'll update the spec, and then go and update the tests to account for that.
10:51
<smaug>
Luke Warlow: and of those I think Firefox behavior is least weird
10:52
<Luke Warlow>
The alternative is an option 4 where we throw in that case, which I know Anne did raise as preferable to the current spec behaviour.
10:52
<smaug>
I could possibly live with that.
10:52
<smaug>
though it isn't super clear to me why we would throw
10:53
<Luke Warlow>
Apologies that there's still some of these edge cases to resolve, I really did think we had the tests covering this but it seems we're not quite fully covering them.
10:53
<smaug>
someone is trying to set attribute node's value, and TT isn't throwing, so why wouldn't it succeed
10:54
<annevk>
But why would setting succeed before you hear back from TT?
10:54
<Luke Warlow>
It doesn't, it happens after TT runs
10:55
<annevk>
Oh, FF moves the attribute and then the setter succeeds.
10:55
<Luke Warlow>
Whereas Webkit trunk and spec, moves the attribute but the setter early returns.
10:56
<smaug>
and value setting becomes oddly no-op
10:56
<annevk>
I see, and we did an early return because the parent changed and thus it might no longer be accurate.
10:56
<Luke Warlow>
The thinking there was they've done something strange and I wasn't entirely convinced it couldn't be used to do something bad. But I think it would have to be a very weirdly written default policy relying on some form of global state for you to ever possibly run into that
10:57
<Luke Warlow>
Ultimately if the attribute isn't bad on the new element it's fine. If it is bad it'll be covered by TT on the move, so it's probably fine?
10:58
<annevk>
Like say you move onload from a div (used by a library) to img. Now I guess either retaining the existing value or updating to the new value could be bad.
10:59
<smaug>
Basically we need to trust TT callbacks to not do unsafe things to themselves, and we need to protect DOM from TT callbacks which try to attack implementations in some way (like trying to get DOM into weird state).
11:01
<Luke Warlow>
The default policy would get the oppurtunity to remove the existing value fwiw, because the default policy would run on move, but they don't actually get information on the element's type, they just get 'Element onload'.
11:01
<annevk>
What does the mutation record look like in FF?
11:02
<annevk>
Basically I think I'm okay with aligning on FF and smaug's stated principles, as long as it all adds up.
11:04
<smaug>
In FF there should be attr removal, adding it somewhere else and then modifying the value. TT callback happens before any DOM mutations, and in the example it does those two first ones, and that last mutation should be setting the new value.
11:13
<Luke Warlow>
Yeah firefox gets [div1] onclick removed: alert(1) [div2] onclick added [div2] onclick modified: alert(1) -> alert(2)
11:17
<Luke Warlow>
Given the mutation records add up does this seem okay? If so I'll go ahead and update the spec PR and work on the test
16:45
<annevk>
Luke Warlow: if you're still around, mind if I push an editorial commit to your DOM TT PR?
16:48
<Luke Warlow>
No that's fine, go for it!
17:02
<annevk>
smaug: unless you want more time I plan to merge tomorrow (https://github.com/whatwg/dom/pull/1268 that is).
17:03
<smaug>
Looking right now
17:03
<annevk>
Also assuming Luke is okay with my changes, but I suspect so.
17:04
<Luke Warlow>
LGTM
17:06
<smaug>
(uh, hard to review on mobile)
17:06
<annevk>
Haha, I don't even review on my laptop most of the time. Let alone mobile.
17:07
<smaug>
Seems fine though
17:11
<smaug>
Wait
17:12
<smaug>
Ah, nm, appending attribute creates mutationrecord too, no need to change
18:58
<smaug>
(but I'm not going to say yet anything about another issue I think we have...related to how attributes are actually implemented, not how they are defined. Need to test a bit)
20:32
<smaug>
ah, no, it should be fine.