1: Correct the Performance API 'NowUnclamped' to obtain a non-Fuzzed Timestamp
2: Do not compare fuzzed and non-fuzzed timestamps in a Refresh Driver assert,
since this happens so early on that we will eventually compare them and
asserting would be bad.
Firefox no longer supports Windows XP, so these test checks that allow for timeouts with 25 ms resolution can be removed. Also, rewrite some test logic and comments to make the test's intention clearer.
The 'getOSCPU' message handler can be removed from test_worker_performance_now.html because test_worker_performance_now.js no longer needs to check for Windows XP.
Stop setting the pref "privacy.reduceTimerPrecision" = false in test_performance_now.html. That pref removes performance.now()'s 1 ms resolution limit so the performance timer will run at full speed. By leaving the pref's default value, the test can assert that performance.now() is actually honoring the 1 ms limit.
I didn't remove "privacy.reduceTimerPrecision" = false for the worker test. The worker tests run an accelerated setTimeout() clock, so setTimeout(1) can time out in less than 1 ms. Leaving the pref "privacy.reduceTimerPrecision" = true causes hundreds of worker tests to run more slowly (in real time), which would increase test automation time.
Differential Revision: https://phabricator.services.mozilla.com/D6581
--HG--
extra : rebase_source : 371d474e556c6f2297286ec1e1f168168aeba0e6
extra : source : d9585d71e99f687b2e5c244d524ccf70096c96a4
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
Without this, we will start including mozMemory in performance.toJSON() even if
the pref for it is not set, once 'object' becomes a JSON type.
This changes behavior in the following observable ways:
1) We stop exposing PerformanceResourceTiming's .serverTiming in the JSON
serialization in insecure contexts.
2) We stop exposing PerformanceTiming's timeToNonBlankPaint and
timeToDOMContentFlushed in the JSON serialization unless the relevant
preferences are turned on.
* Also keeps the timing array as nsTArray<nsCOMPtr<nsIServerTiming>> instead of the scriptable nsIArray (which doesn't like being released on another thread)
MozReview-Commit-ID: 37uPZJ38saQ
--HG--
extra : rebase_source : 099ec74c3032ef6033d187a028466777200c6015
Currently, the document entry is created at the first time when some JS code tries to access it. But for the case when server timing headers exist for a document loading channel, we need to create the document entry and save the server timing data in the document entry.
If we don’t do this, the server timing data would be lost since the http channel will be deleted.
MozReview-Commit-ID: B5ksAZvZACq
--HG--
extra : rebase_source : 27bc6284ec417b2ff430a59cd9eeddc56b7a77ac
Test steps:
1. Create a XHR to get serverTiming.sjs.
2. Add Server-Timing headers in serverTiming.sjs.
3. Check if the value from PerformanceResourceTiming is correct.
MozReview-Commit-ID: KOQhoFQv4fy
--HG--
extra : rebase_source : a0f5bde872ca9e066764d90ab80d7848988f37a8
This patch:
1. Introduces PerformanceServerTiming.webidl.
2. Adds serverTiming in PerformanceResourceTiming.webidl.
3. Gets serverTiming data from nsITimedChannel and keeps it in the PerformanceTimng class.
MozReview-Commit-ID: 9mkGkHbxopC
--HG--
extra : rebase_source : 7e0d0321e71eb0af9591ead76dc163996fbaf819
We need to side-step existing cross-origin checks in Performance Timing code
when the caller is a web extension content script that otherwise has permission
to access the cross-origin resource.
MozReview-Commit-ID: 8IgtqZgPWgY
--HG--
extra : rebase_source : e8152c5d8ab32096d1ff7f97311c1b43b57c3694
We attach it to WorkerPrivate and DOMNavigationTiming so it will be re-used
when it should.
WorkerPrivate is used in the Performance APIs, Performance Storage Worker,
and Event.
DOMNavigationTiming is used only in the Performance APIs, but the crucial
part is that when the individual DOMNavigationTiming object is re-used,
so will the context seed. This in particular came up with the
nav2_test_document_open.html Web Platform Test which illustrated the fact
that even if you .open() a new document, the performance navigation data
is not supposed to change.
MozReview-Commit-ID: GIv6biEo2jY
--HG--
extra : rebase_source : da2ad8d9d6e0172679c6af14dba72938e9d2012c
PresShell only uses performane.now to track refresh times, and notify internal
observers. We can provide more accurate times by not clamping and jittering
these numbers.
MozReview-Commit-ID: FkDGJhrLeAy
--HG--
extra : rebase_source : 99c571d1e5df53f51b4be0304df3818c161d2972
There are a few different reasons why tests needed updating (not an exhaustive list):
- Tests assume that successive operations take place at different times.
- Tests assume that an operation took a minimum amount of time.
- Tests hardcodes a specific delay.
In most cases we hardcode the preference off. In some cases this is the best approach,
in others, we would like to improve. The bug for tracking those improvements is Bug 1429648
An improvement that is present in some tests is to hardcode a specific precision reduction
that is acceptable based on the confides of the test. (Obviously this needs to be a fix for
the test framework and not a requirement on the feature being tested.)
In a few places, the test itself can be fixed, for example to no longer require the end
time of an operation to be strictly greater than the start time, and allows it to be equal
to it.
MozReview-Commit-ID: J59c7xQtZZJ
--HG--
extra : rebase_source : df8a03e76eaf9cdc9524dbb3eb9035af237e534b