The getter used to return CSS pixels, while the setter expected layout
device pixels. The nsIDocShellTreeOwner documentation used to suggest that
CSS pixels are used for getters and setters of the primary content and
the root shell size. Only the getter for the primary content size
happend to match that documentation.
Differential Revision: https://phabricator.services.mozilla.com/D161944
The getter used to return CSS pixels, while the setter expected layout
device pixels. The nsIDocShellTreeOwner documentation used to suggest that
CSS pixels are used for getters and setters of the primary content and
the root shell size. Only the getter for the primary content size
happend to match that documentation.
Differential Revision: https://phabricator.services.mozilla.com/D161944
Without flushing the layout, new windows appear to the opener to
initially open at the size of the opener instead of the specified size.
We can flush the layout unconditionally when we have a specified size
where we otherwise would make sure that the frame loader has been
reflowed at least once.
Thanks to Emilio for providing the changes to avoid tokenizing the
window features twice.
Differential Revision: https://phabricator.services.mozilla.com/D158584
If we don't preserve the precursor principal in this case, we'll end up
doing an unnecessary process switch in some cases, which lead to a
test failure.
This patch also cleans up some logic around the first party origin
attribute with null principals, as the logic was only used in one place
and generally added some unnecessary complexity to NullPrincipal
itself.
Differential Revision: https://phabricator.services.mozilla.com/D155277
Previously we would copy session storage even if we were not opening a new
window, meaning that a targeted load could re-trigger a copy. This was not
specified in the standard so is being changed to only copy when a new window is
created. In addition, the copy was moved before navigaton starts, again for
more consistency with ordering for the standard, such that things like
`javascript:` URI loads will oberve the up-to-date session storage.
Differential Revision: https://phabricator.services.mozilla.com/D154566
The `newBC` and `newDocShell` variables were potentially confusing, as they
could also be existing windows selected by named targeting or the window
provider, so they have been renamed. Some other variables were also renamed for
consistency and clarity.
Differential Revision: https://phabricator.services.mozilla.com/D154565
When opening a window with `noopener`, we will no longer inherit the
subject principal into the newly created window's initial about:blank
document, instead creating a new null principal.
This patch also makes the system/expanded principal -> null principal
translation happen earlier (it previously happened in
SetInitialPrincipalToSubject), so that it can be followed more easily
when reading the code.
Finally, the load started by nsWindowWatcher in new windows is updated
to specify `LOAD_FLAGS_DISALLOW_INHERIT_PRINCIPAL` when noopener is
specified such that the explicit about:blank load also cannot inherit
the subject principal.
This change does make it so that the global is not re-used between the
initial and loaded about:blank document, however this shouldn't be
visible due to `noopener` being specified, preventing any references to
the initial document from existing.
Noopener loads with `javascript:` URIs will be rejected early during the
load due to the mismatch between the triggering principal and the
initial about:blank document's principal.
Differential Revision: https://phabricator.services.mozilla.com/D154564
Previously we would pull this information frequently from the subject
principal, which is unreliable. With this new approach, we more explicitly pass
the principals around as-needed into where they're going to be used.
Some assertions about the subject principal were introduced to ensure that
assumptions made about chrome windows and the system principal are not
incorrect.
Differential Revision: https://phabricator.services.mozilla.com/D154563
Previously we would copy session storage even if we were not opening a new
window, meaning that a targeted load could re-trigger a copy. This was not
specified in the standard so is being changed to only copy when a new window is
created. In addition, the copy was moved before navigaton starts, again for
more consistency with ordering for the standard, such that things like
`javascript:` URI loads will oberve the up-to-date session storage.
Depends on D154565
Differential Revision: https://phabricator.services.mozilla.com/D154566
The `newBC` and `newDocShell` variables were potentially confusing, as they
could also be existing windows selected by named targeting or the window
provider, so they have been renamed. Some other variables were also renamed for
consistency and clarity.
Depends on D154564
Differential Revision: https://phabricator.services.mozilla.com/D154565
When opening a window with `noopener`, we will no longer inherit the
subject principal into the newly created window's initial about:blank
document, instead creating a new null principal.
This patch also makes the system/expanded principal -> null principal
translation happen earlier (it previously happened in
SetInitialPrincipalToSubject), so that it can be followed more easily
when reading the code.
Finally, the load started by nsWindowWatcher in new windows is updated
to specify `LOAD_FLAGS_DISALLOW_INHERIT_PRINCIPAL` when noopener is
specified such that the explicit about:blank load also cannot inherit
the subject principal.
This change does make it so that the global is not re-used between the
initial and loaded about:blank document, however this shouldn't be
visible due to `noopener` being specified, preventing any references to
the initial document from existing.
Noopener loads with `javascript:` URIs will be rejected early during the
load due to the mismatch between the triggering principal and the
initial about:blank document's principal.
Depends on D154563
Differential Revision: https://phabricator.services.mozilla.com/D154564
Previously we would pull this information frequently from the subject
principal, which is unreliable. With this new approach, we more explicitly pass
the principals around as-needed into where they're going to be used.
Some assertions about the subject principal were introduced to ensure that
assumptions made about chrome windows and the system principal are not
incorrect.
Differential Revision: https://phabricator.services.mozilla.com/D154563
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
Compute x and y on desktop pixels based on the old screen and use CSS
pixels for the rest.
Use well-typed units to prevent silly mistakes to the extent possible.
Differential Revision: https://phabricator.services.mozilla.com/D138646
Add BrowsingContext::FieldValues.mIsPopupRequested, and pass "is popup"
value calculated before opening window/tab to BrowsingContext::CreateDetached.
Other code path that is unrelated to content-priv window.open uses the
default value false.
Differential Revision: https://phabricator.services.mozilla.com/D129411
Removed "width" feature from the popup condition, and removed related parameters
(aWidthSpecified, and aSizeSpec) from functions.
Also added "popup" feature that explicitly specify whether to request popup or
not.
This is only for content context, and it behaves differently than existing
"popup" feature for chrome context that makes the window no-style.
Differential Revision: https://phabricator.services.mozilla.com/D129410
This simplifies the chromeFlag calculation for:
* chrome-priv case, by removing not-fully-chrome-priv case
* content case, by removing presenceFlag calculation
both by removing the special case for
nsGlobalWindowOuter::Print and nsDocShell::PerformRetargeting,
that has chrome caller but no chrome parent.
Code path for nsGlobalWindowOuter::Print and nsDocShell::PerformRetargeting
now uses the content case instead of the chrome-priv case, but the resulting
flag doesn't change (CHROME_ALL) for those 2 consumers.
Differential Revision: https://phabricator.services.mozilla.com/D129530
Add BrowsingContext::FieldValues.mIsPopupRequested, and pass "is popup"
value calculated before opening window/tab to BrowsingContext::CreateDetached.
Other code path that is unrelated to content-priv window.open uses the
default value false.
Differential Revision: https://phabricator.services.mozilla.com/D129411
Removed "width" feature from the popup condition, and removed related parameters
(aWidthSpecified, and aSizeSpec) from functions.
Also added "popup" feature that explicitly specify whether to request popup or
not.
This is only for content context, and it behaves differently than existing
"popup" feature for chrome context that makes the window no-style.
Differential Revision: https://phabricator.services.mozilla.com/D129410
This simplifies the chromeFlag calculation for:
* chrome-priv case, by removing not-fully-chrome-priv case
* content case, by removing presenceFlag calculation
both by removing the special case for
nsGlobalWindowOuter::Print and nsDocShell::PerformRetargeting,
that has chrome caller but no chrome parent.
Code path for nsGlobalWindowOuter::Print and nsDocShell::PerformRetargeting
now uses the content case instead of the chrome-priv case, but the resulting
flag doesn't change (CHROME_ALL) for those 2 consumers.
Differential Revision: https://phabricator.services.mozilla.com/D129530
This makes sure to clear and set the value more consistently when replacing
documents within a WindowGlobal, and makes sure to include the relevant flag in
the initializer.
In addition, the place where the flag is set is moved ahead to happen before
the call to `Embed` so that the information is ready before the window is
created.
Differential Revision: https://phabricator.services.mozilla.com/D119815
