Re: [NavigationTiming] new tests

On Tue, Feb 8, 2011 at 5:31 PM, Anderson Quach <aquach@microsoft.com> wrote:

> Hi Web Perf WG,
>
>
>
> I’ve added four new tests:
>
> http://w3c-test.org/webperf/tests/submission/Microsoft/NavigationTiming/
>
>
>
> test_navigation_type_backfoward
>
>
> http://w3c-test.org/webperf/tests/submission/Microsoft/NavigationTiming/test_navigation_type_backforward.htm
>

Chrome fails this test for reasons related to the behavior of
history.back/history.forward on subframes rather than reasons related to the
functionality it is meant to test. I'm looking into exactly why that is and
whether there is a way to workaround that bug so that this test can test
what it is trying to test.


> test_navigation_type_reload
>
>
> http://w3c-test.org/webperf/tests/submission/Microsoft/NavigationTiming/test_navigation_type_reload.htm
>

LGTM


> test_timing_attributes_order
>
>
> http://w3c-test.org/webperf/tests/submission/Microsoft/NavigationTiming/test_timing_attributes_order.htm
>

There are a couple of problems that make the test flaky:
1. It tests the navigation type of the main frame, so when I reload the
page, it fails.
2. It assumes there was a page loaded before it, if not the unload event
tests fail.
Can this test be performed inside of a frame so it isn't susceptible to this
flakiness?


> test_timing_client_redirect
>
>
> http://w3c-test.org/webperf/tests/submission/Microsoft/NavigationTiming/test_timing_client_redirect.htm
>

LGTM, but can the meta refresh be 1 second instead of 3?

This test also tests an interesting corner case (where IE9 and Chrome
agree): After a client side redirect the navigation type is always
"navigate," even if the page that triggered the client side redirect was
loaded by another means. I believe this is what the spec says, but just
wanted to call attention to it.


>
>
> Best Regards,
>
> Anderson, Nic and Karen
>
> Internet Explorer
>