When the session storage prefs are enabled, GeckoSession updateSessionState will provide the bundle of information, including zoom, scroll, and form data, to the delegate. Currently works for Fission and on Fenix.
Differential Revision: https://phabricator.services.mozilla.com/D148215
Preparation for part 3).
The return type of `GetUserGestureStart` is a class, the return type of
`LastUserGestureTimeStamp` a `double`. Hence using the former is safer.
Differential Revision: https://phabricator.services.mozilla.com/D148758
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
In bug 1773342, I made OS text zoom behave like layout full zoom on all
pages (including the main browser page).
This means that getting CSS pixels from the browser page and turning
them to LayoutDevice pixels by multiplying by GetDefaultScale() isn't
right.
However, the caller already has the right device pixel values, so just
use them.
Differential Revision: https://phabricator.services.mozilla.com/D149026
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 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
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
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
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 currently effectively just a helper around the existing
properties. Theoretically we could streamline things here in the future
by managing primary content entirely based on BrowsingContext rather
than docshell, but there's enough complexity there right now with other
properties like updating properties on content shells as they're
attached, that it's probably not worth trying to unify right now,
especially considering the low number of consumers.
Differential Revision: https://phabricator.services.mozilla.com/D146495
This patch won't actually build, because a few bits of code are used
for both nsIFactory::createInstance and static components, and static
components are not fixed until the next patch.
The first place is nsLoadGroupConstructor, which uses an nsIFactory
macro to create a static component constructor. (This could be worked
around by expanding the macro to the state before this patch.)
The other issue is that nsAppShellConstructor is used in an nsIFactory
on OSX, but as a static component on all other platforms. This could
be worked around by wrapping nsAppShellConstructor in an adaptor that
passes in the extra null argument to nsAppShellConstructor.
Differential Revision: https://phabricator.services.mozilla.com/D146456
Joel Maher
Marian-Vasile Laza
Cathy Lu
Kris Maglione
Mark Banner
Mirko Brodesser
Norisz Fay
Peter Van der Beken
Andreas Farre
Emilio Cobos Álvarez
Bogdan Szekely
Benjamin VanderSloot
Nika Layzell
Molnar Sandor
Tooru Fujisawa
Paul Zuehlcke
Cristian Tuns
Andrew McCreight
Sebastian Hengst