Deferred: Deprecate setTimeout() usage under latest browsers.

[diegocr]

Summary

Hi there, as you may know, Chrome/ium has been lately aggressively throttling background tabs, this may result in those setTimeout()-based promises/deferreds to never resolve until the tab becomes active again.

This PR is an attempt to prevent that, by using queueMicrotask under browsers supporting it. Also, the logic has been changed to dispatch those processes in bulk instead of individually, since the main reason for that throttling seems to be by having too many concurrent setTimeout()s running.

This implements a new jQuery.asap() function that will use either queueMicrotask or setTimeout for older browsers.

I've observed that around this whole codebase there are several other uses of that window.setTimeout( func ) pattern so perhaps I should move this jQuery.asap() elsewhere to be used in place of those as well (as part of another PR) ?

Thanks!

Checklist

• New tests have been added to show the fix or feature works
• Grunt build and unit tests pass locally with these changes
• If needed, a docs issue/PR was created at https://github.com/jquery/api.jquery.com

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: diegocr / name: Diego Casorran (813b77c)

[mgol]

Thanks for the PR. Please fix the reported ESLint violations. Also, we don't want to expose a new method, please keep it internal. Once that's done, we should see the actual test suite running.

Also, do we need a manual queue when using queueMicrotask? Won't the browser manage such a queue by itself?

[diegocr]

Hi, thank you, pleased you guys are positive about those kind of changes.

Well, the manual queue for queueMicrotask can be seen as subjective yes, i think it could help the browser but probably we won't prevent much overhead there. Also, i was expecting it'd be fine exposing a method so that for example i could then replace it with my own scheduler. If these are no-go then we can simplify this a lot, will now proceed to do so.

[mgol]

@diegocr you need to rebase the PR to avoid the issues on main as they have recently been fixed.

[diegocr]

Cool, done 🚀

[mgol]

Sorry for a late review. I have one doubt about the testing strategy.

[mgol]

Why mocking jQuery.readyException? Can't this test be done in a similar way as the setTimeout one? In that case, maybe we could just keep a single test?