Converts font.size.systemFontScale to a static pref. Removes the function in nsLayoutUtils and does the float division directly in PresShell.
Differential Revision: https://phabricator.services.mozilla.com/D41824
Converts font.size.inflation.forceEnabled and font.size.inflation.disabledInMasterProcess to static prefs. Like previous revisions, I retained the member variables in PresShell and set them to the static prefs.
Differential Revision: https://phabricator.services.mozilla.com/D41664
Converts font.size.inflation.lineThreshold varcache pref to a static pref. Like previous revisions, this retains the member variable in PresShell.
Differential Revision: https://phabricator.services.mozilla.com/D41662
Converts font.size.inflation.minTwips, font.size.inflation.emPerLine, and font.size.inflation.mappingIntercept to static prefs and removes their associated functions from nsLayoutUtils. There are associated member variables in PresShell, but since documentation specified that these variables are set specifically to prevent changes to the cache from being read until page reload, I made the decision to leave these and set them to the static prefs.
Differential Revision: https://phabricator.services.mozilla.com/D41656
Creates the new 'font' category in StaticPrefList.yaml and adds font.size.inflation.maxRatio to the category. Removes the old static uint in nsLayoutUtils and the function that returns it.
Differential Revision: https://phabricator.services.mozilla.com/D41654
Converts layout.css.ruby.intercharacter.enabled to a static pref and removes the associated function nsLayoutUtils::IsInterCharacterRubyEnabled(). Also removes the macro INTERCHARACTER_RUBY_ENABLED_PREF_NAME, since it was only being used to add the varcache pref.
Differential Revision: https://phabricator.services.mozilla.com/D41653
Converts layout.animated-image-layers.enabled to a static pref and removes the nsLayoutUtils::AnimatedImageLayersEnabled() function, replacing it with the static pref.
Differential Revision: https://phabricator.services.mozilla.com/D41652
Converts layers.offmainthreadcomposition.async-animations and layers.offmainthreadcomposition.log-animations to their respective static prefs. Since all IsAnimationLoggingEnabled() did was create a pref and return the variable sShouldLog, this function is removed and replaced with the static pref.
Differential Revision: https://phabricator.services.mozilla.com/D41651
When we use SVG layout, and transform-box is fill-box, the current
implementation makes the object not align with offset-path because there
may be an offset (SVG x and y values) between the anchor point and offset-path.
We have to tweak the anchor point to fix the alignment.
Differential Revision: https://phabricator.services.mozilla.com/D39419
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
This is what other browsers do, and it does make sense to me, it's useless to
try to scroll a frame with no scroll range in a given direction.
I think all callers of this function should be treated like this, so this is
more like a RFC / feedback request than a patch per se.
The wheel handling code already checks scroll range, so there's no difference of
behavior in that case, if I'm reading the code right.
There are a few other functions that check the result of
GetPerceivedScrollingDirections(), but I think if we change this we should
change this consistently.
I also think that if we do this we should rename the method to something like
GetAvailableScrollingDirections() or such.
Anyhow, wdyt? I should also add a test for this if we go with this.
Differential Revision: https://phabricator.services.mozilla.com/D38991
This is what other browsers do, and it does make sense to me, it's useless to
try to scroll a frame with no scroll range in a given direction.
I think all callers of this function should be treated like this, so this is
more like a RFC / feedback request than a patch per se.
The wheel handling code already checks scroll range, so there's no difference of
behavior in that case, if I'm reading the code right.
There are a few other functions that check the result of
GetPerceivedScrollingDirections(), but I think if we change this we should
change this consistently.
I also think that if we do this we should rename the method to something like
GetAvailableScrollingDirections() or such.
Anyhow, wdyt? I should also add a test for this if we go with this.
Differential Revision: https://phabricator.services.mozilla.com/D38991
This is what other browsers do, and it does make sense to me, it's useless to
try to scroll a frame with no scroll range in a given direction.
I think all callers of this function should be treated like this, so this is
more like a RFC / feedback request than a patch per se.
The wheel handling code already checks scroll range, so there's no difference of
behavior in that case, if I'm reading the code right.
There are a few other functions that check the result of
GetPerceivedScrollingDirections(), but I think if we change this we should
change this consistently.
I also think that if we do this we should rename the method to something like
GetAvailableScrollingDirections() or such.
Anyhow, wdyt? I should also add a test for this if we go with this.
Differential Revision: https://phabricator.services.mozilla.com/D38991
Currently it's completely unclear at use sites that the getters for `once`
static prefs return the pref value from startup, rather than the current pref
value. (Bugs have been caused by this.) This commit improves things by changing
the getter name to make it clear that the pref value obtained is from startup.
This required changing things within libpref so it distinguishes between the
"base id" (`foo_bar`) and the "full id" (`foo_bar` or
`foo_bar_DoNotUseDirectly` or `foo_bar_AtStartup` or
`foo_bar_AtStartup_DoNotUseDirectly`; the name used depends on the `mirror` and
`do_not_use_directly` values in the YAML definition.) The "full id" is used in
most places, while the "base id" is used for the `GetPrefName_*` and
`GetPrefDefault_*` functions.
(This is a nice demonstration of the benefits of the YAML file, BTW. Making
this change with the old code would have involved adding an entry to every
single pref in StaticPrefList.h.)
The patch also rejigs the comment at the top of StaticPrefList.yaml, to clarify
some things.
Differential Revision: https://phabricator.services.mozilla.com/D38604
For avoiding confusion between API of `nsRange` and `StaticRange`, I'd like to
rename `nsRange::CreateRange()` to `nsRange::Create()` because
`StaticRange::CreateStaticRange()` is too long name and
`StaticRange::CreateRange()` sounds odd. This patch renames it and changes
related methods to template methods to avoid runtime cost of temporary
`RawRangeBoundary` instance creation.
Differential Revision: https://phabricator.services.mozilla.com/D35141
App units of a remote browser element in the parent process are
different from app units inside the remote content in the child
process. We should apply the appropriate conversions by exposing
the relevant data as LayoutDevicePixel.
Differential Revision: https://phabricator.services.mozilla.com/D35334
Even if we don't have a root displayport, the composition size is still used for
displayport margins calculations. For extremely tall iframes, this will create
a displayport that is way to big. We should instead report a composition size that
is equivalent to the visible rect for OOP-iframes.
Differential Revision: https://phabricator.services.mozilla.com/D34528
Now they both work in opt builds, and they both work with advanced layers.
For consistency, layers.dump-client-layers is also modified to work in
opt builds.
Differential Revision: https://phabricator.services.mozilla.com/D34413
