It's dead code, because we never create PerformanceEntry objects directly and
subclasses override WrapObject.
Differential Revision: https://phabricator.services.mozilla.com/D32203
--HG--
extra : moz-landing-system : lando
This patch updates BUG_COMPONENT for some dom/* and testing/web-platform/* files
Differential Revision: https://phabricator.services.mozilla.com/D28721
--HG--
extra : moz-landing-system : lando
This is split from the previous changeset since if we include dom/ the file size is too
large for phabricator to handle.
This is an autogenerated commit to handle scripts loading mochitest harness files, in
the simple case where the script src is on the same line as the tag.
This was generated with https://bug1544322.bmoattachments.org/attachment.cgi?id=9058170
using the `--part 2` argument.
Differential Revision: https://phabricator.services.mozilla.com/D27457
--HG--
extra : moz-landing-system : lando
There are few things that are either Fennec-specific or don't work
currently under GeckoView w/ e10s under TestRunnerActivity. Disable
these so we can get some testing going in automation.
This also replaces 'isFennec' with the more correct 'is_fennec'.
Differential Revision: https://phabricator.services.mozilla.com/D19016
--HG--
extra : moz-landing-system : lando
The actual subcategories will be added in later patches, so that there are no
unused categories.
Differential Revision: https://phabricator.services.mozilla.com/D11334
--HG--
extra : moz-landing-system : lando
There are few things that are either Fennec-specific or don't work
currently under GeckoView w/ e10s under TestRunnerActivity. Disable
these so we can get some testing going in automation.
Differential Revision: https://phabricator.services.mozilla.com/D19016
--HG--
extra : moz-landing-system : lando
This commit adds categories to all markers. This way the profiler's
marker categories and frame label categories agree. There are a few
duplicate category properties on some of the marker payloads, but
this could be cleaned up in a follow-up if needed.
Differential Revision: https://phabricator.services.mozilla.com/D16864
--HG--
extra : moz-landing-system : lando
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.
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
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
Currently the Gecko Profiler defines a moderate amount of stuff when
MOZ_GECKO_PROFILER is undefined. It also #includes various headers, including
JS ones. This is making it difficult to separate Gecko's media stack for
inclusion in Servo.
This patch greatly simplifies how things are exposed. The starting point is:
- GeckoProfiler.h can be #included unconditionally;
- everything else from the profiler must be guarded by MOZ_GECKO_PROFILER.
In practice this introduces way too many #ifdefs, so the patch loosens it by
adding no-op macros for a number of the most common operations.
The net result is that #ifdefs and macros are used a bit more, but almost
nothing is exposed in non-MOZ_GECKO_PROFILER builds (including
ProfilerMarkerPayload.h and GeckoProfiler.h), and understanding what is exposed
is much simpler than before.
Note also that in BHR, ThreadStackHelper is now entirely absent in
non-MOZ_GECKO_PROFILER builds.
This matches to the spec and makes po-callback-mutate.any.js test pass.
From the spec [1]
1. Let entries be a copy of po’s observer buffer.
2. Empty po’s observer buffer.
3. If entries is non-empty, call po’s callback with entries as first
argument and po as the second argument and callback this value. If this
throws an exception, report the exception.
[1] https://w3c.github.io/performance-timeline/#queue-a-performanceentry
MozReview-Commit-ID: AEdfvGpauzy
--HG--
extra : rebase_source : 20b9fc8426fd48d10e8e55662afe1c881fd92343
Replace it with NS_INTERFACE_MAP_BEGIN_CYCLE_COLLECTION, because it
has been the same for a while.
MozReview-Commit-ID: 5agRGFyUry1
--HG--
extra : rebase_source : 5388c56b2f6905c6ef969150f0c5b77bf247624d
As well as the obvious #ifdef stuff, the patch removes
TCPSocket::SetAppIdAndBrowser(), which means
{TCPSocketParent,TCPServerSocketParent}::{GetAppId,GetInIsolatedMozBrowser}()
can also be removed.
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
Storing PerformanceEntry objects in an AutoTArray (currently sized to
match our limit for resource timing entries) should omit some
per-entry allocations and give us a small speedup with creating
entries in tight loops.
MozReview-Commit-ID: LNgVhMn461g
--HG--
extra : rebase_source : 10250c2fad5ebaf0e89bf9759d157b7d1d855ffa
This requires:
- Moving the constructors of ProfilerMarkerPayload and its subclasses into the
.h file so they are visible even when ProfilerMarkerPayload.cpp isn't
compiled.
- Similarly, using a macro to make StreamPayload() a crashing no-op when the
profiler isn't enabled. (It is never called in that case.)
--HG--
extra : rebase_source : 7aad2fdb1bd4e49782024dba6664e8f992771520
PROFILER_MARKER is now just a trivial wrapper for profiler_add_marker(). This
patch removes it.
--HG--
extra : rebase_source : 9858f34763bb343757896a91ab7ad8bd8e56b076
Once the |aPayload| argument to profile_add_marker() became a UniquePtr the
default value of nullptr caused compilation difficulties that could only be
fixed by #including ProfilerMarkerPayload.h into lots of additional places
(because the UniquePtr<T> instantiation required the T to be fully defined). To
get around this I just split profile_add_marker() into two functions, one with
1 argument and one with 2 arguments.
The patch also removes the definition of PROFILER_MARKER_PAYLOAD in the case
where MOZ_GECKO_PROFILER isn't defined. A comment explains why.
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
This patch is adapted from Tor bug 1517.
To offer some protection against timing attacks by JS content pages, in this
patch we round the various time-exposing APIs (such as Date and
Event.timeStamps) to the nearest 100 ms when the pref "privacy.resistFingerprinting" is on.
MozReview-Commit-ID: eGucM9nGTn
--HG--
extra : rebase_source : 3ee600b07943f3954e9a2a9561391f2f7821bb86
Because ProfilerMarkerPayload is the main type defined in these files, and
because the next patch is going to introduce ProfilerMarker.{h,cpp}, which
would be confusingly similar to the old names.
--HG--
rename : tools/profiler/core/ProfilerMarkers.cpp => tools/profiler/core/ProfilerMarkerPayload.cpp
rename : tools/profiler/public/ProfilerMarkers.h => tools/profiler/public/ProfilerMarkerPayload.h
extra : rebase_source : df22a2ab3867650348ae78fe959ff0366aff230b
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
Will Hawkins
Victor Porof
Coroiu Cristina
Mark Banner
Andrea Marchesini
Boris Zbarsky
Hsin-Yi Tsai
Brian Grinstead
Bogdan Tara
Ciure Andrei
Dorel Luca
Sebastian Hengst
Ryan Hunt
James Willcox
Christoph Kerschbaumer
Markus Stange
Andreea Pavel
Cosmin Sabou
Greg Tatum
Ehsan Akhgari
Emilio Cobos Álvarez
Sylvestre Ledru
Dragana Damjanovic
Randell Jesup
Nazım Can Altınova
Margareta Eliza Balazs
Jon Coppeard
shindli
Chris Peterson
Andi-Bogdan Postelnicu
Thomas Wisniewski
Jeff Gilbert
Tom Ritter
Bobby Holley
Valentin Gosu
Kershaw Chang ext:(%2C%20Valentin%20Gosu%20%3Cvalentin.gosu%40gmail.com%3E)
Phil Ringnalda
Tomislav Jovanovic
Tristan Bourvon
Josh Matthews
Florian Quèze
Brindusan Cristian
Jonathan Watt
Nika Layzell
Ben Kelly
Nicholas Nethercote
Hiroyuki Ikezoe
Andrew McCreight
Masatoshi Kimura
Ryan VanderMeulen
Patrick McManus
Perry Jiang
Wes Kocher
Kyle Machulis
Bill McCloskey
Carsten "Tomcat" Book
Tim Huang
Jonathan Hao
Greg Tatum
Wei-Cheng Pan
Joel Maher
Olli Pettay
Tom Tromey