Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
* 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
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 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
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
--HG--
extra : rebase_source : e06785203f0f8b01fc7b694ce840f07dc09bc4a1
Implements PerformanceTiming, nsITimedChannel, and devtools 'tls setup'
Also captures telemetry on this as we do for all other attributes of timedChannel
Also propogates some null transaction timings onto first real
transaction of a connection
MozReview-Commit-ID: 47TQJYVHnKC
--HG--
extra : rebase_source : a7723962986de0c2ab00d479a22c3f5fd185c8b2
This patch is going to neutralize the threat of fingerprinting of performance API
by spoofing the value of performance timing into 0, making getEntries* functions
always returns an empty list and making mark() and measure() into NOP methods.
In addition, this patch changes nsContentUtils::ShouldResistFingerprinting() to
allow it can be called in both main thread and worker threads.
MozReview-Commit-ID: C8Jt7KEMe5e
--HG--
extra : rebase_source : 85cbf66881c868ca5109022ffd4af81e3ab0a049
