User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/534.57.2 (KHTML, like Gecko) Version/5.1.7 Safari/534.57.2 Steps to reproduce: Like this bug ("window.performance is null in a webpage loaded via <object>"): https://bugzilla.mozilla.org/show_bug.cgi?id=694612 window.performance is null to in XML documents that are viewed using a <?xml-stylesheet?> processing instruction. Expected results: window.performance should be available in these Windows as well.

Probably has to do with the say the transform result document replaces the original document. That said, it's not clear exactly what the various window.performance members should return here, since you actually have two separate sets of performance data (for the original document and for the transform result document).

(In reply to Boris Zbarsky [:bz] from comment #3) > Probably has to do with the say the transform result document replaces the > original document. > > That said, it's not clear exactly what the various window.performance > members should return here, since you actually have two separate sets of > performance data (for the original document and for the transform result > document). I do not agree that there will be any confusion about what the window.performance members will return. The document produced by the transformation does not involve any additional navigation or network interactions and does not create two separate sets of performance data. This problem previously was annoying because it affected any application code that used window.performance. Now it is severe because new internal Firefox code uses window.performance without checking for its existence. It throws an uncaught exception and invariably causes any application code wrapped in a "console.time/console.timeEnd" call to fail. ConsoleAPI.js, line 219/220 (Firefox 26) does this: if (aMethod == "time" || aMethod == "timeEnd") { metaForCall.monotonicTimer = window.performance.now(); } So if application code does this it fails: console.time("mytimer1"); doStuff();//this will never be called because of uncaught exception in firefox console.timeEnd("mytimer1"); I have modified the attachment example to demonstrate this.

> The document produced by the transformation does not involve any additional navigation or > network interactions The performance object has numbers that have nothing to do with navigation or network interaction, like "how long it took to parse the document". Which gets confusing when there are _two_ documents involved. Jonas, can you find someone to own this?

Honestly, I don't know of anyone not working on something more important. XSLT is not seeing a whole lot of usage on the web. But the first step would probably be to reach out to the web-performance WG and ask them to specify what values to return here.

We could also just return it zeroed out for now so a least we don't get exceptions...

Works for me

That solution sounds like a fair stopgap for "window.performance.timing" (which is governed by http://www.w3.org/TR/navigation-timing/#sec-navigation-timing-interface). In the interests of making the code in ConsoleAPI.js work it would be nice to have a functioning "window.performance.now" which should not care whether or not the document was generated via XSLT and is governed by a different spec: http://www.w3.org/TR/hr-time/#dom-performance-now

Sure. now() would work fine; it's not affected by the issues the timing object has.

This work fine for me with a current nightly and with Firefox 36. Presumably fixed by some of the ongoing work on the performance object....