For desktop this should basically have no impact (maybe impacts tab
warming, but if we wanted we could set the priority hint from the tab
switcher the same way we set renderLayers), but Fenix always has
renderLayers as true, effectively, so we were never de-prioritizing the
background tab processes.
Differential Revision: https://phabricator.services.mozilla.com/D145351
For desktop this should basically have no impact (maybe impacts tab
warming, but if we wanted we could set the priority hint from the tab
switcher the same way we set renderLayers), but Fenix always has
renderLayers as true, effectively, so we were never de-prioritizing the
background tab processes.
Differential Revision: https://phabricator.services.mozilla.com/D145351
This is fixing an oversight in a patch that was supposed to be functionally neutral.
https://hg.mozilla.org/mozilla-central/rev/22b568631834e556ab8351ac8458d5b24aa638bd#l1.49
The old code always called UpdateVsyncDispatcher, even if the widget's vsync
source was null, and then UpdateVsyncDispatcher fell back to using the global
vsync source when null was passed.
The new code skipped the call entirely when the vsync dispatcher was null,
so it prevented fallback to the global vsync dispatcher.
Now with this patch, we correctly fall back to the global vsync
dispatcher if the widget's dispatcher is null.
This code only runs on Linux wayland; on other platforms, BrowserParent::mVsyncParent
is always null because nothing calls AllocPVsyncParent.
Differential Revision: https://phabricator.services.mozilla.com/D145807
All users of nsIWidget::GetVsyncSource just want the dispatcher anyway.
Getting the dispatcher directly from the widget will allow us to remove VsyncSource::GetVsyncDispatcher.
Differential Revision: https://phabricator.services.mozilla.com/D144374
This doesn't change much; VsyncParent was already only using mVsyncSource
to obtain the VsyncDispatcher. (And to get the vsync rate, which it can
now get directly from the dispatcher.)
Differential Revision: https://phabricator.services.mozilla.com/D144370
All users of nsIWidget::GetVsyncSource just want the dispatcher anyway.
Getting the dispatcher directly from the widget will allow us to remove VsyncSource::GetVsyncDispatcher.
Differential Revision: https://phabricator.services.mozilla.com/D144374
This doesn't change much; VsyncParent was already only using mVsyncSource
to obtain the VsyncDispatcher. (And to get the vsync rate, which it can
now get directly from the dispatcher.)
Differential Revision: https://phabricator.services.mozilla.com/D144370
Otherwise we can return without the widget even seeing the event. This is how other test functions are implemented.
We need this to make the test in bug 1757928 pass.
Differential Revision: https://phabricator.services.mozilla.com/D142943
Prior behavior for active tabs in an inactive app would have the process priority oom score of 15. Now it's set to a higher priority oom score of 11. This will increase priority for recently used tabs on apps and prevent Android from unloading them.
Differential Revision: https://phabricator.services.mozilla.com/D142386
Prior behavior for active tabs in an inactive app would have the process priority oom score of 15. Now it's set to a higher priority oom score of 11. This will increase priority for recently used tabs on apps and prevent Android from unloading them.
Differential Revision: https://phabricator.services.mozilla.com/D142386
Prior behavior for active tabs in an inactive app would have the process priority oom score of 15. Now it's set to a higher priority oom score of 11. This will increase priority for recently used tabs on apps and prevent Android from unloading them.
Differential Revision: https://phabricator.services.mozilla.com/D142386
This patch replaces the previous process selection infrastructure with a
new setup implemented entirely in C++, which should more accurately
track the set of processes in use, and should encourage re-use of the
existing content process when navigating by not counting the current
tab.
This approach intentionally allows for process switching to another
process during navigation if there is uneven load between processes to
encourage balanced process use.
I think this may also fix some of the session restore issues with many
tabs using the same process, rather than being spread over 4, as we now
track a tab earlier in its lifecycle before the BrowserParent instance
is created.
Differential Revision: https://phabricator.services.mozilla.com/D126405
Users may map reserved shortcut keys of Firefox/Thunderbird as an editing
command or a navigation command. Therefore if and only if an editable element
has focus and a reserved key combination is mapped to an editing command or
a navigation command by the system settings, we should allow to dispatch it
into the content and work it as what user expects.
With this change, keyboard only users may loose some shortcut keys to leave
from a web content which blocks keyboard focus in it. However, there may
be another reserved shortcut keys to escape from such web apps only with
keyboard because it's hard to think that all reserved shortcut keys conflict
with users' settings.
Differential Revision: https://phabricator.services.mozilla.com/D138009
Querying selection for getting writing mode may run script in the main process
if focus is in it. For avoiding new users of writing mode at selection **only**
when the value is required during an editable content has focus,
`TextEventDispatcher` should always store writing mode at receiving focus
notification.
Differential Revision: https://phabricator.services.mozilla.com/D138008
I'd like to use it in `IMEData.h`. However, adding new include into it may
cause bustage with MinGW, and it's included by `nsIWidget.h` because `nsIWidget`
requires some classes defined in `IMEData.h`. Therefore, I'd like to make a
new header file for avoiding the include hell.
Differential Revision: https://phabricator.services.mozilla.com/D138007
This is introduced by bug 805939, but no one uses it.
Screen orientation information is handled by `hal::ScreenConfiguration` now.
Differential Revision: https://phabricator.services.mozilla.com/D136119
If the BrowsingContext is missing in ConstructBrowser, previously we would fail
out, crashing the content process. With this new change, we instead exit
successfully, destroying the `ManagedEndpoint` instances due to the earlier
changes in this bug, and displaying the subframe as crashed.
As we don't know how to reproduce the case which caused this crash, this change
instead triggers the failure using a custom pref, which can be used to request
that attempts to create a BrowserParent for a specific BrowsingContext fail in
the same way as it would for a missing BrowsingContext, allowing us to test the
behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D128778
This patch shouldn't change behavior at all.
This patch replaces a manual NS_ADDREF call with typesafe code that manages the
reference count for us. This reduces repeated boilerplate code, in the
implementation as well as the callsites.
Differential Revision: https://phabricator.services.mozilla.com/D127179
This patch shouldn't change behavior at all.
This patch replaces a manual NS_ADDREF call with typesafe code that manages the
reference count for us. This reduces repeated boilerplate code, in the
implementation as well as the callsites.
Differential Revision: https://phabricator.services.mozilla.com/D127179
This patch replaces the previous process selection infrastructure with a
new setup implemented entirely in C++, which should more accurately
track the set of processes in use, and should encourage re-use of the
existing content process when navigating by not counting the current
tab.
This approach intentionally allows for process switching to another
process during navigation if there is uneven load between processes to
encourage balanced process use.
I think this may also fix some of the session restore issues with many
tabs using the same process, rather than being spread over 4, as we now
track a tab earlier in its lifecycle before the BrowserParent instance
is created.
Differential Revision: https://phabricator.services.mozilla.com/D126405
This patch replaces the previous process selection infrastructure with a
new setup implemented entirely in C++, which should more accurately
track the set of processes in use, and should encourage re-use of the
existing content process when navigating by not counting the current
tab.
This approach intentionally allows for process switching to another
process during navigation if there is uneven load between processes to
encourage balanced process use.
I think this may also fix some of the session restore issues with many
tabs using the same process, rather than being spread over 4, as we now
track a tab earlier in its lifecycle before the BrowserParent instance
is created.
Differential Revision: https://phabricator.services.mozilla.com/D126405
We implement a new nsIDOMWindowUtils function sendNativeTouchpadPan to do this. It is only implemented on Windows here.
Depends on D122048
Differential Revision: https://phabricator.services.mozilla.com/D122049
