Граф коммитов

35 Коммитов

Автор SHA1 Сообщение Дата
Andrea Marchesini cdc5dc80cf Bug 1548253 - Port pref cache variables of nsContentUtils to StaticPrefs - dom.enable_resource_timing, r=Ehsan
Differential Revision: https://phabricator.services.mozilla.com/D29506

--HG--
extra : moz-landing-system : lando
2019-05-01 21:08:36 +00:00
Andrea Marchesini 54d87e9690 Bug 1548253 - Port pref cache variables of nsContentUtils to StaticPrefs - dom.enable_performance, r=Ehsan
Differential Revision: https://phabricator.services.mozilla.com/D29505

--HG--
extra : moz-landing-system : lando
2019-05-01 21:06:59 +00:00
Ryan Hunt 00e98538aa Bug 1523969 part 6 - Move method definition inline comments to new line in 'dom/'. r=nika
Differential Revision: https://phabricator.services.mozilla.com/D21106

--HG--
extra : rebase_source : ea3f51c2c11247114deccbc86e90fb02b8a97257
2019-02-25 16:05:29 -06:00
Christoph Kerschbaumer 54df1cb98c Bug 1528677: Remove nullchecks for loadinfo since we have loadinfo on all channels. r=baku 2019-02-20 13:27:25 +01:00
Emilio Cobos Álvarez d2ed260822 Bug 1517241 - Rename nsIDocument to mozilla::dom::Document. r=smaug
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.
2019-01-03 17:48:33 +01:00
Sylvestre Ledru 265e672179 Bug 1511181 - Reformat everything to the Google coding style r=ehsan a=clang-format
# ignore-this-changeset

--HG--
extra : amend_source : 4d301d3b0b8711c4692392aa76088ba7fd7d1022
2018-11-30 11:46:48 +01:00
Dragana Damjanovic 7598019f0a Bug 1506512 - ServerTiming header must be updated onStopRequest as well. r=valentin
Differential Revision: https://phabricator.services.mozilla.com/D12026

--HG--
extra : moz-landing-system : lando
2018-11-16 10:17:15 +00:00
Andrea Marchesini aeaf76c5f4 Bug 1481195 - The current document should have access to its PerformanceTimingData, r=valentin 2018-08-06 21:27:00 +02:00
Andrea Marchesini b1e6d36a31 Bug 1462883 - Update PerformanceTimingData::mReportCrossOriginRedirect in SetPropertiesFromHttpChannel, r=bz 2018-08-03 13:08:32 +02:00
Jeff Gilbert 5b753da289 Bug 1470325 - s/FooBinding/Foo_Binding/g - r=qdot
MozReview-Commit-ID: JtTcLL5OPF0
2018-06-26 17:05:01 -07:00
Valentin Gosu f96bb4a629 Bug 1423495 - Part6: Use threadsafe refcounting for nsServerTiming r=baku,nwgh
* 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
2018-04-24 13:04:12 +02:00
Kershaw Chang ext:(%2C%20Valentin%20Gosu%20%3Cvalentin.gosu%40gmail.com%3E) 760d944af2 Bug 1423495 - Part1: Implement PerformanceServerTiming, r=baku
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
2018-01-10 04:01:00 +01:00
Phil Ringnalda 529ef739c9 Backed out changeset 1e6febc9f5af (bug 1436778) for being too easy to hit, by just running navigation-timing/test_performance_attributes_exist_in_object.html 2018-04-13 19:03:36 -07:00
Tom Ritter 6d09d0bdf2 Bug 1436778 Add an assertion to hopefully get a reproduction for a hard-to-repro timer jitter bug r=baku
MozReview-Commit-ID: D4zt1v1tjOs

--HG--
extra : rebase_source : b4f5be226c72d6a2f80b4f598155fe9f11ee695c
2018-04-10 13:08:25 -05:00
Tom Ritter 6ebcecc30e Bug 1440195 Add a random context seed to the Performance APIs r=baku
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
2018-03-13 12:36:34 -05:00
Tom Ritter ba0e15150d Bug 1443943 Port the performance APIs only to only clamping/jittering on non-System Principal r=baku
MozReview-Commit-ID: FKYLI5Yc1kX

