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
The only functions that remain are used as helper functions in the various variants of the Storage Access API.
To make this clearer, I have renamed this class and file that contains it.
Differential Revision: https://phabricator.services.mozilla.com/D148286
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
mStorageAccessPermissionGranted was initialized to ShouldAllowAccessFor(...).
This had logic that has nothing to do with this the permission being granted.
A few bugs with my helpers were covered up by this default value, so I fixed the helpers in the same patch here.
This also required adding a new helper to the RejectForeignAllowList and exposing it to the Document.cpp file.
I'm not enthused about making that available, but we don't have a good component boundary for now, so I don't hate it.
Ideally the implementation of the rSA and hSA funcitons (and the like) would be in our component, but that is outside of this change's scope.
Differential Revision: https://phabricator.services.mozilla.com/D147867
The only functions that remain are used as helper functions in the various variants of the Storage Access API.
To make this clearer, I have renamed this class and file that contains it.
Differential Revision: https://phabricator.services.mozilla.com/D148286
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
mStorageAccessPermissionGranted was initialized to ShouldAllowAccessFor(...).
This had logic that has nothing to do with this the permission being granted.
A few bugs with my helpers were covered up by this default value, so I fixed the helpers in the same patch here.
This also required adding a new helper to the RejectForeignAllowList and exposing it to the Document.cpp file.
I'm not enthused about making that available, but we don't have a good component boundary for now, so I don't hate it.
Ideally the implementation of the rSA and hSA funcitons (and the like) would be in our component, but that is outside of this change's scope.
Differential Revision: https://phabricator.services.mozilla.com/D147867
The only functions that remain are used as helper functions in the various variants of the Storage Access API.
To make this clearer, I have renamed this class and file that contains it.
Differential Revision: https://phabricator.services.mozilla.com/D148286
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
mStorageAccessPermissionGranted was initialized to ShouldAllowAccessFor(...).
This had logic that has nothing to do with this the permission being granted.
A few bugs with my helpers were covered up by this default value, so I fixed the helpers in the same patch here.
This also required adding a new helper to the RejectForeignAllowList and exposing it to the Document.cpp file.
I'm not enthused about making that available, but we don't have a good component boundary for now, so I don't hate it.
Ideally the implementation of the rSA and hSA funcitons (and the like) would be in our component, but that is outside of this change's scope.
Differential Revision: https://phabricator.services.mozilla.com/D147867
Add a dom/base/rust crate called just "dom" where we can share these.
Most of the changes are automatic:
s/mozilla::EventStates/mozilla::dom::ElementState/
s/EventStates/ElementState/
s/NS_EVENT_STATE_/ElementState::/
s/NS_DOCUMENT_STATE_/DocumentState::/
And so on. This requires a new cbindgen version to avoid ugly casts for
large shifts.
Differential Revision: https://phabricator.services.mozilla.com/D148537
Given how nsIPrintSettings is passed around, stored and copied all over the
place, it's very hard to reason about where and when a RemotePrintJobChild is
needed or valid. This patch avoids all that by explicitly passing a
RemotePrintJobChild when it's needed.
Another reason to make this change is because RemotePrintJobChild really does
not belong on nsIPrintSettings. That interface is supposed to represent a
collection of settings for laying out the document that is to be printed.
Differential Revision: https://phabricator.services.mozilla.com/D146380
This basically undoes bug 1246346. The current behavior is pretty bizarre,
the screenX origin / position doesn't match the mouse event coordinates,
because on windows we return device pixels rather than CSS pixels for the
window coordinates.
This makes behavior consistent with how other browsers report these coordinates
at least on Windows in non-mixed DPI mode, and I think is fine.
In mixed DPI mode, there might indeed be overlapping coordinates, but again I
think that's fine, because the CSS coordinate space of the different monitors
is different. You need to multiply by the devicePixelRatio if you want
coordinates not to overlap.
Depends on D138039
Differential Revision: https://phabricator.services.mozilla.com/D138130
This basically undoes bug 1246346. The current behavior is pretty bizarre,
the screenX origin / position doesn't match the mouse event coordinates,
because on windows we return device pixels rather than CSS pixels for the
window coordinates.
This makes behavior consistent with how other browsers report these coordinates
at least on Windows in non-mixed DPI mode, and I think is fine.
In mixed DPI mode, there might indeed be overlapping coordinates, but again I
think that's fine, because the CSS coordinate space of the different monitors
is different. You need to multiply by the devicePixelRatio if you want
coordinates not to overlap.
Depends on D138039
Differential Revision: https://phabricator.services.mozilla.com/D138130
Make the ScreenOrientation part of the screen struct, as it should. Stop
using HAL to propagate just screen orientation updates, use the more
general screen manager.
Instead of HAL observers, add a simple observer service notification,
and clean a bunch of the code.
This will simplify bug 1754802 a bit, and is generally simpler.
Shouldn't change behavior. I've tested the events and some common
orientation locking use cases like Youtube, and they behave the same.
Differential Revision: https://phabricator.services.mozilla.com/D138477
It only pokes at the document's pres context, there's no need to
roundtrip through the outer window. No behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D138019
Printing was failing for silent window.print() printing because we need a
RemotePrintJobChild. The content process side of the print now asks the parent
process to send a valid nsIPrintSettings object and a RemotePrintJobChild
before it starts printing.
Printing was also failing for silent print-to-file printing in the case that
the user omits to set the `printer.print_to_filename` pref. That was because
we weren't setting a fallback value for nsIPrintSettings.toFileName.
Differential Revision: https://phabricator.services.mozilla.com/D134799
Printing was failing for silent window.print() printing because we need a
RemotePrintJobChild. The content process side of the print now asks the parent
process to send a valid nsIPrintSettings object and a RemotePrintJobChild
before it starts printing.
Printing was also failing for silent print-to-file printing in the case that
the user omits to set the `printer.print_to_filename` pref. That was because
we weren't setting a fallback value for nsIPrintSettings.toFileName.
Differential Revision: https://phabricator.services.mozilla.com/D134799
