Mobile code now loads LoginManagerParent lazily, similar to
nsBrowserGlue on desktop, so we no longer need LoginManagerParent.login.
MozReview-Commit-ID: 8tnWnev344
--HG--
extra : rebase_source : f2e9d5e2be13156032d827ee67f960f96c87345c
Search would leave text in the input field when switching categories,
show a 'No search results' message on load, and show a 'No search results'
message in sections without search inputs.
Tidy those cases away.
MozReview-Commit-ID: BbkgIjq8fYD
--HG--
extra : rebase_source : 0ce7a88f05a8919275e46f8d1c44df33fd83b135
The files relevant to the memory allocator are currently spread between
memory/mozjemalloc and memory/build, and the distinction was
historically from sharing some Mozilla-specific things between
mozjemalloc and jemalloc3. That distinction is not useful anymore, so
we fold everything together.
As we will likely rename the allocator at some point in the future, it
is preferable to move away from the mozjemalloc directory rather than in
its direction.
--HG--
rename : memory/mozjemalloc/Makefile.in => memory/build/Makefile.in
rename : memory/mozjemalloc/mozjemalloc.cpp => memory/build/mozjemalloc.cpp
rename : memory/mozjemalloc/mozjemalloc.h => memory/build/mozjemalloc.h
rename : memory/mozjemalloc/mozjemalloc_types.h => memory/build/mozjemalloc_types.h
rename : memory/mozjemalloc/rb.h => memory/build/rb.h
Since LinearHistogram and its descendants inherit ranges_ from
Histogram, and we wanted to replace the copying into a std::vec
for Histogram, the simplest approach seemed to just be to
precompute ranges for all histograms, exponential or otherwise.
This should have the added benefit of reducing the memory
footprint for those histograms, since they will benefit from the
deduplication work that the precomputing script already does.
MozReview-Commit-ID: JTV5Dej5ZIb
--HG--
extra : rebase_source : de942d54b3475be54c70d43d2fa8e772ee2e18c4
This is a fairly small optimization - since the indices for this
array never exceed the size of an int16_t, let's just use that
instead to save a little bit of space.
MozReview-Commit-ID: 8bRokjlvZ9p
--HG--
extra : rebase_source : b74bd0d6c36ecbb83db8ce6659f1484bfa3b885e
Since we already have the indices array, we can just point duplicate
ranges at the first occurrence's index.
MozReview-Commit-ID: 3f5os1xSp89
--HG--
extra : rebase_source : 68a859716aeafd3330b4b0b728f77c537a5020aa
Search would leave text in the input field when switching categories,
show a 'No search results' message on load, and show a 'No search results'
message in sections without search inputs.
Tidy those cases away.
MozReview-Commit-ID: BbkgIjq8fYD
--HG--
extra : rebase_source : 3d1b02d6c29096c42cdcce795689214b44b8cf00
This patch gently removes support for __exposedProps__ by changing
ExposedPropertiesOnly::check() to always return false, while still
failing silently in deny for some kinds of access.
The tests that I changed all involve testing the behavior with
__exposedProps__. I adjusted them to expect it to fail, or to adjust
the error message they get when they fail. That seemed better than
deleting them entirely.
Note that test_bug1065185.html had a bug, so that it never executed
the first case. I fixed that, and then fixed up the test to work when
__exposedProps__ is not supported.
This also removes various bits of the test framework that use
__exposedProps__, but don't actually need to.
MozReview-Commit-ID: 8fvkAmITmXY
--HG--
extra : rebase_source : ef7e2c55adc12511f17f3865ebb46c343875f0b3
We currently call has() every time we do a DefaultMap/DefaultWeakMap lookup,
which unfortunately shows up a lot in profiles. We only actually need to
check, though, if get() returns an undefined value.
Similar things in other places, where we only need to do a has() call if
another operation fails.
MozReview-Commit-ID: 9qFWsb4vlZj
--HG--
extra : rebase_source : 94c231fa007744f733faa9fdbde38a3875e10e7d
