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
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
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
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
Bug 1429764 details a test failure that was asserting that the performance navigation
timers were strictly increasing (or equal). fetchStart should have a timestamp before
domainLookupStart. But it didn't.
The problem is two-fold. This corrects the test and the issue by addressing one part
of the problem, the second part of the problem needs to be written up in a new bug
and addressed there. (That bug is not yet filed at writing, but see dependencies of
1429764 in the future to find it.)
The second, and underlying, problem is that calling ReduceTimerPrecision with the
same value multiple times may continually reduce it. Meaning that the first you call
it with, say, .75, (and a precision of .20), it will be reduced to .6. The second time
you call it (with .6), instead of staying at .6 it will be reduced to .4. This is
because floats are fuzzy. Inside ReduceTimerPrecision we are multiplying a decimal by
a decimal, so while floor(.6 / .20) should equal 3, sometimes it's actually 2.999...
which gets floors to 2, gets multiplied again by .2, and which results in .4
If that's the underlying problem, the first, and surface, problem is - why are we
calling ReduceTimerPrecision multiple times? We shouldn't be. That's what this
patch fixes.
TimeStampToDOMHighResOrFetchStart will return either TimeStampToDOMHighRes() or
FetchStartHighRes(). FetchStartHighRes() internally calls TimeStampToDOMHighRes
and then ReduceTimerPrecision - this is where (some of) the two reduction calls
happen - because TimeStampToDOMHighRes itself calls ReduceTimerPrecision also.
I remove the ReduceTimerPrecision from TimeStampToDOMHighRes. FetchStartHighRes
will now only call ReduceTimerPrecision once, at the end of the return.
But we have to fix places we call TimeStampToDOMHighResOrFetchStart, because the
callers of that function also call ReduceTimerPrecision. So if
TimeStampToDOMHighResOrFetchStart returned FetchStartHighRes, we'd be calling
ReduceTimerPrecision twice for those callers.
So inside first off, we remove the outer call to ReduceTimerPrecision. that
surrounds the 5 or so callsites of TimeStampToDOMHighResOrFetchStart. Then
inside of TimeStampToDOMHighResOrFetchStart we return either FetchStartHighRes
(which is has already called ReduceTimerPrecision) or we call
ReduceTimerPrecision with the value.
Now. TimeStampToDOMHighRes was used in more places than just FetchStartHighRes -
there were several other places where we were doing double rounding, and this
fixed those as well. AsyncOpenHighRes, WorkerStartHighRes, DomainLookupEndHighRes,
ConnectStartHighRes, SecureConnectionStartHighRes, ConnectEndHighRes, and
ResponseEndHighRes.
MozReview-Commit-ID: K5nHql135rb
