- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 02 Apr 2026 16:58:44 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-view-transitions-2] Figuring out whether a ViewTransition was skipped or not, is not possible`, and agreed to the following: * `RESOLVED: return the dictionary with info on whether the transition skipped or not, and also make sure we resolve that correctly based on the object vuln` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> vmpstr: so we have promises on our VT. ready, finished, domcallbackfinished<br> <TabAtkins> vmpstr: they resolve with udnefined<br> <TabAtkins> vmpstr: there is an oppo to add some information, a dictionary reporting whether it was skipped or not<br> <TabAtkins> vmpstr: so this lets us report that, yes, the promise resolved, but due to the transition skipping rather than finishing<br> <TabAtkins> vmpstr: this is similar to scroll promises<br> <TabAtkins> ntim: sounds fine<br> <TabAtkins> +1<br> <emilio> q+<br> <TabAtkins> proposed: add info to the VT promises on whether or not they are skipped<br> <astearns> ack emilio<br> <TabAtkins> emilio: one subtle thing that can happen when resolving a promise with a random object, is if the epage overrides the object it can run sync and mess things up<br> <TabAtkins> emilio: do we need to audit places that currently return undefined?<br> <TabAtkins> emilio: assumption is that returning udnefined is always safe right now, but if it can run sync script<br> <andreubotella> q+<br> <TabAtkins> emilio: not sure if WebIDL dicts cause this issue, but it is when resolving with Dom objects<br> <astearns> ack andreubotella<br> <emilio> https://github.com/tc39/proposal-thenable-curtailment/<br> <TabAtkins> andreubotella: there's current work in TC 39 on fixing this<br> <TabAtkins> andreubotella: so WebIDL resolution auto-prevents this kind of attack<br> <TabAtkins> andreubotella: if `then` is added to Object.prototype, resolving with WebIDL will ensure that doesn't run<br> <TabAtkins> andreubotella: still at an early stage, not clear when it'll be accepted/fixed<br> <TabAtkins> emilio: right, if the proposal was already implemented i wouldn't have brought it up. but until then, might need to be a little careful about when it's resolved, exactly<br> <TabAtkins> emilio: resolution time is observable, then. spec assumptions about what can and can't happen might be violated<br> <flackr> q+<br> <astearns> ack flackr<br> <TabAtkins> TabAtkins: my point was just that Objec.tprototype.then isnt' something a page would do innocently, so if things screw up (both dont' crash) it's fine<br> <TabAtkins> flackr: if we construct the object at promise microtask resolution time, doesn't that protect?<br> <TabAtkins> emilio: the issue is when exactly you call `resolve()`<br> <TabAtkins> emilio: you queue a microtask, create the object, then resolve the promise which queues another microtask<br> <TabAtkins> emilio: the tc39 proposal would do what you mean, which is ignore then .then getter and resolve sync<br> <TabAtkins> emilio: that's ideal, but it's not the behavior you get right now if you resolve a promise with a new dictionary<br> <TabAtkins> vmpstr: seems like that would be subtle/wide-ranging, right? not scoped to VT?<br> <TabAtkins> emilio: right, it's not<br> <TabAtkins> emilio: but there's been similar security vulns because of this issue<br> <TabAtkins> emilio: font loading, web Animations, etc<br> <TabAtkins> emilio: might not even be an issue here depending on WebIDL dictionary impl. we just have to be careful<br> <TabAtkins> emilio: we just probably need to write the spec to manually queue a microtask to resolve the promise async<br> <TabAtkins> astearns: so proposed resolution is to return the dictionary with info on whether the transition skipped or not, and also make sure we resolve that correctly based on the object vuln<br> <TabAtkins> RESOLVED: return the dictionary with info on whether the transition skipped or not, and also make sure we resolve that correctly based on the object vuln<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13379#issuecomment-4179188636 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 2 April 2026 16:58:45 UTC