Closed szager-chromium closed 4 years ago
I think it's worth noting that this violates one of the TAG's API design principles on run-to-completion semantics. I think this sort of explicit violation of the principle is probably less problematic than a less visible one, and it's possible we might agree that the principle needs similar edits to the ones made to a different principle in w3ctag/design-principles#129.
(Actually, maybe I was thinking of isInputPending
, and isFramePending
perhaps doesn't have that problem?)
It seems to depend on how it's defined. In particular, if this loop ever terminates, then it breaks run to completion:
while (!navigator.scheduling.isFramePending) {
// do some work
}
The explainer seems to indicate that this loop will break, i.e., something from another thread can cause this value to change.
This would violate run-to-completion in the same way as isInputPending. The two API's will sink or swim together on this point.
For what it's worth, I don't see a TAG review for isInputPending
(although maybe it has some other name?).
@hober and I are looking into this in a breakout at the TAG face-to-face meeting.
So far, just noting that there's some interesting discussion in the discourse thread.
@hober @plinss and I are looking at this again at our Cupertino face-to-face meeting, and we pulled in @smfr since he's here.
One of the things that came out of the discourse thread mentioned in the previous comment that we discussed a bit is that it sounds like the intent (although that isn't clear from the explainer, and probably should be!) is that isFramePending
should become true as a result of some vsync trigger that comes from the OS, not as a result of the JS that dirties the DOM or style that ends up triggering the need for a repaint. This actually makes me a little bit more worried about interoperability here: it's not clear to me how interoperably those OS signals are defined, whether they behave in different ways on different platforms, e.g., how much does the time between when isFramePending
becomes true and when the main-thread rendering is done vary between platforms? how much does this differ for a page in a background tab? also, when does isFramePending
become unset?
We also talked a little bit about whether there are :visited
link history-sniffing attacks that would result from this. My assertion was that it didn't seem like a big deal because we should be attempting to audit from the side of not having different performance characteristics whether or not links are visited. But @smfr pointed out that there could be optimizations (e.g., those based on display-list diffing) that might need to be disabled in that case, and which could (depending on how it's defined) affect whether isFramePending
is true.
It might help the review progress a bit if the explainer tried to flesh out the answers to these questions a little bit more. And if you do update the explainer in response to this, please ping us in this issue so we know to take another look at it.
@hober and I are looking at this in our "Cork" virtual face-to-face. The "Progress: stalled" state still seems accurate, at a minimum given the state of szager-chromium/isFramePending#3
We're no longer working on this proposal, I think it's ok to close. @szager-chromium ok by you?
Yes, closing.
こんにちはTAG!
I'm requesting a TAG review of:
Further details:
We'd prefer the TAG provide feedback as (please select one):