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 crash reporter client should behave in the same way across all platforms.
Crucially the first time it's opened it needs to have the "submit this report"
and "include the URL" checkboxes checked by default. It should also preserve
the value of those checkboxes across runs. This patch does the following to
achieve this goal
* Set the submit and include URL checkboxes by default if the crash reporter
preferences INI file is not available or cannot be read on Linux
* Remove the unused preference keys from the Windows implementation
* Preserve the value of the include URL checkbox across runs on macOS
The names of the options used for both preferences are inconsistent across the
different platforms and I'll harmonize them in a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D148959
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
Experimenter now performs the following additional validations:
- FML `int` field types are mapped to `integer` and not `number`;
- `additionalProperties` is now false; and
- All fields are marked as `required`.
We now perform the same validation.
Differential Revision: https://phabricator.services.mozilla.com/D149146
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
Sean Burke
Luca Greco
Tooru Fujisawa
Cristian Tuns
Jeff Muizelaar
Sergey Galich
Emilio Cobos Álvarez
Neil Deakin
Bogdan Szekely
Gabriele Svelto
Norisz Fay
Andreas Farre
Janvi Bajoria
Marian-Vasile Laza
Paul Zuehlcke
Barret Rennie
Katherine Patenio
Calixte
Gijs Kruitbosch
mcheang
Magnus Melin
Dennis Jackson
Michael Kohler
serge-sans-paille