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
