Closed
Bug 804069
Opened 12 years ago
Closed 10 years ago
window.performance is null in a webpage loaded via <?xml-stylesheet?>
Categories
(Core :: DOM: Navigation, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: mail+moz, Unassigned)
References
Details
(Keywords: helpwanted)
Attachments
(3 files)
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.
Reporter | ||
Comment 1•12 years ago
|
||
Reporter | ||
Comment 2•12 years ago
|
||
Comment 3•12 years ago
|
||
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).
Keywords: helpwanted
Updated•11 years ago
|
OS: Mac OS X → All
(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.
Comment 7•11 years ago
|
||
> 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?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(jonas)
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.
Flags: needinfo?(jonas)
Comment 9•11 years ago
|
||
We could also just return it zeroed out for now so a least we don't get exceptions...
Works for me
Comment 11•11 years ago
|
||
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
Comment 12•11 years ago
|
||
Sure. now() would work fine; it's not affected by the issues the timing object has.
Comment 13•10 years ago
|
||
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....
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•