Add a layout test for longtask timing

Add a layout test for longtask timing

BUG=635596
Committed: https://crrev.com/97baf8674918865d98af196ee9f9dcf0a3a4fd8c
Cr-Commit-Position: refs/heads/master@{#426108}

[panicker, 2016-10-13 22:42:07]

panicker@chromium.org changed reviewers:
+ caseq@chromium.org, haraken@chromium.org

[panicker, 2016-10-13 22:42:08]

Hey Kentaro, Andrey,
I'd like to add a suite of tests for long task timing, based on the pattern in
this first test. So please scrutinize accordingly :)
Any better suggestion for directory location?

[haraken, 2016-10-14 00:06:41]

LGTM

[caseq, 2016-10-14 00:45:46]

lgtm, though I guess you also want to add the test expectation :-)

[panicker, 2016-10-14 17:35:26]

On 2016/10/14 00:45:46, caseq wrote:
> lgtm, though I guess you also want to add the test expectation :-)

There is no separate expectation file needed in this set up with testharness.
The assertions are inline.

[panicker, 2016-10-14 17:37:22]

panicker@chromium.org changed reviewers:
+ rbyers@chromium.org

[panicker, 2016-10-14 17:37:22]

Rick - could you review for OWNERS ?

[Rick Byers, 2016-10-17 15:06:25]

On 2016/10/14 17:37:22, Shubhie wrote:
> Rick - could you review for OWNERS ?

LayoutTests has OWNERS *, so you're already good.

But regardless LGTM.

The only thing I'd suggest you might want to think about is your path to a
web-platform-test suite that other vendors can easily consume.  Do you expect
you'll be able to test most things without any window.internals/eventSender
calls?  If so then you could iterate as layouts tests for now and once they're
in good shape move them to web-platform-tests.  Or you could just go with
web-platform-tests from the start (though we don't yet have the tooling in place
to make that as easy for you as we'd liked it to be).

[panicker, 2016-10-17 18:01:21]

On 2016/10/17 15:06:25, Rick Byers wrote:
> On 2016/10/14 17:37:22, Shubhie wrote:
> > Rick - could you review for OWNERS ?
> 
> LayoutTests has OWNERS *, so you're already good.
> 
> But regardless LGTM.
> 
> The only thing I'd suggest you might want to think about is your path to a
> web-platform-test suite that other vendors can easily consume.  Do you expect
> you'll be able to test most things without any window.internals/eventSender
> calls?  If so then you could iterate as layouts tests for now and once they're
> in good shape move them to web-platform-tests.  Or you could just go with
> web-platform-tests from the start (though we don't yet have the tooling in
place
> to make that as easy for you as we'd liked it to be).
Thanks for the advise here.
- One question I have is that the tests generate a long task by doing something
slow: while (window.performance.now() < begin + 51)
Do you have any concerns with having a couple dozen of these in the test suite
eventually?

- I started with writing this as a web-platform-test and then ported to layout
test. The reason is that we don't have a blessed spec for this API yet. What's
the official policy here?

- I don't expect to need window.internals/eventSender calls.

[panicker, 2016-10-17 18:13:12]

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

[commit-bot: I haz the power, 2016-10-17 18:13:35]

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, 2016-10-17 19:12:04]

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

[commit-bot: I haz the power, 2016-10-17 19:12:05]

Dry run: This issue passed the CQ dry run.

[panicker, 2016-10-18 23:26:55]

The CQ bit was checked by panicker@chromium.org

[commit-bot: I haz the power, 2016-10-18 23:27:22]

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, 2016-10-19 01:38:28]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-10-21 13:05:28]

Description was changed from

==========
Add a layout test for longtask timing

BUG=635596
==========

to

==========
Add a layout test for longtask timing

BUG=635596

Committed: https://crrev.com/97baf8674918865d98af196ee9f9dcf0a3a4fd8c
Cr-Commit-Position: refs/heads/master@{#426108}
==========

[commit-bot: I haz the power, 2016-10-21 13:05:29]

Patchset 1 (id:??) landed as
https://crrev.com/97baf8674918865d98af196ee9f9dcf0a3a4fd8c
Cr-Commit-Position: refs/heads/master@{#426108}

[Rick Byers, 2016-10-27 03:58:28]

Sorry I missed this!

On 2016/10/17 18:01:21, Shubhie wrote:
> On 2016/10/17 15:06:25, Rick Byers wrote:
> > On 2016/10/14 17:37:22, Shubhie wrote:
> > > Rick - could you review for OWNERS ?
> > 
> > LayoutTests has OWNERS *, so you're already good.
> > 
> > But regardless LGTM.
> > 
> > The only thing I'd suggest you might want to think about is your path to a
> > web-platform-test suite that other vendors can easily consume.  Do you
expect
> > you'll be able to test most things without any window.internals/eventSender
> > calls?  If so then you could iterate as layouts tests for now and once
they're
> > in good shape move them to web-platform-tests.  Or you could just go with
> > web-platform-tests from the start (though we don't yet have the tooling in
> place
> > to make that as easy for you as we'd liked it to be).
> Thanks for the advise here.
> - One question I have is that the tests generate a long task by doing
something
> slow: while (window.performance.now() < begin + 51)
> Do you have any concerns with having a couple dozen of these in the test suite
> eventually?

Yeah that's a good point.  If there's only a couple then it should be fine.  We
may need (or even already have) some way to flag some particularly slow tests
for special handling, but I'm SURE there are already quite a few WPTs that take
>100ms.

> - I started with writing this as a web-platform-test and then ported to layout
> test. The reason is that we don't have a blessed spec for this API yet. What's
> the official policy here?

As long as there's some spec somewhere (eg. WICG, even private GitHub) then it
should be fine.  For the most part nobody seems to care when new tests are added
(if they don't pass, nobody will be running them).  But there's a good chance
it's not worth the hassle of working in WPT until you're actually close to
getting some benefit from it (eg. impls starting elsewhere).  But it's always a
shame when Mozilla starts implementing and rewrites a whole test suite from
scratch because we didn't make ours follow the w3c standard format (or they
didn't know ours existed).

> - I don't expect to need window.internals/eventSender calls.