Bug 164193 – Implement requestIdleCallback

• Status: RESOLVED
• Resolution: FIXED
• Component: DOM

[Simon Fraser (smfr)]

We should implement requestIdleCallback. IntersectionObserver makes use of it.

[Ms2ger (he/him; ⌚ UTC+1/+2)]

Created attachment 320005 [details]
WIP (bindings only)

[Jon Lee]

rdar://problem/22900866

Can we get this properly implemented? More and more sites are starting to rely on this.
Currently enabling it as an experimental feature breaks a bunch of stuff (like the ability to log into your gmail account).

Thanks.

[Simon Fraser (smfr)]

Can you list some sites that use it?

Sure: gmail.com, netflix.com, microsoft.com, amazon.com, tripadvisor.com, urbandictionary.com, nypost.com, groupon.com, primevideo.com, …

Certain web based software has started to require it (as in won't work without), such as Tiny Tiny RSS.

[Alexandre Dieulot]

This has been available in both Chrome and Firefox for 4.5 years. This was listed in WebKit’s 2020 goals under the “Catchup” session. It’s weird for the browser most aggressively marketing its speed not to have that API.

I don’t have any numbers on how useful it is in the wild, but a Google engineer that went all-in with rAF got a two-third reduction in first input delay for the worst 1% of cases and 20% reduction for the worst 5% on a JS-light site in late 2018: https://philipwalton.com/articles/idle-until-urgent/#how-much-does-this-actually-improve-performance%3F

[Tyler Gross]

It's worth noting that React heavily relies on requestIdleCallback for scheduling. If requestIdleCallback is missing, then React falls back to setTimeout, which can lead to running much more code than is necessary.

Sources:
https://github.com/facebook/react/blob/c7ce0091dcb2036e19df980247c9a4388ad75741/packages/shared/ReactDOMFrameScheduling.js#L71
https://twitter.com/dan_abramov/status/962810069510492167?lang=en

[Sam Sneddon [:gsnedders]]

(In reply to Tyler Gross from comment #7)
> It's worth noting that React heavily relies on requestIdleCallback for
> scheduling. If requestIdleCallback is missing, then React falls back to
> setTimeout, which can lead to running much more code than is necessary.
> 
> Sources:
> https://github.com/facebook/react/blob/
> c7ce0091dcb2036e19df980247c9a4388ad75741/packages/shared/
> ReactDOMFrameScheduling.js#L71
> https://twitter.com/dan_abramov/status/962810069510492167?lang=en

This is apparently no longer true: https://github.com/facebook/react/issues/13206#issuecomment-418417892

[Alexandre Dieulot]

May we know what’s blocking WebKit from shipping requestIdleCallback, if anything? Has it just been utterly deprioritized? Nearly all the dependencies of this ticket haven’t moved in the last three years. It’s bewildering.

[Michael Catanzaro]

This is now required by github.com to set labels in pull requests. WebKit development moved to github.com and landing changes depends on setting a label, so for us to continue to develop WebKit we now need to use Firefox or another non-WebKit browser to land pull requests.

Exception: it seems to work in Safari even without requestIdleCallback, but we don't know why. I initially assumed that GitHub was doing user agent header shenanigans to avoid this API when the browser is Safari, but that does not seem to be it.

[Michael Catanzaro]

So Ms2ger's patch from five years ago provides a starting point.

We will need four different implementations for four different platform event loops:

 * Windows
 * Cocoa (uses CFRunLoop) 
 * GLib (uses GMainContext/GMainLoop)
 * Generic

The generic RunLoop currently has no concept of priority, but we could add one.

For GLib it's easy, because the concept of idle dispatch maps directly to G_PRIORITY_DEFAULT_IDLE.

For Cocoa, CFRunLoop supports CFRunLoopMode. I guess we could use a special mode and dispatch it only when no events for other modes are pending? I'm not sure.

For Windows, I did not investigate because the implementation looks gnarly. It looks to be based on a "message window" concept that is quite different from GMainContext/GMainLoop or CFRunLoop.

[Michael Catanzaro]

So assuming we add idle-priority execution to RunLoop, then the cross-platform implementation would be:

 * If no timeout is specified, attach a RunLoop task at idle priority
 * If a timeout is specified, then attach two RunLoop tasks: one at idle priority and one using Timer.startOneShot(). Whichever task executes first should cancel the other.

That would be needed in DOMWindow, where Ms2ger's patch provides us with empty stubs.

All this assumes that "run task at idle priority" is actually a valid way to decide when the browser is idle, but I think it probably is. The browser might be doing more stuff on secondary threads, but the main thread is definitely idle. Only problem could be if a secondary thread is doing something that will imminently cause a task to post to the main thread. WebKit developers might know that something important might be about to happen, but the RunLoop isn't smart enough to avoid this. So perhaps we might theoretically want to have "blackout" times when idle callbacks are not dispatched. But that adds extra complexity and I don't know when those times would be, so this is probably not part of the minimal viable solution.

(Honestly, the minimal viable solution would be to implement it equivalent to setTimeout(0), but it's not hard to do better.)

[Michael Catanzaro]

> Only problem could be if a secondary thread is doing something that will imminently cause a task to post to the main thread.

Actually, it's also possible that higher-priority timeouts are already scheduled on the main thread that might be about to post. That could be detected automatically by implementing a rule that idles do not dispatch if a timeout is scheduled within the next n milliseconds. But if we set n too high then we could accidentally denial of service every idle callback, so not sure it's a good idea, probably again not part of the minimal viable solution. I'm inclined to ignore all of this and schedule the idle callbacks whenever there is no other non-idle priority source to be dispatched on the current run loop iteration. Simple is often best; if it doesn't work well in practice, then we can deal with added complexity later on.

[Michael Catanzaro]

(In reply to Alexandre Dieulot from comment #9)
> May we know what’s blocking WebKit from shipping requestIdleCallback, if
> anything? Has it just been utterly deprioritized? Nearly all the
> dependencies of this ticket haven’t moved in the last three years. It’s
> bewildering.

Well nobody has submitted any pull requests. It won't fix itself; help welcome.

Anyway, good thing you pointed me to the dependent issues, because now I see there is the DOM-level EventLoop.cpp, WindowEventLoop.cpp, WorkerEventLoop.cpp, which I didn't know about. I had only been thinking in terms of RunLoop.cpp. Since it's a wrapper over Timer and RunLoop, I had hoped that maybe it's just one more layer to deal with, but nope there's a complicated specification at https://html.spec.whatwg.org/multipage/webappapis.html#event-loops which I haven't read and which should ideally be understood before proceeding. But it looks seriously complicated, and I don't have enough time or expertise to understand it, so I won't try. (Then there's also a request idle callback specification https://w3c.github.io/requestidlecallback/ but fortunately that one is simple and more or less exactly what I expected.)

Regarding the dependent issues: maybe these are required to implement that event loop spec as expected, but frankly I only have a couple afternoons to spend on this and I only care about being able to create pull requests on github.com and nothing else, so I'm going to ignore those. ;) None look required for a minimum viable implementation. Bug #203137 is about timers and not idles, bug #203667 is about media loading, bug #203840 is basically what I wrote in comment #13 above, and bug #206676 is about a test that fails because this API doesn't exist yet.

[Michael Catanzaro]

Oh, maybe I should look at the *closed* dependent bugs. Finally I see that Ryosuke has already landed most of the work, e.g. in https://trac.webkit.org/changeset/251050/webkit, including everything that I had planned to look into. But the feature is disabled (presumably due to the warning in comment #3). OK.

So I think next step is to expose this only for github.com for starters, to avoid breaking other websites before Ryosuke thinks it is ready. I don't think we actually have capability to enable DOM APIs via quirks currently. Will report a separate bug for this.

Hopefully this concludes my Bugzilla conversation with myself.

[Sam Sneddon [:gsnedders]]

(In reply to Michael Catanzaro from comment #15)
> Oh, maybe I should look at the *closed* dependent bugs. Finally I see that
> Ryosuke has already landed most of the work, e.g. in
> https://trac.webkit.org/changeset/251050/webkit, including everything that I
> had planned to look into. But the feature is disabled (presumably due to the
> warning in comment #3). OK.

Yes, a bunch has landed, but there's also various things that per spec should go via the event loop but don't in WebKit (see the open dependent bugs), which means we will quite often (with the current off-by-default implementation) fire the callback prior to actually being idle. We've been pretty conservative here, not wanting to expose it while it still has obviously different timing characteristics to other engines; that said, it probably is no worse than setTimeout(…, 0) today?

> So I think next step is to expose this only for github.com for starters, to
> avoid breaking other websites before Ryosuke thinks it is ready. I don't
> think we actually have capability to enable DOM APIs via quirks currently.
> Will report a separate bug for this.

See EnabledByQuirk/DisabledByQuirk IDL extended attributes; you probably just want to define a quirk for GitHub and use that? That said, given GitHub _does_ work on Safari this should probably only enable it on the platforms where it is currently broken.

[Michael Catanzaro]

(In reply to Sam Sneddon [:gsnedders] from comment #16)
> Yes, a bunch has landed, but there's also various things that per spec
> should go via the event loop but don't in WebKit (see the open dependent
> bugs), which means we will quite often (with the current off-by-default
> implementation) fire the callback prior to actually being idle. We've been
> pretty conservative here, not wanting to expose it while it still has
> obviously different timing characteristics to other engines; that said, it
> probably is no worse than setTimeout(…, 0) today?

Right, so I see now that the challenge here is not requestIdleCallback itself but  rather the DOM EventLoop portion of the HTML spec, which WebKit previously had no concept of. Looks like that all is fairly new and not quite right yet. I would have hoped that getting things not exactly right would be no worse than setTimeout(…, 0) but there is a warning in comment #3 indicating otherwise, so I guess we need to be careful here.

> See EnabledByQuirk/DisabledByQuirk IDL extended attributes; you probably
> just want to define a quirk for GitHub and use that? That said, given GitHub
> _does_ work on Safari this should probably only enable it on the platforms
> where it is currently broken.

Looks like exactly what I want. Thanks. Whether to limit the quirk to specific ports or not, I'm not sure. (There are risks either way, but at least they'll only affect github.com.)

[Michael Catanzaro]

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.

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #18)
> 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.)

Hm, this is probably already possible by continuously using setTimeout/setInterval(..., 0).

Seems that Safari 16.4 even removed this from the experimental features, effectively leaving Safari broken with no recourse.

Going on 6+ years now, absolutely mind-boggling…

[Michael Catanzaro]

Please only comment here if you are a developer with helpful information to add; otherwise, this bug will grow to the point where it becomes difficult to keep track of the previous comments.

[Anne van Kesteren]

This was finished for Apple ports in bug 260369. Linux ports are tracked in bug 260478.

[Daniel]

Created attachment 469554 [details]
Video showing how requestIdleCallback fires after a minute on an empty page, should fire directly

[Daniel]

Created attachment 469555 [details]
A real world example that shows how image loading is delayed too far, due to requestIdleCallback being buggy

[Daniel]

Hello, first of all: AMAZING that Safari is finally getting requestIdleCallback (referring to https://bugs.webkit.org/show_bug.cgi?id=260369).

However, it unfortunately doesn't seem to work as expected. It's quite glitchy and sometimes never fires, even when the browser is obviously completely idle. I got it to fire in Safari Version 17.2.1 (19617.1.17.11.12) after enabling the feature flag and going to page that uses it, then to another one, then back again.

In Safari Technology Preview (Release 187 (Safari 17.4, WebKit 19619.0.1.2)) where it's enabled by default, it doesn't seem to work at all (or is *very* spotty). To illustrate this example, creating a totally blank index.html file and then running requestIdleCallback inside it would be expected to fire immediately, like it does in Firefox and Chrome. In Safari however it seems to sometimes fire after a minute, even after disabling all browser extensions (see attached video).

As for a real world example:
If you go to https://singular-society.com/search?q= all but the first 8 images are loaded using requestIdleCallback. This increases performance when scrolling down, as the product cards are fairly complex and contain many images.

If you visit the page in chrome and scroll down ~20 images, you will notice that the loading of the images is delayed a bit to keep the browser smooth but they still load really quickly. If you visit it in safari technology preview, the images don't load at all for minutes (seems to only sometimes happen. Try: after a fresh browser start, first go to singular-society.com and then click on the search icon and then press enter, then scroll down a bit). (See also attached video)

[Michael Catanzaro]

Please create a new bug report. You can link to this one using the See Also field.

[Daniel]

Ok, opened https://bugs.webkit.org/show_bug.cgi?id=268152