Closed rmcilroy closed 9 years ago
I guess this would be equivalent to adding an handler to the onunload (or onbeforeunload) event, which is canceled if the callback get's triggered through other means (much like the current optional timer parameter is equivalent to a cancelable setTimeout). You could build this manually, but it might be nice to have it built-in to the API like the timeout parameter.
@igrigorik @toddreifsteck any thoughts?
We don't have this kind of params for setTimeout either. pagehide/unload/beforeunload event listeners cover this case just fine.
I wouldn't complicate the API with this kind of optional param.
I wouldn't complicate the API with this kind of optional param.
+1. I can imagine many cases where forcing the requestIdle callback during this part of app's lifecycle is pure overhead. If you care about pagehide/onunload then you should handle those cases explicitly.
:-1: I agree with @smaug---- and @igrigorik that this is out of scope.
Great, I was hoping this would be the consensus to avoid overcomplicating the API. Closing this issue.
Suggestion from junov@chromium.org:
There does not seem to be any provision for guaranteeing that the user agent will execute an idle callback. To be more specific, the optional deadline argument does not guarantee that the callback will be executed before the script execution context is destroyed. It would be nice to be able to provide some guarantee of execution. Without that guarantee, one would not want to implement any critical task (like saving user data) using idle callbacks.