Move the fake mouse move event timer to the UserInteraction task queue.

Move the fake mouse move event timer to the UserInteraction task queue.

This is generally used for triggering hover chain updates after
scrolling. However, there is one exception which makes this a bit odd to
place in the UserInteraction task queue: after Document does a style
recalc, it queues a fake mouse move event to update the hover chains,
since the style recalc may have shifted elements around.

BUG=624694
Review-Url: https://codereview.chromium.org/2645483002
Cr-Commit-Position: refs/heads/master@{#444589}
Committed: https://chromium.googlesource.com/chromium/src/+/89ac94386ebb1a4e316549cab76fe490e66f9b34

[dcheng, 2017-01-18 10:07:26]

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

[commit-bot: I haz the power, 2017-01-18 10:07:49]

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

[dcheng, 2017-01-18 10:11:16]

dcheng@chromium.org changed reviewers:
+ haraken@chromium.org, rbyers@chromium.org

[dcheng, 2017-01-18 10:11:16]

This one is a bit tricky: style recalc triggered updates don't really feel like
something that belongs in the user interaction task queue, while things
triggered by scroll updates seem like they should. Thoughts welcome.

[commit-bot: I haz the power, 2017-01-18 10:18:36]

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

[commit-bot: I haz the power, 2017-01-18 10:18:37]

Dry run: Try jobs failed on following builders:
  chromeos_daisy_chromium_compile_only_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_daisy_...)

[haraken, 2017-01-18 10:26:07]

On 2017/01/18 10:11:16, dcheng wrote:
> This one is a bit tricky: style recalc triggered updates don't really feel
like
> something that belongs in the user interaction task queue, while things
> triggered by scroll updates seem like they should. Thoughts welcome.

I think the user interaction task source makes sense. LGTM.

https://html.spec.whatwg.org/#definitions-3

"For example, a user agent could have one task queue for mouse and key events
(the user interaction task source), and another for everything else"

[dcheng, 2017-01-18 19:21:16]

On 2017/01/18 10:26:07, haraken wrote:
> On 2017/01/18 10:11:16, dcheng wrote:
> > This one is a bit tricky: style recalc triggered updates don't really feel
> like
> > something that belongs in the user interaction task queue, while things
> > triggered by scroll updates seem like they should. Thoughts welcome.
> 
> I think the user interaction task source makes sense. LGTM.
> 
> https://html.spec.whatwg.org/#definitions-3
> 
> "For example, a user agent could have one task queue for mouse and key events
> (the user interaction task source), and another for everything else"

I see; I originally interpreted this to read 'platform mouse and key events',
but it kind of makes sense that synthesized events might go in this bucket as
well.

[dcheng, 2017-01-18 19:21:16]

On 2017/01/18 10:26:07, haraken wrote:
> On 2017/01/18 10:11:16, dcheng wrote:
> > This one is a bit tricky: style recalc triggered updates don't really feel
> like
> > something that belongs in the user interaction task queue, while things
> > triggered by scroll updates seem like they should. Thoughts welcome.
> 
> I think the user interaction task source makes sense. LGTM.
> 
> https://html.spec.whatwg.org/#definitions-3
> 
> "For example, a user agent could have one task queue for mouse and key events
> (the user interaction task source), and another for everything else"

I see; I originally interpreted this to read 'platform mouse and key events',
but it kind of makes sense that synthesized events might go in this bucket as
well.

[dcheng, 2017-01-18 19:21:16]

On 2017/01/18 10:26:07, haraken wrote:
> On 2017/01/18 10:11:16, dcheng wrote:
> > This one is a bit tricky: style recalc triggered updates don't really feel
> like
> > something that belongs in the user interaction task queue, while things
> > triggered by scroll updates seem like they should. Thoughts welcome.
> 
> I think the user interaction task source makes sense. LGTM.
> 
> https://html.spec.whatwg.org/#definitions-3
> 
> "For example, a user agent could have one task queue for mouse and key events
> (the user interaction task source), and another for everything else"

I see; I originally interpreted this to read 'platform mouse and key events',
but it kind of makes sense that synthesized events might go in this bucket as
well.

[dcheng, 2017-01-18 19:23:48]

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

[commit-bot: I haz the power, 2017-01-18 19:24:21]

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

[commit-bot: I haz the power, 2017-01-18 21:46:56]

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

[commit-bot: I haz the power, 2017-01-18 21:46:56]

Dry run: This issue passed the CQ dry run.

[Rick Byers, 2017-01-19 01:14:02]

Yeah I think this is probably fine.  Conceptually what matters is the mouse
moving in relation to the content (not whether it's the mouse or content moving
relative to some absolute frame of reference).

LGTM

[dcheng, 2017-01-19 01:15:36]

The CQ bit was checked by dcheng@chromium.org

[dcheng, 2017-01-19 01:15:36]

The patchset sent to the CQ was uploaded after l-g-t-m from haraken@chromium.org
Link to the patchset: https://codereview.chromium.org/2645483002/#ps20001
(title: "fix build")

[commit-bot: I haz the power, 2017-01-19 01:16:11]

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

[Rick Byers, 2017-01-19 01:16:13]

BTW I'm assuming this difference isn't really observable to a web page. There's
already an arbitrary delay here so the exact timing should be pretty irrelevant,
right?  So this is just a code health thing, no need for a test or web compat
concern.

[haraken, 2017-01-19 01:19:14]

On 2017/01/19 01:16:13, Rick Byers wrote:
> BTW I'm assuming this difference isn't really observable to a web page.
There's
> already an arbitrary delay here so the exact timing should be pretty
irrelevant,
> right?  So this is just a code health thing, no need for a test or web compat
> concern.

Correct.

[commit-bot: I haz the power, 2017-01-19 01:30:31]

CQ is committing da patch.

Bot data: {"patchset_id": 20001, "attempt_start_ts": 1484788536302040,
"parent_rev": "9288679e3eb12c219b520c6327ac5ab9a7741cb5", "commit_rev":
"89ac94386ebb1a4e316549cab76fe490e66f9b34"}

[commit-bot: I haz the power, 2017-01-19 01:31:05]

Description was changed from

==========
Move the fake mouse move event timer to the UserInteraction task queue.

This is generally used for triggering hover chain updates after
scrolling. However, there is one exception which makes this a bit odd to
place in the UserInteraction task queue: after Document does a style
recalc, it queues a fake mouse move event to update the hover chains,
since the style recalc may have shifted elements around.

BUG=624694
==========

to

==========
Move the fake mouse move event timer to the UserInteraction task queue.

This is generally used for triggering hover chain updates after
scrolling. However, there is one exception which makes this a bit odd to
place in the UserInteraction task queue: after Document does a style
recalc, it queues a fake mouse move event to update the hover chains,
since the style recalc may have shifted elements around.

BUG=624694

Review-Url: https://codereview.chromium.org/2645483002
Cr-Commit-Position: refs/heads/master@{#444589}
Committed:
https://chromium.googlesource.com/chromium/src/+/89ac94386ebb1a4e316549cab76f...
==========

[commit-bot: I haz the power, 2017-01-19 01:31:06]

Committed patchset #2 (id:20001) as
https://chromium.googlesource.com/chromium/src/+/89ac94386ebb1a4e316549cab76f...