In bug 1773342 I made OS text scale factor behave like a full zoom
factor which applies to all pages (including the browser chrome). That's
generally straight forward but it makes some callsites that use unzoomed
CSS coordinates misbehave (or behave correctly accidentally actually in
some other cases).
The main fix here is making
nsIBaseWindow::UnscaledDevicePixelsPerCSSPixel() and
nsIScreen::GetDefaultCSSScaleFactor() account for OS zoom as necessary.
However, I also went through the relevant code and cleaned it up to use
typed units and operations when possible.
The setup means:
* nsIWidget::GetDefaultScale() doesn't account for OS full zoom.
* nsIBaseWindow and nsIScreen does.
These are the places where this should matter and stuff can get
confused, but this works surprisingly well for all callers (except one
nsDeviceContext one which we use only for PuppetWidget and we can
remove by falling back to 1.0 like all other widgets until the update
comes).
Differential Revision: https://phabricator.services.mozilla.com/D149033
In bug 1773342 I made OS text scale factor behave like a full zoom
factor which applies to all pages (including the browser chrome). That's
generally straight forward but it makes some callsites that use unzoomed
CSS coordinates misbehave (or behave correctly accidentally actually in
some other cases).
The main fix here is making
nsIBaseWindow::UnscaledDevicePixelsPerCSSPixel() and
nsIScreen::GetDefaultCSSScaleFactor() account for OS zoom as necessary.
However, I also went through the relevant code and cleaned it up to use
typed units and operations when possible.
The setup means:
* nsIWidget::GetDefaultScale() doesn't account for OS full zoom.
* nsIBaseWindow and nsIScreen does.
These are the places where this should matter and stuff can get
confused, but this works surprisingly well for all callers (except one
nsDeviceContext one which we use only for PuppetWidget and we can
remove by falling back to 1.0 like all other widgets until the update
comes).
Differential Revision: https://phabricator.services.mozilla.com/D149033
This is largely a straightforward find and replace of various methods, with the
unnecessary arguments removed and compiler errors fixed.
Differential Revision: https://phabricator.services.mozilla.com/D148532
It's used by the DevTools to emulate touch events from mouse events in the
responsive design mode. Therefore, we should make it accept IPC messages
even if it's not in the automation mode, but it's in the responsive design mode.
Differential Revision: https://phabricator.services.mozilla.com/D148365
This is used by in the normal mode (i.e., not in the automation mode) to
emulate a hover at locking or unlocking a pointer capture. If it'd be possible,
we should make it handle only in the remote process, but for now, we should
make it relax for safer fix in the branches. I think that it's acceptable
because synthesizing only native mousemove events is safer than the other events.
Differential Revision: https://phabricator.services.mozilla.com/D148364
For making this, `BrowserParent` (temporarily) store sent keyboard events which
wants reply from the remote process. Then, when it gets a reply event received,
it compares whether the event data is broken or not.
Differential Revision: https://phabricator.services.mozilla.com/D145944
Previously, even for remote in-process iframes, it was only possible to retrieve the top level BrowsingContext for the remote process by getting the managing BrowserParent.
This makes it possible to get the correct BrowsingContext even for in-process iframes.
Differential Revision: https://phabricator.services.mozilla.com/D147716
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
