is-input-pending

is-input-pending copied to clipboard

Apologies for not raising this sooner...

This API would encourage developers to have long running tasks with some guarantee that they won't interrupt user input. Should we still be reporting such Long Tasks as something to be discouraged?

Are there scenarios where such long tasks can hurt the user's experience that are not input related? If we want to encourage developers to use the "long interruptible task" pattern, how can we exclude such tasks from LT reporting?

^^ @npm1 @philipwalton

If the site is performing animations or such, longtasks would still present unoptimal experiences to the user, no? One idea is to expose whether isInputPending was called during the longtask, and then the developer can choose to interpret the information accordingly.

+1 to @npm1's suggestion.

If you're going to run a long task and only yield on input, I think the developer should still have signal to ensure they aren't harming the experience otherwise (which I think reporting on the performance timeline does a good job of).

The other thing is: there are currently RUM providers which provide metrics based on longtasks. Given that, do we need to ship the new API with the solution to this problem at the same time? This question of course, is ignoring the shape of the solution (which I already gave my opinion on).

+1 to exposing whether isInputPending was called during the long task. I think it's still valuable for sites that use isInputPending to know about these long tasks, even if they don't directly harm UX on the site. It could be the long tasks are unexpected for a different reason and indicate some other problem, such as inefficient or broken code. Also, a long task that does not delay inputs can still be a problem for CPU or battery life.

I do worry that this API will give a false sense of security wrt task length. As @npm1 mentioned, there are other reasons to yield, and importantly IIUC there are also situations where isInputPending might return false negatives, e.g. for background pages that are sharing a process with foreground pages. That concern came up recently in conversations with Google Docs folks. Anyways, I do agree that we should continue to report long tasks even if they call isInputPending, and +1 to the additional annotation.

Given that, do we need to ship the new API with the solution to this problem at the same time? This question of course, is ignoring the shape of the solution (which I already gave my opinion on).

I'd be curious about the prevalence of the false positive cases described. For React's case, concurrent mode is actually quite uncommonly used, since it isn't quite ready for prime time yet (however, it becomes more viable with isInputPending).

And like @shaseley said, having the UA "bless" certain long tasks is problematic as well, particularly when incidentally calling isInputPending in an otherwise ill-behaved long task. Consider the case where a scheduler executed a poorly behaved work item -- it'll still call isInputPending, but we'll fail to acknowledge the fact that we blocked for a long time between these yield checks.

I mentioned this issue over in the Long Tasks V2 API discussion doc. There is definite tension between the long task API and use of isInputPending. React concurrent mode will land one of these days (😁 ) and this issue will become more front and center.