--HG--
extra : rebase_source : a50952a233eff12c523bb9d9006d3143fa744005
2018-03-09 09:29:33 -06:00
Andrea Marchesini 0356adb210 Bug 1425458 - Resource timing entries Workers - part 3 - PerformanceStorageWorker, r=smaug 2018-01-24 17:17:32 +01:00
Andrea Marchesini a8d07c4d56 Bug 1425458 - Resource timing entries Workers - part 2 - PerformanceTimingData, r=smaug 2018-01-24 17:17:31 +01:00
Brindusan Cristian 368c3d5b6b Backed out 12 changesets (bug 1425458) for mochitest failures on WorkerPrivate.cpp on a CLOSED TREE
Backed out changeset 11997de13778 (bug 1425458)
Backed out changeset 100b9d4f36bc (bug 1425458)
Backed out changeset a29e9dbb8c42 (bug 1425458)
Backed out changeset b96d58fd945c (bug 1425458)
Backed out changeset f140da44ba68 (bug 1425458)
Backed out changeset af56400233d9 (bug 1425458)
Backed out changeset 7034af4332e4 (bug 1425458)
Backed out changeset f70500179140 (bug 1425458)
Backed out changeset 793bbfc23257 (bug 1425458)
Backed out changeset 2efb375a8ffc (bug 1425458)
Backed out changeset 07e781e37451 (bug 1425458)
Backed out changeset e875f3702a5f (bug 1425458)
2018-01-24 20:47:48 +02:00
Andrea Marchesini 614ece72f9 Bug 1425458 - Resource timing entries Workers - part 9 - Fixing a compilation issue, r=me CLOSED TREE 2018-01-24 18:19:12 +01:00
Andrea Marchesini 662a5542a3 Bug 1425458 - Resource timing entries Workers - part 3 - PerformanceStorageWorker, r=smaug 2018-01-24 17:17:32 +01:00
Andrea Marchesini f5ad0fea6c Bug 1425458 - Resource timing entries Workers - part 2 - PerformanceTimingData, r=smaug 2018-01-24 17:17:31 +01:00
Tom Ritter d0170278b3 Bug 1429764 Do not call ReduceTimerPrecision twice for DOM Navigation timers r=bkelly,timhuang
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
2018-01-12 13:36:04 -06:00
Tom Ritter 58c53866d8 Bug 1424341 Round the Performance Timing APIs when privacy.reduceTimerPrecision is set r=bkelly,timhuang
MozReview-Commit-ID: LrAmrIfKk39

--HG--
extra : rebase_source : e9ded5202406abd07465a0b4a9a6122c86a9c072
2018-01-10 15:51:23 -06:00
Dragana Damjanovic d2271cd3a8 Bug 1417431 - secureConnectionStart should be 0 for pages with HTTP scheme. r=bkelly 2017-12-06 12:57:28 +01:00
Ben Kelly 39ab1eb0b4 Bug 1415630 Make PerformanceResourceTiming.fetchStart match the time we dispatch the FetchEvent when SW interception occurs. r=baku 2017-11-09 09:00:43 -08:00
Ben Kelly 8231685365 Bug 1204254 P14 Stop faking responseStart/End directly and make PerformanceTiming map SW specific timings instead. r=asuth 2017-10-17 13:38:56 -07:00
Ben Kelly f9e5ee1ee2 Bug 1191943 P1 Implement PerformanceResourceTiming.workerStart. r=asuth 2017-10-06 09:04:54 -07:00
Ben Kelly b4b2a21adc Bug 1405739 P1 Don't expose internal redirect start/end/count through performance timing API. r=valentin 2017-10-06 09:04:54 -07:00
Valentin Gosu 8482ae39c3 Bug 919391 - Incorrect Navigation Timing API: performance.timing.responseStart - performance.timing.requestStart < 0 r=baku
MozReview-Commit-ID: 6s5FljTQEAB
2017-08-23 16:50:18 +02:00
Patrick McManus 850582d8f3 Bug 772589 - Implement the secureConnectionStart property for the PerformanceTiming interface r=bkelly,dragana,francois,Honza
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
2017-07-10 15:01:35 -04:00
Tim Huang 7d1c0f2d14 Bug 1369303 - Part 2: Marking the performance timing API always reports 0 and the access of resource timing and user timing becomes NOP when 'privacy.resistFingerprinting' is true. r=arthuredelstein,baku
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
2017-06-15 16:48:27 +08:00
Wei-Cheng Pan 150bc3a607 Bug 1344893 - Part 2: Add time to first byte metric. r=smaug, data-review=bsmedberg
MozReview-Commit-ID: 6a30Xofr6p1
2017-04-19 02:00:00 -04:00
Andrea Marchesini 64734bf74c Bug 1278838 - Remove separate worker binding for Performance API, r=smaug
--HG--
rename : dom/performance/nsPerformance.cpp => dom/performance/Performance.cpp
rename : dom/performance/nsPerformance.h => dom/performance/Performance.h
rename : dom/workers/Performance.cpp => dom/performance/PerformanceWorker.cpp
rename : dom/workers/Performance.h => dom/performance/PerformanceWorker.h
2016-06-09 19:04:42 +02:00
Andrea Marchesini d84e87b425 Bug 1278843 - Move PerformanceTiming code in separate files, r=smaug 2016-06-09 12:43:56 +02:00