On 12/08/2017 09:21 AM, Bevis Tseng wrote:
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,
Just a small correction, we have had the correct microtask handling since the
beginning of microtasks.
It has been used with MutationObserver.
Then later another different mechanism, also called microtask internally was
added for Promises, but
it did something very different to the original microtask handling.
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
