Simplify Blink <-> V8 Microtask queue running protocol

Simplify Blink <-> V8 Microtask queue running protocol

V8 now implements Isolate::RunMicrotasks() in C++, which means its callers
no longer need to enter V8 Context::Scope before calling it. This simplifies
WebCore::Microtask::performCheckpoint, and gets us one step closer to ditching
V8PerIsolateData::ensureDomInJSContext().

This patch also gets rid of most of the microtask-related logic in
ScriptPromiseResolverWithContext, allowing WebCore::Microtask::performCheckpoint
to be the only code in Blink that calls Isolate::RunMicrotasks().
Instead of triggering microtask delivery directly, or via the RunMicrotasksTask,
ScriptPromiseResolverWithContext now utilizes V8RecursionScope to "simulate"
a JavaScript stack (from Blink's point of view). In workers, this will
result in a RunMicrotasks() call when the V8RecursionScope is destructed.

There are still two FIXMEs:
  - The V8RecursionScope discussed above would be unnecessary if there were
    a WebThread::TaskObserver on worker threads to handle microtask-running
    at the end of each task.
  - ensureDomInJSContext() is still needed in order to instantiate the v8::Functions
    that are passed into Isolate::EnqueueMicrotask(). Fixing this will require
    more work on the V8 side to allow passing in a C++ callback directly.

BUG=374772
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=174987

[adamk, 2014-05-28 01:50:18]

The failure in fast/css/fontface-methods.html is "real", in that it fails with
this patch applied and passes otherwise. But the actual failure seems
timing-related: the test is asserting that the FontFace status is "loading", but
it's already "loaded" by the time the test checks it (this is for face3).
+ksakamoto in case he can help explain why this CL might affect that test.

[Kunihiko Sakamoto, 2014-05-28 06:25:39]

On 2014/05/28 01:50:18, adamk wrote:
> The failure in fast/css/fontface-methods.html is "real", in that it fails with
> this patch applied and passes otherwise. But the actual failure seems
> timing-related: the test is asserting that the FontFace status is "loading",
but
> it's already "loaded" by the time the test checks it (this is for face3).
> +ksakamoto in case he can help explain why this CL might affect that test.

Interesting.
https://codereview.chromium.org/300683011/ fixed the test failure on my machine,
but I'm nut sure why this patch changed loading behavior.

[jochen (gone - plz use gerrit), 2014-05-28 12:18:43]

it's not that surprising, as this CL changes the ordering when the promise tasks
are executed.

I think it's just exposing a pre-existing flakiness.

anyway, lgtm

[adamk, 2014-05-28 18:18:48]

The CQ bit was checked by adamk@chromium.org

[commit-bot: I haz the power, 2014-05-28 18:19:08]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/adamk@chromium.org/303693005/1

[adamk, 2014-05-28 18:19:18]

On 2014/05/28 06:25:39, Kunihiko Sakamoto wrote:
> On 2014/05/28 01:50:18, adamk wrote:
> > The failure in fast/css/fontface-methods.html is "real", in that it fails
with
> > this patch applied and passes otherwise. But the actual failure seems
> > timing-related: the test is asserting that the FontFace status is "loading",
> but
> > it's already "loaded" by the time the test checks it (this is for face3).
> > +ksakamoto in case he can help explain why this CL might affect that test.
> 
> Interesting.
> https://codereview.chromium.org/300683011/ fixed the test failure on my
machine,
> but I'm nut sure why this patch changed loading behavior.

Ah, thanks, with your patch applied the test passes.

[commit-bot: I haz the power, 2014-05-28 19:37:31]

Change committed as 174987