Because we read 8 bits from extradata, it won't exceed MAX_SPS/PPS_COUNT (256).
MozReview-Commit-ID: 5qr1pDLrmvt
--HG--
extra : rebase_source : 4a7269a7430ea913650298ad06a2132297dad85d
We have been using a different zone allocator between mozjemalloc and
replace-malloc for a long time. Jemalloc 4 uses the same as
replace-malloc, albeit as part of the jemalloc upstream code base.
We've been bitten many times in the past with Apple changes breaking the
zone allocator, and each time we've had to make changes to the three
instances, although two of them are similar and the changes there are
straightforward.
It also turns out that the way the mozjemalloc zone allocator is set up,
when a new version of OSX appears with a new version of the system zone
allocator, Firefox ends up using the system allocator, because the zone
allocator version is not supported.
So, we use the same zone allocator for both replace-malloc and
mozjemalloc, making everything on par with jemalloc 4.
--HG--
extra : rebase_source : 9c0e245b5f82bb71294370d607e690c05cc89fbc
The intent here is to reuse the zone allocator for mozjemalloc, to avoid
all the shortcomings of mozjemalloc using a different one. This change
only moves the replace-malloc zone allocator out of replace-malloc.c, to
make changes for mozjemalloc integration clearer.
--HG--
rename : memory/build/replace_malloc.c => memory/build/zone.c
extra : rebase_source : 8b98efaa4a88862f2967c855b511e92beb9c4031
Somehow, we never called those hooks when replace-malloc is enabled. I'd
expect this to cause random deadlocks when forking, and I'm surprised
this hasn't surfaced. Maybe it actually causes some intermittent oranges
on automation, who knows.
This also brings consistency with what is done for jemalloc 4, and with
the mozjemalloc implementation, too, that we're going to replace with
this one in a subsequent changeset.
--HG--
extra : rebase_source : 059567d17f928098db8367e9081b631ced351110
Unfortunately tinting the bookmark star is highly complicated due to the tinting
that NavigationView performs (i.e. we'd likely have to disable NavigationView
tinting, and do manual tinting on every icon - alternatively we could hack
the tint-list to use blue for "checked" items, and set the bookmark item
as checked). Since it's unclear if we even want the star to be blue,
we'll leave it grey (but filled) for now.
MozReview-Commit-ID: DekRZJayKIz
--HG--
extra : rebase_source : 1e3443e5f09c60bd0d7295bc35ecc08ca17b3dab
See https://code.google.com/p/android/issues/detail?id=209558 . On Devices
running Android 4 and below, VectorDrawable's can be corrupted due
to overzealous proguarding. This doesn't appear to have been
fixed in the support library yet, and even if it were fixed we
still wouldn't be able to switch to the most modern support
library without significant work.
MozReview-Commit-ID: 3ByogGygCEd
--HG--
extra : rebase_source : 2adeed63f88ca39a71feec60627fb812b76d3bb4
Since Bug 854126 landed there's not a restriction on private windows
with lightweight themes anymore and no need for this verification
MozReview-Commit-ID: 4uQxfbtqO7G
--HG--
extra : rebase_source : d2cccfee36d3fd6894652d13eb8426af0e9699ea
- `totalCyclesDelta` is incremented whenever there is CPU usage in the topmost compartment *and* the execution of the topmost compartment stops on the same core as it started;
- each individual `cyclesDelta` is incremented whenever there is CPU usage in a compartment *and* the execution of the compartment stops on the same core as it started;
- however, with previous versions of Windows, the function to identify a core was not available, so the check was #ifdef-ed away.
It is therefore entirely possible that, at some point during the execution of a mochitest, the thread is rescheduled to another core in a way such that at least one compartment executes entirely on a core but the topmost compartment starts and stops on a different core.
Given that we're running on VMs that presumably run on timeshared servers, reschedulings are bound to be frequent, so it's hardly surprising that this always happens during the execution of mochitests.
The simplest would probably be to throw away results if `cyclesDelta > totalCyclesDelta` for any of `cyclesDelta`. We should check if this happens and, if so, reset stuff without actually committing data.
MozReview-Commit-ID: 3w2D1gtW4AQ
--HG--
extra : rebase_source : 251455d8a3450795eb9dcb05c46f6c4d6e2c7810
When MFT returns MF_E_NOTACCEPTING means the input buffer is full and it can't
accept input data anymore, so we need to output the data first and then resummit
the input data.
MozReview-Commit-ID: DfSTASsEX7r
--HG--
extra : rebase_source : fd3cff6284345872dd580fbd0568d99129af936c
Restore overwriting of this._sourceBrowser as it was before bug 1308621
to ensure we continue to use the same DOM to do print previewing (and
eventually printing).
Bug 1308621 already changed the enterPrintPreview code to rely on the
member _sourceBrowser variable, which will be updated to point to the
print preview browser if/when print preview is being reinitialized for
the same page (because one of the print settings changes). We need to
do this to avoid re-initializing off the original browser, which may
now have navigated or be displaying something else entirely.
This also updates the 'simplified' mode code to rely on the extant
_originalURL member to avoid displaying the page URL as about:blank
after a settings change.
MozReview-Commit-ID: DZ1kT7Mb0mS
--HG--
extra : rebase_source : cb79c835d6f8bcd67a7118de3a19b1cab85b6593
Previously if we could not compare two icon descriptions we'd always return the "right" one. This does
not create a consistent order if the parameters are flipped. As a result some operations on a TreeSet
can fail (like remove()).
MozReview-Commit-ID: EYPlhzGUEnD
--HG--
extra : rebase_source : f8918c022188401e21a03ac666628cff3e87f317
