[Webkit-unassigned] [Bug 164193] Implement requestIdleCallback

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=164193

Michael Catanzaro <mcatanzaro at gnome.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|253758                      |

--- Comment #18 from Michael Catanzaro <mcatanzaro at gnome.org> ---
My understanding is still limited, but here are some more considerations I've been thinking about:

 * There are multiple WindowEventLoops/WorkerEventLoops per underlying RunLoop, one per security origin, and they can know when they are themselves in idle periods, but they cannot know about the idle periods of other EventLoops running on the same RunLoop. Therefore they do not know when the underlying RunLoop is truly idle and idle work will be scheduled during non-idle times.
 * They schedule work on the underlying RunLoop always using default priority callbacks, not idle priority callbacks, because RunLoop doesn't expose the concept of idle priority callbacks. Everything scheduled using the cross-platform RunLoop interface is currently default priority.
   * For most ports this just means the callbacks will be scheduled during non-idle times, not ideal but probably not harmful.
   * But for WPE/GTK it additionally means that idle callbacks of the EventLoop will actually delay execution of all work scheduled by application-level idle callbacks until the next run loop iteration. I think a website can perform a denial of service against application-level idle callbacks in the web process by simply always ensuring that at least one requestIdleCallback is scheduled. (The lower-priority callbacks never dispatch when a higher-priority callback is scheduled.)
 * So we should consider implementing idle priority for the underlying RunLoop (comment #11) so we can schedule the requestIdleCallback when the underlying RunLoop is actually idle

I'll also note that the EventLoop spec is seriously complex and I'm not sure how realistic it is to fully implement it. This affects basically everything and is alien to how WebKit works today. So if we're aiming for full spec compliance before we ship requestIdleCallback, I suspect it's going to be a very, very, very long wait. We might want to ship requestIdleCallback much sooner as long as it's not breaking websites in practice (which it currently does, comment #3).

(In reply to Michael Catanzaro from comment #10)
> This is now required by github.com to set labels in pull requests.

Um, it seems this is no longer required after fixing bug #211979, so this is no longer an emergency. I'll remove the dependent bug.


Referenced Bugs:

https://bugs.webkit.org/show_bug.cgi?id=253758
[Bug 253758] ☂️ [GTK][WPE?] GitHub breaks in different ways after their March 2023 update
-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20230316/7cc812b8/attachment.htm>