W3C home > Mailing lists > Public > public-web-perf@w3.org > April 2012

RE: test_timing_attributes_order

From: Karen Anderson (IE) <Karen.Anderson@microsoft.com>
Date: Wed, 25 Apr 2012 03:59:54 +0000
To: Boris Zbarsky <bzbarsky@MIT.EDU>
CC: "public-web-perf@w3.org" <public-web-perf@w3.org>
Message-ID: <748A9FD1BD28E74F971C8D69F6349472079819@BL2PRD0310MB350.namprd03.prod.outlook.com>
Yes, the technical aspect of the fix makes sense.  I guess it wasn't clear who's action item it was.  Would you mind making the edit after Jatinder uploads my other fixes?

Thanks
-Karen

Sent from my Windows Phone
________________________________
From: Boris Zbarsky
Sent: 4/24/2012 8:42 PM
To: Karen Anderson (IE)
Cc: public-web-perf@w3.org
Subject: Re: test_timing_attributes_order

On 4/24/12 11:37 PM, Karen Anderson (IE) wrote:
> Hi Boris,
>
> The http://w3c-test.org/webperf/tests/approved/navigation-timing/html5/test_timing_attributes_order.html test is failing the window.performance.timing.loadEventEnd>  0 and window.performance.timing.loadEventEnd>  loadEventStart with this call:  test_timing_order('loadEventEnd', 'loadEventStart');

Yes, this is because it's assuming things that it shouldn't be assuming;
in particular it assumes that the firing of the onload event of <iframe>
happens async after the firing of the onload event of the window inside
the iframe, which is not required by this spec.  As in, the test is
broken.  I've raised that on this list in the past.

For what it's worth, fixing the test should be pretty easy: just don't
read loadEventEnd synchronously from onload; do it off a timeout instead.

I'm sorry if I didn't make that clear in
http://lists.w3.org/Archives/Public/public-web-perf/2012Apr/0028.html

-Boris
Received on Wednesday, 25 April 2012 04:00:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 25 April 2012 04:00:34 GMT