The ESR release cadence changed from every 7 Firefox releases to 8.
Also, move strcmp() instead #ifdef DEBUG because it does nothing in release builds.
Differential Revision: https://phabricator.services.mozilla.com/D13657
In 1404608, the OS was revealed in both the HTTP User-Agent
header and to JavaScript code via navigator.userAgent. To avoid
leaking the OS inside each HTTP request (which many web servers
log), always use the Windows 7 OS value in the desktop User-Agent
header. We continue to allow access to the actual OS via JavaScript,
since doing so improves compatibility with web applications such
as GitHub and Google Docs.
This is an uplift of Tor's 26146
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.
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13371
For doing this, ServoComputedData is split into separate files, so that
files don't need to include ServoBindings.h just for accessing style
structs from ComputedStyles.
MozReview-Commit-ID: DPAd7PUUCl9
Previously we used Services.appinfo.defaultUpdateChannel to determine if we were on ESR
and if so, we would assert to make sure the ESR equation hadn't changed. But that method
is a footgun. We could use UpdateUtils.getUpdateChannel, but for our purposes here, the
compile-time constant will work just as well.
If it's set correctly, for Mozilla, we will perform our assert check. If it's not set to
esr (e.g. for Tor), they'll skip the assert. They probably want to control their user agent
themselves anyway.
MozReview-Commit-ID: DLnWSEpCVJ6
do_GetService("@mozilla.org/security/random-generator;1" may initialize NSS.
NSS Initialization occurs on Main Thread only.
If we lock on a subthread, then try to initialize NSS, it _might_ be the case
that the main thread is blocked on the same lock (same location or a different
one.) NSS can't initialize on Main Thread - deadlock.
Move do_GetService out of the lock. Now if NSS tries to initialize on a
subthread, the main thead can't be blocked (because the subthread hasn't locked
anything.)
Now, the only statements that occur in locks are pointer asignment, new, memcpy,
and randomGenerator->GenerateRandomBytes.
MozReview-Commit-ID: 9C1Ok910A11
Previously we needed this check because we were jittering before NSS was initialized
and this was causing tests to fail (primarily xpcshell and Marionette) because
NSS was being initialied before there was a profile directory.
In Bug 1443943 we only jitter non-System Principal calls and that reduces the early
jitter causes. Ultimately we got to a place where everything was looking okay whether
or not NSS was initialized by the time we got here, so we can simply this code and
simply always perform jittering (if it's enabled and we're not in System Principal
code.)
MozReview-Commit-ID: Dgfi8Z1hHfB
Note that by not using the same context pointer for all timestamps within a single
'communication group' (that is, all things that can communication to each other
in JavaScript), it's possible to observe time going backwards.
Imagine comparing
performance.timeOrigin + performance.now() < new File([], "").lastModified
In theory this should always be true. However, if performance.now() was jittered
up (using one context pointer, because it is a relative timestamp) and File was
jittered down (using a null context pointer, because it is an absolute timestamp)
then this may evaluate to False.
I think this is okay.
MozReview-Commit-ID: BfgbmGS8XdD
We need to include a seed for each context (origin, iframe, worker, etc) we reduce
the time precision of. This prevents a replay attack of the random midpoint sequence.
MozReview-Commit-ID: EFoHev1SrTM
Before, we would initialize LRUCache on the first instance of
calling the Timer Precision Reduction functions. We would both
allocate and initialize it, and call ClearOnShutdown.
ClearOnShutdown can only be called on the Main Thread, but it
just so happened that we always did that, so there was no
problem. Now that we are not calling precision reduction for
system callers, we were initializing on a non-main-thread and
we need to avoid that.
In the future, we could reduce memory use IF we are not using
the timer precision reduction functions by figuring out how
to initialize this lazily but still on the main thread. For
now, because we are using the timer precision reduction
functions, doing so would not save us any memory.
MozReview-Commit-ID: 6YGeAlCPReZ
Negative input times would carry a negative sign all the way
through to where we do pointer math. That's bad, and embaressing.
As far as I know, there was no way to have the resulting value be
outside [-32, 28]. We coerce it down to [0, 28] to always stay in
bounds.
Doing so caused nearly every xpcshell test to fail, as well as Marionette.
This is safe, because we're not going to be doing any web context stuff before NSS is
initialized, so anything that winds up here won't be exposed to content so we don't
really need to worry about fuzzing its value.
MozReview-Commit-ID: KiFSIbjQnN3
Time Precision Reduction in the JS Engine was handled by a small bit of
duplicated logic. With Time Jittering, and general improvements to the
logic due to float fuzziness, we want to unify the logic for the JS Engine
and the browser into one location. This patch does that.
Note that this will leave the JS Shell without a time jittering implementation.
It currently has a time clamping implementation - but I'm not actually sure if
the shell is doing anything with it, because it's probably not calling
SetTimeResolutionUsec to set it up. In Bug 1440539 we will add a jitter
implementation for the shell. (And probably turn time rounding and jittering on
for it too.)
MozReview-Commit-ID: 2BTIMzE8MjW
Fuzzytime deterministically generates a random midpoint between two clamped values,
and if the unreduced timestamp is above the midpoint, the time is rounded upwards.
This allows safe time jittering to occur, as time will never go backwards on a given
timeline.
It _is_ possible for time to go backwards when comparing different (but related)
timelines, such as a relative timeline in one page (with its own
performance.timeOrigin) and a relative timeline in an iframe or Worker (which
also has its own performance.timeOrigin). This is the same behavior as the 2ms timer
reduction we previously landed; jitter doesn't make this any better or worse.
MozReview-Commit-ID: IdRLxcWDQBZ
Time Precision Reduction in the JS Engine was handled by a small bit of
duplicated logic. With Time Jittering, and general improvements to the
logic due to float fuzziness, we want to unify the logic for the JS Engine
and the browser into one location. This patch does that.
Note that this will leave the JS Shell without a time jittering implementation.
It currently has a time clamping implementation - but I'm not actually sure if
the shell is doing anything with it, because it's probably not calling
SetTimeResolutionUsec to set it up. In Bug 1440539 we will add a jitter
implementation for the shell. (And probably turn time rounding and jittering on
for it too.)
MozReview-Commit-ID: 2BTIMzE8MjW
Fuzzytime deterministically generates a random midpoint between two clamped values,
and if the unreduced timestamp is above the midpoint, the time is rounded upwards.
This allows safe time jittering to occur, as time will never go backwards on a given
timeline.
It _is_ possible for time to go backwards when comparing different (but related)
timelines, such as a relative timeline in one page (with its own
performance.timeOrigin) and a relative timeline in an iframe or Worker (which
also has its own performance.timeOrigin). This is the same behavior as the 2ms timer
reduction we previously landed; jitter doesn't make this any better or worse.
MozReview-Commit-ID: IdRLxcWDQBZ
We eliminate float fuzziness by calculating the reduced precision using
integers in microseconds. (This means we automatically lose any granularity
about nanoseconds, but that's okay.)
MozReview-Commit-ID: D9ReLknsafo
This commit adds a gtest calling ReduceTimePrecision that illustrates several
failing test cases from float fuzziness, as well as generating a ton of test
cases at random that also fail.
MozReview-Commit-ID: Epia5gm5Ahb
This patch creates the capability to have callsites specify if timestamps
should be clamped only in Resist Fingerprinting Mode, or in the more expansive
Timer PRecision Reduction Mode.
Then it changes the CSS Animation callsite to only apply in RFP Mode.
This avoids regressing RFP.
MozReview-Commit-ID: B1pSri0kRk6
This patch makes Firefox to spoof keyboardEvent.code, keyboardEvent.keycode and
modifier states, for 'Shift', 'Alt', 'Control' and 'AltGraph', when 'privacy.resistFingerprinting'
is true. Firefox will spoof keyboard events as a certain keyboard layout according
to the content language of the document, for example, we use US English keyboard for
English content. Right now, it only supports English contents, we will add more
support for more languages later. The spoofing only affects content, chrome
can still see real keyboard events.
MozReview-Commit-ID: 40JPvwLmMMB
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
This pref does not override privacy.resistFingerprinting, but when it is set (and
privacy.resistFingerprinting is not) we will still adjust the precision of almost
all timers. The adjustment amount is the second pref, which is defaulted to
20us but now dynamically adjustable (in the scale of microseconds.)
This patch does _not_ address the performance API, which privacy.resistFingerprinting
disables.
We are landing this preffed on at the current value we clamp performance.now() at
which is 20us.
MozReview-Commit-ID: ESZlSvH9w1D
