Mobile code now loads LoginManagerParent lazily, similar to
nsBrowserGlue on desktop, so we no longer need LoginManagerParent.login.
MozReview-Commit-ID: 8tnWnev344
The current timeout was added to deal with some shutdown deadlocks that were
happining in the wild, but were hard to reproduce locally and therefore
diagnose. It's not clear whether the bulk of those have been fixed, so I'm
reluctant to remove the timeout entirely.
But the current 1s timeout is quite short, and doesn't allow for proper
cleanup in a lot of legitimate cases. The async shutdown service starts to
emit warnings at 10s, so 8s gives us enough time to avoid at least that.
MozReview-Commit-ID: 94zZjYUY8qZ
--HG--
extra : rebase_source : 980cce2af1117d6d46f6083910672e3ef8702981
extra : histedit_source : d8d9b2d7f6312b5d8801e4e26d2b0c0a32a538c2
The main change here is to disconnect stream filters immediately if we try to
send start or data events to a window that's already been destroyed.
It also fixes a race where we end up in the wrong state if a stop event
arrives while the channel is being disconnected.
MozReview-Commit-ID: LwxXxoRUDgQ
--HG--
extra : rebase_source : 8c04e4be2f74850f28d642350b9ff268ab3206e4
extra : histedit_source : d0c18c9a190179431b81fdb32262a0324dc35762
During extremely short sessions (such as the ones triggered by many tests),
the code run by BackgroundPageThumbs during shutdown can trigger
hard-to-diagnose issues, among the most serious being a deadlock in the
service worker registrar.
Calling the (currently unused) _destroy() method at the start of shutdown
seems to prevent the majority of these problems.
MozReview-Commit-ID: Go7OLzVM24G
--HG--
extra : rebase_source : 7e5f619f8eed0e0ce3f1b94e8285d12a4be29d51
extra : histedit_source : 8b9c73b9e85a430381e2e1ee48e7fef5b56ab6e3
We were reusing "all sections" in more than one way, which isn't a globally-
permissable language use. Embedding the substring directly takes care of it
while at the same time embedding it within its context.
MozReview-Commit-ID: CTQhFWEajRo
--HG--
extra : rebase_source : 03b79c5bb19ad690b4ccba27c96bcc6a9f7f17a7
Not all of these probes are expiring in 58, but they are all (with the exception
of CONTENT_RESPONSE_DURATION) metrics that might be affected by WebRender, and
so are useful to continue measuring until WebRender is "done". The CONTENT_RESPONSE_DURATION
probe is indicating durations have dropped over the past few releases and it would be
useful to continue to measure this for a few more releases.
MozReview-Commit-ID: CTsOGuMS5f3
If we don't do this explicitly, the channel is automatically disconnected when
it's GCed. However, if we start shutdown while a stream is being processed,
the stream may not be GCed before we shut down the parent process's message
loop. In that case, we get a shutdown crash because the StreamFilterParent's
data channel is still open when we shut down its message loop.
Explicitly disconnecting the StreamFilter when the context is closed prevents
this, since app shutdown is automatically blocked on extension shutdown, and
extension shutdown explicitly closes all extant contexts.
MozReview-Commit-ID: 5JPrSUooq1j
--HG--
extra : rebase_source : d9af8c6b1c2107a726fead2aa0bbf9cc6f7b72e2
The GPU process doesn't have the directory service enabled, so it can't find
a tmp dir to put its .extra files for crash reports. Even if we do enable the
directory service, we still don't get the correct "content process tmp dir" in
the GPU process, because the UUID baked into that folder is passed via the
preferences service, and that isn't initialized in the GPU process either.
Rather than unneccessarily initialize all this stuff in the GPU process just
to get one folder name, we can pass that folder name directly in the argv list.
See comments 12-19 on the bug for further discussion of the various solutions
attempted/explored.
MozReview-Commit-ID: 1sFg27hIe7S
--HG--
extra : rebase_source : 78eb600a58fed45800b9df8303cc4d6898d96ae9
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 : fd963f1afd4a303a115466189b2044b4668ee0a3
We were reusing "all sections" in more than one way, which isn't a globally-
permissable language use. Embedding the substring directly takes care of it
while at the same time embedding it within its context.
MozReview-Commit-ID: CTQhFWEajRo
--HG--
extra : rebase_source : 4a4e25137086f112eeae8152b4867553e372ce03
Since we don't atomically retrieve session and subsession snapshots, there's
a possibility that off-thread accumulations can happen in between the two
getPayload calls in test_checkSubsessionHistograms.
CYCLE_COLLECTOR_WORKER* are the obvious first choice.
MozReview-Commit-ID: 5lseRAJ1Rg6
--HG--
extra : rebase_source : 219ed38e526483627792ed4c177f49c1537c3f07
The GPU process doesn't have the directory service enabled, so it can't find
a tmp dir to put its .extra files for crash reports. Even if we do enable the
directory service, we still don't get the correct "content process tmp dir" in
the GPU process, because the UUID baked into that folder is passed via the
preferences service, and that isn't initialized in the GPU process either.
Rather than unneccessarily initialize all this stuff in the GPU process just
to get one folder name, we can pass that folder name directly in the argv list.
See comments 12-19 on the bug for further discussion of the various solutions
attempted/explored.
MozReview-Commit-ID: 1sFg27hIe7S
--HG--
extra : rebase_source : 62ff819c5b03f642cd4b9af7c89c84b790397372
When a content crash is detected we run the minidump analyzer on it to extract
a stack trace that will be sent with the crash ping. Since this operation can
potentially take a long time this patch prevents it from happening if the
browser is already quitting. Already running instances of the minidump
analyzer are also killed. The patch includes test coverage for both the new
codepaths.
MozReview-Commit-ID: 4CQBp0v5KxE
--HG--
extra : rebase_source : 430d4ddad0780fe8fa0adfc8dd6728ab2eadbeaf
extra : amend_source : 3468542ab80d29cf98dfe9e10185215fedbe03b8
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
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
There's only one interesting case here: the active tab. When rendering the label
of an overflowing active tab into the fadeout mask surface, text rendering must
not use the font smoothing background color for dark vibrancy. Instead, it needs
to use the color of the tab itself for best results.
Alternatively, we could set the font smoothing background color of the active
tab to "transparent", because this text is not on top of a vibrant background.
However, doing so would lose the subpixel AA and would not look as crisp.
MozReview-Commit-ID: 28MKCz1vmb9
BrandFullName is now defined in the branding files
MozReview-Commit-ID: 5wmInT9xbrT
--HG--
extra : rebase_source : e10448351ba4b1623c123eb87a1ddb69a1104cd0
Add a `--screenshot` argument that implies `--headless` and is used to take a screenshot of a page from the command line.
Default is a full page screenshot, but `--window-size=width[,height]` can change this.
A path for the screenshot can be supplied with `--screenshot=/path/to/file`.
MozReview-Commit-ID: 13tUjk2Yrsl
--HG--
extra : rebase_source : d26ed0856af882ad52a606941685b2c91577d3bf
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
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
Aside from moving this logic closer to the place the input data is generated,
this significantly reduces the number of cross-compartment wrappers involved
in creating those messages, especially with JSM global sharing enabled.
MozReview-Commit-ID: 6IvetcHnMfC
--HG--
extra : rebase_source : 0f97464ee9840ac40a6882e70e99d5b6c566c5ef
Also extend activeAddons records with a started flag to avoid
double-starting extensions that are upgraded during the startup check.
MozReview-Commit-ID: FPX71Q3lSrw
--HG--
extra : rebase_source : 06b9be6748d09ddee310882c342e6b12cfedf91b
extra : source : 3977730d0f477e54631db184bcb24b13f83e328b
Also extend activeAddons records with a started flag to avoid
double-starting extensions that are upgraded during the startup check.
MozReview-Commit-ID: FPX71Q3lSrw
--HG--
extra : rebase_source : a168cb6bb2343bc5a329a604d3b36e13c714452f
extra : source : 3977730d0f477e54631db184bcb24b13f83e328b