This changes comes with several different refactorings all rolled into one,
unfotunately I couldn't find a way to pull them apart:
- First of all annotations now can either recorded (that is, we copy the value
and have the crash reporting code own the copy) or registered. Several
annotations are changed to use this functionality so that we don't need to
update them as their value change.
- The code in the exception handler is modified to read the annotations from
the mozannotation_client crate. This has the unfortunate side-effect that
we need three different bits of code to serialize them: one for annotations
read from a child process, one for reading annotations from the main process
outside of the exception handler and one for reading annotations from the
main process within the exception handler. As we move to fully
out-of-process crash reporting the last two methods will go away.
- The mozannotation_client crate now doesn't record annotation types anymore.
I realized as I was working on this that storing types at runtime has two
issues: the first one is that buggy code might change the type of an
annotation (that is record it under two different types at two different
moments), the second issue is that types might become corrupt during a
crash, so better enforce them at annotation-writing time. The end result is
that the mozannotation_* crates now only store byte buffers, track the
format the data is stored in (null-terminated string, fixed size buffer,
etc...) but not the type of data each annotation is supposed to contain.
- Which brings us to the next change: concrete types for annotations are now
enforced when they're written out. If an annotation doesn't match the
expected type it's skipped. Storing an annotation with the wrong type will
also trigger an assertion in debug builds.
Differential Revision: https://phabricator.services.mozilla.com/D195248
This seems to work, and turns out I need to fix this before bug 1847584,
because the epoch handling breaks with those patches in the case
customize mode sets display: none on browser elements.
Instead of dealing with epochs, just always report the last "has layers"
state to BrowserParent. This is both simpler and more reliable (there
were a couple hacks in WebRenderBridgeParent to make sure we notified
even though a transaction failed).
AsyncTabSwitcher pretty much already deals with this correctly because
it already needs to deal with browsers that already have layers, we only
had to loosen some assertions for potentially previous messages which
are fine.
Differential Revision: https://phabricator.services.mozilla.com/D187203
This bug uses the existing process hang messaging infrastructure to raise priorities on main threads. To ensure reduced latency, we also increase the priority of ProcessHangMon threads. We also address an edge-case bug where flipping the QoS prefs during use might lead to a tab getting stuck at the wrong priority.
Due to increasing the priority of the hang monitor thread, we may see some increase in its utilization on MacOS during high CPU load. I'm not sure the extent of how this may impact the browser, but as it makes the thread "faster" it may be more responsive than some other threads during this case.
I tested thread responsiveness by using the stress tool and dispatching various numbers of worker threads, up to 250. During these tests, even when other parts of firefox were less responsive under stress, tab switching appeared to remain snappy and responsive.
I captured some updated power profiles using the change. Profile where pref flipped off during use: https://share.firefox.dev/46BksO3 (Note that we start with the prefs on, then we flip off the prefs half way and repeat the same behavior to observe the fix to the previous bug that left tabs trapped in the background)
Profile with the pref fully enabled: https://share.firefox.dev/46EBIC7
In regards to the edge case, to avoid spurious tab wakeups, we won't reinstate normal thread priority when pref is disabled until the tab is interacted with again.
Differential Revision: https://phabricator.services.mozilla.com/D182787
This bug uses the existing process hang messaging infrastructure to raise priorities on main threads. To ensure reduced latency, we also increase the priority of ProcessHangMon threads. We also address an edge-case bug where flipping the QoS prefs during use might lead to a tab getting stuck at the wrong priority.
Due to increasing the priority of the hang monitor thread, we may see some increase in its utilization on MacOS during high CPU load. I'm not sure the extent of how this may impact the browser, but as it makes the thread "faster" it may be more responsive than some other threads during this case.
I tested thread responsiveness by using the stress tool and dispatching various numbers of worker threads, up to 250. During these tests, even when other parts of firefox were less responsive under stress, tab switching appeared to remain snappy and responsive.
I captured some updated power profiles using the change. Profile where pref flipped off during use: https://share.firefox.dev/46BksO3 (Note that we start with the prefs on, then we flip off the prefs half way and repeat the same behavior to observe the fix to the previous bug that left tabs trapped in the background)
Profile with the pref fully enabled: https://share.firefox.dev/46EBIC7
In regards to the edge case, to avoid spurious tab wakeups, we won't reinstate normal thread priority when pref is disabled until the tab is interacted with again.
Differential Revision: https://phabricator.services.mozilla.com/D182787
We want to signal content processes to cancel content JS unconditionally on shutdown.
In the case of parent shutdown this has to happen as early as "quit-application-granted", given that both extensions and session storage shutdown rely on the possibility to interact with content processes (which is not possible when they are inside long running JS).
In addition in the case of a normal child shutdown we cancel content JS execution, too.
For now we put this behind the pref "dom.abort_script_on_child_shutdown" which remains default off.
Depends on D150539
Differential Revision: https://phabricator.services.mozilla.com/D150598
We want to signal content processes to cancel content JS unconditionally on shutdown.
In the case of parent shutdown this has to happen as early as "quit-application-granted", given that both extensions and session storage shutdown rely on the possibility to interact with content processes (which is not possible when they are inside long running JS).
In addition in the case of a normal child shutdown we cancel content JS execution, too.
For now we put this behind the pref "dom.abort_script_on_child_shutdown" which remains default off.
Depends on D150539
Differential Revision: https://phabricator.services.mozilla.com/D150598
We want to signal content processes to cancel content JS unconditionally on shutdown.
In the case of parent shutdown this has to happen as early as "quit-application-granted", given that both extensions and session storage shutdown rely on the possibility to interact with content processes (which is not possible when they are inside long running JS).
In addition in the case of a normal child shutdown we cancel content JS execution, too.
For now we put this behind the pref "dom.abort_script_on_child_shutdown" which remains default off.
Depends on D150539
Differential Revision: https://phabricator.services.mozilla.com/D150598
If run late in shutdown, we cannot rely on any of our normal infrastructure to be still in place. This patch collects a series of additional guards to avoid potential crashes.
Not all of them might ever been hit, but there is no harm in additional checks as this is not performance critical at all.
Differential Revision: https://phabricator.services.mozilla.com/D143687
HangData is the only member left in the union and SLOW_SCRIPT is the only member left in the enum.
This patch also migrates the one remaining (invalid) use of PLUGIN_HANG in testing to work as a SLOW_SCRIPT instead.
Differential Revision: https://phabricator.services.mozilla.com/D113885
This is the second of two patches in this series that removes a large amount of now dead code from dom/plugins as part of removing all NPAPI plugin support.
Differential Revision: https://phabricator.services.mozilla.com/D107150
This is the first of two patches in this series that removes a large amount of now dead code from dom/plugins as part of removing all NPAPI plugin support. This patch removes re-entrancy guards we have for Windows OnPaint messages, as the guards were only needed for windowed plugins.
Differential Revision: https://phabricator.services.mozilla.com/D107144
This is the second of two patches in this series that removes a large amount of now dead code from dom/plugins as part of removing all NPAPI plugin support.
Differential Revision: https://phabricator.services.mozilla.com/D107150
This is the first of two patches in this series that removes a large amount of now dead code from dom/plugins as part of removing all NPAPI plugin support. This patch removes re-entrancy guards we have for Windows OnPaint messages, as the guards were only needed for windowed plugins.
Differential Revision: https://phabricator.services.mozilla.com/D107144
This never actually worked, because nothing ever listened to the notification
sent in XPCJSContext (kill-content-script-sandbox). We're also removing the
"Temporarily disable extension" button in the slow addon notification, which
was the primary caller of this - however, that's in a separate patch.
Differential Revision: https://phabricator.services.mozilla.com/D110583
No need to access top level doc. Disabling bfcaching on any subframe prevents bfcaching of the top level page.
(There may be other issues around stopping slow scripts in Fission.)
Differential Revision: https://phabricator.services.mozilla.com/D109400
See bug for more details, but effectively the decision is to show the same
notification which we would normally show for hung pages if an iframe hangs,
but only do so if the user is trying to interact with content hung by that
iframe. This should accomplish that.
Differential Revision: https://phabricator.services.mozilla.com/D107933
Note that this patch only transforms the use of the nsDataHashtable type alias
to a directly equivalent use of nsTHashMap. It does not change the specification
of the hash key type to make use of the key class deduction that nsTHashMap
allows for in some cases. That can be done in a separate step, but requires more
attention.
Differential Revision: https://phabricator.services.mozilla.com/D106008
