- From: Jatinder Mann <jmann@microsoft.com>
- Date: Wed, 28 Mar 2012 23:23:11 +0000
- To: Jatinder Mann <jmann@microsoft.com>, Sigbjørn Vik <sigbjorn@opera.com>, "public-web-perf@w3.org" <public-web-perf@w3.org>
There were two exceptions raised by the measure method that had questions: "Throws a SYNTAX_ERR exception if either startMark or endMark argument, or both, have the same name as a PerformanceTiming attribute with a DOMHighResTimeStamp time value of 0." This exception protects from comparing against a Navigation Timing attribute that has been zero'd out due to cross-origin restrictions. If we allow this operation to occur, developers may get misleading data. E.g., if redirectStart has been zero'd out due to cross-origin restrictions, a measure from that point would be misleading if the data consumer doesn't know that a cross-origin restriction was in effect. As this isn't exactly a syntax error, I have updated to make this a INVALID_ACCESS_ERR. "Throws a SYNTAX_ERR exception if the duration (the end mark DOMHighResTimeStamp time value minus the start mark DOMHighResTimeStamp time value) is negative." The reason behind including this exception may have been to protect from comparing against a Navigation Timing attribute that has not yet loaded. E.g., performance.measure('measure1', 'navigationStart', 'loadEventEnd'), where the load event has not yet fired. However, the zero case above should cover the scenario where you are measuring against loadEventEnd but the load hasn't yet fired. I believe there is some value in being able to return negative measures. If I can do performance.measure('myMeasure', 'mark1', 'mark2') and getting the measure returns [5.0], then getting the measure when invoking performance.measure('mymarkInverse', 'mark2', 'mark1') should return [-5.0]. Thanks, Jatinder
Received on Wednesday, 28 March 2012 23:23:48 UTC