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
With the use of mStorageAccessPermissionGranted reduced to a single meaning, it turns out to be entirely redundant with the variable on the inner window.
Depends on D147867
Differential Revision: https://phabricator.services.mozilla.com/D147868
With the use of mStorageAccessPermissionGranted reduced to a single meaning, it turns out to be entirely redundant with the variable on the inner window.
Depends on D147867
Differential Revision: https://phabricator.services.mozilla.com/D147868
With the use of mStorageAccessPermissionGranted reduced to a single meaning, it turns out to be entirely redundant with the variable on the inner window.
Depends on D147867
Differential Revision: https://phabricator.services.mozilla.com/D147868
This allows us to replace a number of magic numbers in the
WebRequestError code with automatically generated constants which are
guaranteed to be kept up to date.
This build script is able to run early enough during the build step as
generated files which take a `.jinja` file as an argument are hard-coded
to be run during the pre-export phase for Android builds. As it is just
as simple python script with no other dependencies, this shouldn't
impact geckoview build performance even when using build artifacts.
Differential Revision: https://phabricator.services.mozilla.com/D146356
Previously the SessionHistoryInfo would hold onto and hand out the
original nsIInputStream objects which were provided by the
nsDocShellLoadState and used to create the underlying channel. This
could cause issues in edge cases, as input streams when serialized over
IPC have their logical owner transferred to the IPC layer so that it can
copy the data to the peer process.
This patch changes the logic to instead clone the input stream to and
from the history info. This means that the history info has its own
instance of the stream type and interacting with it shouldn't interfere
with other consumers of the post data stream.
The behaviour for non-SHIP session history is not changed, as it doesn't
serialize the relevant streams over IPC in the same way, and is on track to be
removed.
Differential Revision: https://phabricator.services.mozilla.com/D141047
Previously the SessionHistoryInfo would hold onto and hand out the
original nsIInputStream objects which were provided by the
nsDocShellLoadState and used to create the underlying channel. This
could cause issues in edge cases, as input streams when serialized over
IPC have their logical owner transferred to the IPC layer so that it can
copy the data to the peer process.
This patch changes the logic to instead clone the input stream to and
from the history info. This means that the history info has its own
instance of the stream type and interacting with it shouldn't interfere
with other consumers of the post data stream.
The behaviour for non-SHIP session history is not changed, as it doesn't
serialize the relevant streams over IPC in the same way, and is on track to be
removed.
Differential Revision: https://phabricator.services.mozilla.com/D141047
Previously the SessionHistoryInfo would hold onto and hand out the
original nsIInputStream objects which were provided by the
nsDocShellLoadState and used to create the underlying channel. This
could cause issues in edge cases, as input streams when serialized over
IPC have their logical owner transferred to the IPC layer so that it can
copy the data to the peer process.
This patch changes the logic to instead clone the input stream to and
from the history info. This means that the history info has its own
instance of the stream type and interacting with it shouldn't interfere
with other consumers of the post data stream.
The behaviour for non-SHIP session history is not changed, as it doesn't
serialize the relevant streams over IPC in the same way, and is on track to be
removed.
Differential Revision: https://phabricator.services.mozilla.com/D141047
Previously the SessionHistoryInfo would hold onto and hand out the
original nsIInputStream objects which were provided by the
nsDocShellLoadState and used to create the underlying channel. This
could cause issues in edge cases, as input streams when serialized over
IPC have their logical owner transferred to the IPC layer so that it can
copy the data to the peer process.
This patch changes the logic to instead clone the input stream to and
from the history info. This means that the history info has its own
instance of the stream type and interacting with it shouldn't interfere
with other consumers of the post data stream.
The behaviour for non-SHIP session history is not changed, as it doesn't
serialize the relevant streams over IPC in the same way, and is on track to be
removed.
Differential Revision: https://phabricator.services.mozilla.com/D141047
Because wireframes are collected together with the session history
entry for its docshell, we need to collect session history to make
sure that collected wireframes show up.
Differential Revision: https://phabricator.services.mozilla.com/D143368
This property defaults to false. When set to true, user-initiated link clicks in
the top-level BrowsingContext will default target to _blank. This is similar to what
we do for App Tabs, but is slightly more aggressive in that in will also occur for
same-origin navigations.
Differential Revision: https://phabricator.services.mozilla.com/D143374
This property defaults to false. When set to true, user-initiated link clicks in
the top-level BrowsingContext will default target to _blank. This is similar to what
we do for App Tabs, but is slightly more aggressive in that in will also occur for
same-origin navigations.
Differential Revision: https://phabricator.services.mozilla.com/D143374
Before this patch, nsISiteSecurityService APIs took "flags" parameters that
differentiated private contexts from not private contexts. However, these
parameters were redundant with respect to origin attributes, which led to some
confusion for consumers of these APIs. This patch removes these parameters in
favor of using origin attributes.
Differential Revision: https://phabricator.services.mozilla.com/D142901
In particular, gather telemetry to evaluate the impact of unlabeled UTF-8
and how detector-triggered reloads would change if ASCII-only at initial
guess was treated as UTF-8.
Differential Revision: https://phabricator.services.mozilla.com/D140818
multipart/x-mixed-replace loads don't start a new load for parts other than the first,
they just call OnStartRequest/OnStopRequest for every part. The nsDocShell code was
trying to set the active entry to the loading entry for these loads, but because we
never started a new load after the first part, the loading entry would be null and we'd
just clear the active entry. history.replaceState would then try to replace the active
entry, but finding none it would just add a new one.
Differential Revision: https://phabricator.services.mozilla.com/D138464
The previous version had two issues:
It revealed an issue in the old implementation which causes an assertion to fire.
There was also a problem with mDocumentRequest, so the new approach tries to be less clever
and just adds a new boolean member variable mCheckingSessionHistory,
which GetIsAttemptingToNavigate() then uses.
Differential Revision: https://phabricator.services.mozilla.com/D136041
