Thanks for filing!

Oh, something that came up at TPAC that we haven't discussed.

Folks from Apple expressed that they'll want some wiggle room here, and were pushing for a higher level API. Folks from MS expressed that they want something precisely specified.

I think resolving this is unlikely to change Chrome's implementation much, but it could change naming.

I opened up an issue on the explainer here: https://github.com/tdresser/should-yield/issues/1.

Regarding receiving input information from cross-origin iframes- would it make sense to gate the experimental implementation on OOPIF support/strict site isolation? This would allow the MTEQ to satisfy the P&S requirements discussed in https://github.com/tdresser/should-yield/issues/2 without implementing off-main-thread hit testing in the renderer.

Ouch, good point.

The work here (https://chromium-review.googlesource.com/c/chromium/src/+/1318054) and followup patches will enable a fairly easy solution, right?

I'm not sure whether it would be worth shipping an origin trial without support on mobile. +Jason to see whether he thinks that would potentially be reasonable.

Just chatted with Jason - it sounds like there's precedent for shipping an origin trial desktop only. I think it makes sense to push for this.

Discussed offline with Tim. In short, it seems reasonable to run an origin trial that is not available on mobile, if you think you can get useful feedback from desktop only. There is precedent for such trials, and the OT framework allows configuring a trial to be available only on specific platforms.

Great!

> The work here (https://chromium-review.googlesource.com/c/chromium/src/+/1318054) and followup patches will enable a fairly easy solution, right?

It depends on whether or not it becomes possible to perform all steps up to (and including) frame attribution on the compositor thread.

+Dave, does this sound reasonable to you? Our goal with the current implementation is to be able to tell if the compositor has received a WebInputEvent in a frame without yielding the event loop from client JS.

Hey all, tackling and demonstrating wins on mobile is critical for the web platform scheduling effort.
Let's discuss what we need to do to make this work, rather than punting on mobile.

Shubhie, why do you think having support for mobile in the origin trial is required?

We plan to ship on all platforms, this just lets us get the OT out the door sooner. Are there specific things you're hoping to learn about this API via OT that are mobile specific?