Currently tabs.onActivated (for the tab that becomes active after a tab is removed) fires before
tabs.onRemoved (for the tab that was removed). This is neither the order in which Chrome fires
these events, nor is it the order in which the internal TabSelect and TabClose happen in Firefox.
This bug fixes this so tabs.onActivated fires *after* tabs.onRemoved.
Note that this does introduce an issue in in-process mode, where window.close() will not
trigger a tabs.onRemoved event for the window, but Kris says "Meh" about that.
MozReview-Commit-ID: CrFR3jqL2u5
--HG--
extra : rebase_source : 5cc3d2a138bf812d13779e8ca1188b89ddbcdcc1
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
This additionally adds the edge cases that were found in bug 1397322
and bug 1397765.
MozReview-Commit-ID: 7CFEgePpOK1
--HG--
extra : rebase_source : 386741b3de775c1eb61f406364180e222e9f3011
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
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
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
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
BrandFullName is now defined in the branding files
MozReview-Commit-ID: 5wmInT9xbrT
--HG--
extra : rebase_source : e10448351ba4b1623c123eb87a1ddb69a1104cd0
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
