Also, avoid calling SendFindImageText() on unsupported platforms, so that
test_image_recognition_unsupported.html will pass.
Differential Revision: https://phabricator.services.mozilla.com/D191678
without this, permissions set in the main process that are site-scoped on origins with non-null ports are not pushed out to the content process.
Differential Revision: https://phabricator.services.mozilla.com/D186984
without this, permissions set in the main process that are site-scoped on origins with non-null ports are not pushed out to the content process.
Differential Revision: https://phabricator.services.mozilla.com/D186984
without this, permissions set in the main process that are site-scoped on origins with non-null ports are not pushed out to the content process.
Differential Revision: https://phabricator.services.mozilla.com/D186984
This IPC message is never used. about:support runs in the
parent process, and test_device_reset.html is a mochitest chrome,
so it also runs in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D187292
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
The parent process might be busy such that the time that passes between NotifyTabDestroying and ShutdownProcess can become significant in terms of activating the ShutdownKill timer too early. In order to avoid this, we will start the timer only after we actually sent the shutdown message.
To cover the time that passes between NotifyTabDestroying (right after sending a delete to the Browser actor) and the effective NotifyTabDestroyed (in response to the Browser actor destroy roundtrip through the content process), we add a second timer that triggers the sending of the shutdown message.
Differential Revision: https://phabricator.services.mozilla.com/D180959
