In V2 we shuffled the hash entries before sending the request to obscure the real
entry from noises. We should also hide the real entry in V4. Using sort() is
enough for both V2 and V4 because the array contains exactly 5 entries in almost
all cases.
MozReview-Commit-ID: 4uOXIF83KQL
--HG--
extra : rebase_source : 97c6439965e864863dc99f194356eb1efb0235df
This is the Servo side change for [bug 1336540](https://bugzilla.mozilla.org/show_bug.cgi?id=1336540)
Source-Repo: https://github.com/servo/servo
Source-Revision: 0ad0641872b5fc8139c84159ccec484ab4c3e265
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 1228206e2754696df4465fbc07223a28d682f9c1
The external helper app service waits for a second before closing the window,
which could lead to races. Also wait for the tab to close to avoid similar
races, there.
MozReview-Commit-ID: IdxNWRPheoY
--HG--
extra : rebase_source : 7b53e9690ad64994c5b8c5f6aa2a7f80db9a6a04
Since MozPromise supports move-only types, we don't need to make MetadataHolder a ref-counted type.
MozReview-Commit-ID: E7KJuFQNWxe
--HG--
extra : rebase_source : d303c4d119504a289fe60cf5cdd2793ebf58d643
Technically speaking, we use the new async API 'nsIURIClassifier.asyncClassifyLocalWithTables'
to replace the old sync API. However, since we cannot guarantee the async call will be done when
we neet its result, we need a sync call as a fallback in this case. This is a sub-optimal
solution and we will be investigating if there's a better solution if the sync call
is used too frequently.
MozReview-Commit-ID: L1uQ2eaYr1e
--HG--
extra : rebase_source : 148e0e85796c932ea85d123092f479e1373ecec9
extra : intermediate-source : 53007a31b576fcd4f16ad6523cccd0a9b90c66f0
extra : source : 1175b9c64b31da2ca2ab88f78488aed6fdc405bc
The changes here:
1. Make it easier to discover where nsIPKCS11 is implemented / make it easier to
discover what the file implements.
2. Reduce global scope pollution.
3. Make nsCrypto.h no longer unnecessarily exported.
4. Remove NS_CRYPTO_CONTRACTID from nsDOMCID.h, since the define isn't used
anywhere.
5. Move the definition of NS_PKCS11_CONTRACTID from nsDOMCID.h into PSM code,
since this contract ID is firmly in PSM territory now.
MozReview-Commit-ID: 2PdFM0mlL4R
--HG--
rename : security/manager/ssl/nsCrypto.cpp => security/manager/ssl/PKCS11.cpp
rename : security/manager/ssl/nsCrypto.h => security/manager/ssl/PKCS11.h
extra : rebase_source : 46667edef5a1d8c910d96dec1125c05bc3477bee
This has the implementation of grid's `<track-list>` nightmare.
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#15311
<!-- Either: -->
- [x] There are tests for these changes
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: 0b3fd8de767c6ad6ea2fd983c396f5c0a20becfc
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : da14c9edfdea19e5909b44215f4a39492512a9cd
The eslint-plugin-mozilla currently searches for Mozilla Central root by
walking up from its installed dir. However, if the plugin is installed outside
of central, such as globally, it will not find the root. This changeset
retains that behaviour, but will also perform the same check from the current
working directly before failing.
MozReview-Commit-ID: 2L3JqLTuVDS
--HG--
extra : rebase_source : e24ddc726cb2470f7165f028f71416e942c44f87
It's a Solaris-only optimization that was used as a workaround for some
infinite loop in pages_map (bug 457189). In the meanwhile, the way
pages_map works has changed in such a way the infinite loop can't happen
anymore.
Specifically, the original problem was that pages_map would try to
allocate something larger than a chunk, then deallocate it, and
reallocate at a hinted aligned address near the address of the now
deallocated mapping, hopefully getting an aligned chunk. But Solaris
would ignore the hint and the chunk would never be aligned, causing the
infinite loop.
What the code does now it over-allocate, find an aligned chunk in there,
and deallocate what ends up not being needed. Which leaves no room for
the original infinite loop.
We thus remove the workaround and put Solaris in par with other Unix
platforms.
--HG--
extra : rebase_source : 9ce4509d9c5ac6123cedabf87c5738672af35d1b
In Gecko code, MOZ_RELEASE_ASSERT means assertions that happen on all
types of builds.
In mozjemalloc, RELEASE_ASSERT means assertions that happen when
MOZ_JEMALLOC_HARD_ASSERTS is set, otherwise normal assertions. Which is
confusing. On the other hand, it's very similar to
MOZ_DIAGNOSTIC_ASSERT, and we may just want to use that instead.
Moreover, with release promotion, the check setting
MOZ_JEMALLOC_HARD_ASSERTS means releases (promoted from beta) would end
up with those asserts while they're not meant to, so
MOZ_DIAGNOSTIC_ASSERT is actually closer to the intent. It however means
we'd lose the beta population running those assertions.
--HG--
extra : rebase_source : 606ab47af8d9ee793b13b806acadb9781c99a078
Support for them was only enabled on debug builds, and required an
opt-in through e.g. MALLOC_OPTIONS to actually enable at runtime.
--HG--
extra : rebase_source : 60c27585c2901a73eb790cec124b880c93da6ef7
While it makes sense for a global system allocator, it's not really
interesting for Firefox to respect that. Plus, newer versions of
jemalloc, which are more likely to be used as a global system allocator
use a different format for the options passed through that file.
--HG--
extra : rebase_source : 0f2283cf5660bc437bd097bf48c2b5989fa08011
Those options, complementing the MALLOC_OPTIONS environment variable,
were always empty since the removal of b2g.
--HG--
extra : rebase_source : 0e34cfce0b537ebb8ed3902bd46180dc205cb0e4
