Hi Everyone, Microtask is a fundamental piece of the EventLoop defined in HTML standard to allow algorithms to run something asynchronously that was just settled asap without the latency of enqueuing a new task. The most well-known use cases of Microtasks are Promises, await of async function and MutationObservers. After Bug 1193394 <https://bugzilla.mozilla.org/show_bug.cgi?id=1193394> revealed the problem about how Firefox performs microtasks differently from what has be specified in HTML standard, we've spent some time since the end of last year to push this forward by providing a correct microtask scheduling (Thanks Olli(:smaug) for the major work of the new scheduling patch) and fixing the test failures in our implementation discovered by the scheduling change. Good news is that we have all WPT green now plus removing some expected failures. However, we still have some failures <https://bugzilla.mozilla.org/show_bug.cgi?id=1193394#c62> in chrome test, mochitest, bc, dt and mda. I'd like to say thanks here again to Tooru(:arai) and Hiroyuki(:hiro) who have helped to clean up a lot of failures in browser-chrome and dom/animation.
However, after more tests were fixed, more concern is raised to remind me to write this mail to tell everyone the story why you should understand more about the microtask algorithm defined in the event loop of HTML and how different it is performed in current m-c, so each module owner could spend some time to review if your implementation will be compatible with the new scheduling even though there might be no test failure captured on try when new scheduler is applied. You can read the attached slides to understand more about the difference: [image: Google Slides] Microtask checkpoints <https://docs.google.com/a/mozilla.com/presentation/d/1momsC3suU8m-CrdZyYD_6QATATehjzZHbkGmL6KsmSk/edit?usp=drivesdk> In short, inside Firefox, 1. There are 2 queues for different types of microtasks instead of single queue: - One is for MutationObservers while the other is for Promise callbacks. - The Promise one is performed after the Mutation one is done. 2. For the Promise one, a. we don't perform microtask at the end of a JS callback or an event listener but perform only at the end of current task. b. there is no reentrant check of performing microtask checkpoint. 3. Some implementation heavily relies on the executing order of current scheduling between MutationObservers and Promise callbacks. Hence, everyone shall be aware that 1. It shall be possible to reenter immediately to your implementation from a JS callback or an even listener instead of being accessed at the end of current task especially if your test cases are only written with promises or *await* async function without the awareness of the re-entrant problems. 2. There is no particular order between mutation observers and promise callbacks. They shall be consumed in FCFS order in a single queue. Some people might ask why we didn't land this fix to m-c directly or land it but disable it by default to fix it gradually: 1. We have done some experiments and we found that replacing the scheduler is risky which cause several crashes and function broken due to the expectation of the behavior in old scheduling. 2. In addition, it make the new scheduling un-maintainable and unreadable if we use the new scheduler to simulate the old behavior. (See bug 1420816 <https://bugzilla.mozilla.org/show_bug.cgi?id=1420816#c9>) 3. We should fix them as soon as we can instead of fixing it gradually. Otherwise, without test coverage before landing this main patch, we expect more failures to be suppressed while adding new features or more WPT failures contributed by other vendors which is expected to be passed in correct scheduling approach. We still have several failures open without assignee yet and I will keep updating the rebased patches with try results weekly for tracking: Bug 1414170 <https://bugzilla.mozilla.org/show_bug.cgi?id=1414170>: Fix failure in toolkit/components/extensions/test/mochitest/ that replies non-comformant Promise handling Bug 1414176 <https://bugzilla.mozilla.org/show_bug.cgi?id=1414176>: Fix failure WebRTC tests relying on non-comformant Promise handling Bug 1414177 <https://bugzilla.mozilla.org/show_bug.cgi?id=1414177>: Fixed failed tests in devtools which relies on non-comformant Promise handling Bug 1415781 <https://bugzilla.mozilla.org/show_bug.cgi?id=1415781>: Fix failure in layout/style/test/chrome/ relying on non-comformant Promise handling Bug 1415787 <https://bugzilla.mozilla.org/show_bug.cgi?id=1415787>: Fix failure in dom/svg/test/test_tabindex.html on OSX with comformant Promise handling Bug 1415791 <https://bugzilla.mozilla.org/show_bug.cgi?id=1415791>: Fix failure in dom/presentation/tests/mochitest/ on Win7-non-e10s with comformant Promise handling Bug 1415793 <https://bugzilla.mozilla.org/show_bug.cgi?id=1415793>: Fix failure of mobile/android/components/extensions/test/mochitest/test_ext_activeTab_permission.html relying on non-comformant Promise handling Bug 1415796 <https://bugzilla.mozilla.org/show_bug.cgi?id=1415796>: Fix failure of mobile/android/tests/browser/chrome/test_session_form_data.html relying with comformant Promise handling Bug 1415797 <https://bugzilla.mozilla.org/show_bug.cgi?id=1415797>: Fix failures in dom/network/tests/ with comformant Promise handling It's really appreciated if there are experts in these failed modules to look into it because the root cause might not only be the test failure itself but the wrong implementation relying on the old scheduling behavior. Then, additional migration work is required to make it behave correctly in both new/old scheduling to allow the main patch to be landed after all these failure are fixed. BTW, if you need face to face discussion during Austin All Hands, please feel free to ping me on irc (:bevis). Thanks, Bevis Tseng _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
