Introduce animation frame tasks

Introduce animation frame tasks

This will be used to fix the timing of Fullscreen state transitions and
events. In the spec, it is still acknowledged that "Animation frame task
is not really defined yet, including relative order within that task":
https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen

However, this matches the order in HTML, where "run the fullscreen
rendering steps" comes after various events and before "run the
animation frame callbacks":
https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model

It would have to be HTML that defines "animation frame task" for the
integration with Fullscreen to really make sense, tracked by:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28001

BUG=402376
Committed: https://crrev.com/0428d2791da252d73049587ac6bd4fa1610f6734
Cr-Commit-Position: refs/heads/master@{#436670}

[Sami, 2016-11-28 15:50:27]

skyostil@chromium.org changed reviewers:
+ skyostil@chromium.org

[Sami, 2016-11-28 15:50:27]

https://codereview.chromium.org/2536643002/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/dom/ScriptedAnimationController.cpp (right):

https://codereview.chromium.org/2536643002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/dom/ScriptedAnimationController.cpp:85: //
TODO(foolip): can running a task append to the task queue?
FWIW I'd suggest they get added to the queue for the *next* frame, which is how
rAF works.

[foolip, 2016-12-06 14:00:30]

Description was changed from

==========
Introduce animation frame tasks

BUG=
==========

to

==========
Introduce animation frame tasks

This will be used to fix the timing of Fullscreen state transitions and
events. In the spec, it is still acknowledged that "Animation frame task
is not really defined yet, including relative order within that task":
https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen

However, this matches the order in HTML, where "run the fullscreen
rendering steps" comes after various events and before "run the
animation frame callbacks":
https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-...

It would have to be HTML that defines "animation frame task" for the
integration with Fullscreen to really make sense, tracked by:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28001

BUG=402376
==========

[foolip, 2016-12-06 14:00:52]

The CQ bit was checked by foolip@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-06 14:01:09]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[foolip, 2016-12-06 14:01:22]

https://codereview.chromium.org/2536643002/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/dom/ScriptedAnimationController.cpp (right):

https://codereview.chromium.org/2536643002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/dom/ScriptedAnimationController.cpp:85: //
TODO(foolip): can running a task append to the task queue?
On 2016/11/28 15:50:27, Sami wrote:
> FWIW I'd suggest they get added to the queue for the *next* frame, which is
how
> rAF works.

I have made it so and written tests, can you PTAL?

[Sami, 2016-12-06 14:32:50]

lgtm.

https://codereview.chromium.org/2536643002/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/dom/ScriptedAnimationController.h (right):

https://codereview.chromium.org/2536643002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/dom/ScriptedAnimationController.h:61: void
enqueueTask(std::unique_ptr<WTF::Closure>);
It might be nice to have a short comment here as a reminder of what these tasks
are and when they run.

[commit-bot: I haz the power, 2016-12-06 16:09:15]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-06 16:09:15]

Dry run: This issue passed the CQ dry run.

[foolip, 2016-12-06 16:32:06]

The CQ bit was checked by foolip@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-06 16:32:31]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[foolip, 2016-12-06 16:32:33]

https://codereview.chromium.org/2536643002/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/dom/ScriptedAnimationController.h (right):

https://codereview.chromium.org/2536643002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/dom/ScriptedAnimationController.h:61: void
enqueueTask(std::unique_ptr<WTF::Closure>);
On 2016/12/06 14:32:50, Sami wrote:
> It might be nice to have a short comment here as a reminder of what these
tasks
> are and when they run.

I added some documentation, please shout if it's not good :)

[foolip, 2016-12-06 16:40:18]

The CQ bit was checked by foolip@chromium.org

[foolip, 2016-12-06 16:40:20]

The patchset sent to the CQ was uploaded after l-g-t-m from
skyostil@chromium.org
Link to the patchset: https://codereview.chromium.org/2536643002/#ps60001
(title: "drop 'the'")

[commit-bot: I haz the power, 2016-12-06 16:40:31]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[foolip, 2016-12-06 16:42:12]

foolip@chromium.org changed reviewers:
+ atotic@chromium.org

[foolip, 2016-12-06 16:42:13]

atotic@, FYI, here are the animation frame tasks we discussed when I was in MTV.
I think that it'd be nice to merge the queue for events with this, and of course
to make the same kind of changes in spec land.

[commit-bot: I haz the power, 2016-12-06 19:01:33]

CQ is committing da patch.

Bot data: {"patchset_id": 60001, "attempt_start_ts": 1481042418241300,
"parent_rev": "3eb765dd03d144fb28e0f19d1b22511618b5a07c", "commit_rev":
"8263019dcbde24c7c0c3f853cb6c0921b331fb01"}

[commit-bot: I haz the power, 2016-12-06 19:04:46]

Description was changed from

==========
Introduce animation frame tasks

This will be used to fix the timing of Fullscreen state transitions and
events. In the spec, it is still acknowledged that "Animation frame task
is not really defined yet, including relative order within that task":
https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen

However, this matches the order in HTML, where "run the fullscreen
rendering steps" comes after various events and before "run the
animation frame callbacks":
https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-...

It would have to be HTML that defines "animation frame task" for the
integration with Fullscreen to really make sense, tracked by:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28001

BUG=402376
==========

to

==========
Introduce animation frame tasks

This will be used to fix the timing of Fullscreen state transitions and
events. In the spec, it is still acknowledged that "Animation frame task
is not really defined yet, including relative order within that task":
https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen

However, this matches the order in HTML, where "run the fullscreen
rendering steps" comes after various events and before "run the
animation frame callbacks":
https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-...

It would have to be HTML that defines "animation frame task" for the
integration with Fullscreen to really make sense, tracked by:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28001

BUG=402376

Committed: https://crrev.com/0428d2791da252d73049587ac6bd4fa1610f6734
Cr-Commit-Position: refs/heads/master@{#436670}
==========

[commit-bot: I haz the power, 2016-12-06 19:04:47]

Patchset 4 (id:??) landed as
https://crrev.com/0428d2791da252d73049587ac6bd4fa1610f6734
Cr-Commit-Position: refs/heads/master@{#436670}