The User Timing API is ready for implementation. This metabug is to track work for implementing it in WebKit. This will need to be announced on webkit-dev before anyone begins. As needed, please add specific implementation bugs that block this.
Created attachment 150769 [details] Patch
Comment on attachment 150769 [details] Patch Attachment 150769 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/13139504 New failing tests: fast/dom/Window/window-properties-performance.html
Created attachment 150778 [details] Archive of layout-test-results from gce-cr-linux-03 The attached test failures were seen while running run-webkit-tests on the chromium-ews. Bot: gce-cr-linux-03 Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'> Platform: Linux-2.6.39-gcg-201203291735-x86_64-with-Ubuntu-10.04-lucid
Comment on attachment 150769 [details] Patch Attachment 150769 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/13137708 New failing tests: fast/dom/Window/window-properties-performance.html
Created attachment 150785 [details] Archive of layout-test-results from gce-cr-linux-07 The attached test failures were seen while running run-webkit-tests on the chromium-ews. Bot: gce-cr-linux-07 Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'> Platform: Linux-2.6.39-gcg-201203291735-x86_64-with-Ubuntu-10.04-lucid
Created attachment 151194 [details] Patch
Created attachment 151244 [details] Patch
Comment on attachment 151244 [details] Patch Attachment 151244 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/13162282
Created attachment 151249 [details] Patch
Thanks for the patch. Just a couple of high level comments at this point: - I probably shouldn't have said "ready for implementation" without taking another pass through the spec. Sorry. The optional return types are kinda icky. I'd rather we just used the Performance Timeline getEntries*() functions. I've started a thread on public-webperf. You might want to hold off until that's settled. - Everything needs to be vendor-prefixed until the spec moves forward. So all of the functions need to start with "webkit". - I'd prefer to use the W3C style test suites instead of adding more WebKit specific ones. It'd be better to just write one set of tests and have them work for both WebKit and the W3C. I have bug 84887 that imports the W3C tests for Navigation Timing. Maybe we can build off that. - User Timing should integrate with Performance Timeline. Maybe the spec isn't very clear on that, but the returned objects (PerformanceMeasure and PerformanceMark) should derive from PerformanceEntry. They should also be returned when you call the Performance Timeline getEntries*() functions. If the spec isn't clear, please post comments on public-webperf. - This is a metabug. It shouldn't have any patches on it. We should create additional bugs to implement aspects of the spec and upload patches to those. Those bugs would block this metabug. For instance, you could have one bug for the main implementation and another to integrate it with Performance Timeline and one to remove the vendor prefixes when ready. Then you wouldn't have to implement everything all at once either. I suspect there'll be some other tweaks here and there as we go too. That's how the other timing specs have been.
Thanks for your kind comments, they are very helpful. :) Since getMarks() and getMeasures() interface maybe change as W3C spec move forward, I would like to implement other main interfaces firstly. patch will be uploaded in other bug entry.
Comment on attachment 151249 [details] Patch Clearing review flag on patches from before 2014. If this patch is still relevant, please reset the r? flag.
User Timing eventually landed. I'll be turning it on experimentally soon. This bug, and its patches, are quite old, so I'm going to close this out.