navigator.scheduling.isFramePending

[szager-chromium]

こんにちはTAG!

I'm requesting a TAG review of:

• Name: navigator.scheduling.isFramePending
• Explainer: https://github.com/szager-chromium/isFramePending/blob/master/explainer.md
• GitHub issues: https://github.com/szager-chromium/isFramePending/issues
• Primary contacts (and their relationship to the specification): szager-chromium@github (owner), shaseley@github (secondary)

Further details:

• Relevant time constraints or deadlines: [please provide]
• I have read and filled out the Self-Review Questionnare on Security and Privacy. Here are the answers.
• I have reviewed the TAG's API Design Principles
• The group where the work on this specification is: WebPerf?

We'd prefer the TAG provide feedback as (please select one):

• open issues in our GitHub repo for each point of feedback

[dbaron]

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.

[dbaron]

(Actually, maybe I was thinking of isInputPending, and isFramePending perhaps doesn't have that problem?)

[domenic]

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.

[szager-chromium]

This would violate run-to-completion in the same way as isInputPending. The two API's will sink or swim together on this point.

[dbaron]

For what it's worth, I don't see a TAG review for isInputPending (although maybe it has some other name?).

[dbaron]

@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.

[dbaron]

@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.