This patch is a bit bigger than I'd like, but it's mostly moving code
around to centralize the color/color-scheme decisions we make when
forcing colors.
In practice, the only behavior change should be that when "use system
colors" is false and we force colors, we force a color-scheme that
matches the user-chosen background (via the LookAndFeel::IsDarkColor
check).
That should make sure that text from system colors is light and matches
the user expectations.
Before this patch, we used to force the color-scheme to light, but that
was just so that we ended up looking at mLightColors. Instead, we
achieve that via a separate bit (mForcedLightColorSet, naming up for
debate, not a fan), so that we can use the right system colors
otherwise.
Another alternative I considered is making all non-link system colors
return mDefaultBackground / mDefault depending on whether they are
background / foreground colors. That seemed a lot more work and
potentially a regression in various ways. I think this should be
strictly an improvement instead.
Differential Revision: https://phabricator.services.mozilla.com/D142423
Two noteworthy details that may seem random otherwise:
* Moving values around in nsStyleDisplay is needed so that the struct
remains under the size limit that we have to avoid jumping allocator
buckets.
* All the test expectation churn is because tests depend on
`container-type: size` parsing to run, and now they run. Tests for
the relevant bits I implemented are passing, with the only exception
of some `container-name-computed.html` failures which are
https://github.com/w3c/csswg-drafts/issues/7181. Safari agrees with
us there.
Other notes when looking at the spec and seeing how it matches the
implementation:
* `container` syntax doesn't match spec, but matches tests and sanity:
https://github.com/w3c/csswg-drafts/issues/7180
* `container-type` syntax doesn't _quite_ match spec, but matches tests
and I think it's a spec bug since the definition for the missing
keyword is gone:
https://github.com/w3c/csswg-drafts/issues/7179
Differential Revision: https://phabricator.services.mozilla.com/D142419
This patch is a bit bigger than I'd like, but it's mostly moving code
around to centralize the color/color-scheme decisions we make when
forcing colors.
In practice, the only behavior change should be that when "use system
colors" is false and we force colors, we force a color-scheme that
matches the user-chosen background (via the LookAndFeel::IsDarkColor
check).
That should make sure that text from system colors is light and matches
the user expectations.
Before this patch, we used to force the color-scheme to light, but that
was just so that we ended up looking at mLightColors. Instead, we
achieve that via a separate bit (mForcedLightColorSet, naming up for
debate, not a fan), so that we can use the right system colors
otherwise.
Another alternative I considered is making all non-link system colors
return mDefaultBackground / mDefault depending on whether they are
background / foreground colors. That seemed a lot more work and
potentially a regression in various ways. I think this should be
strictly an improvement instead.
Differential Revision: https://phabricator.services.mozilla.com/D142423
Make Link and SVGAElement agree on XLink handling, and make it more
explicit that SVGAElement needs to be a bit more special for SMIL.
Remove dead MathML XLink code.
Differential Revision: https://phabricator.services.mozilla.com/D142546
The trickiest bits are the PrintTargetCG ones, the rest is just plumbing
and cleanups and tests, but let me know if you want those to be split
out, can do.
The GTK change to nsPrintSettingsGTK::GetResolution is a no-op (we only
read resolution on windows), but I did that because we assume that it
doesn't fail and GTK returns a sane default anyways.
Differential Revision: https://phabricator.services.mozilla.com/D142199
This is mostly edge-casey, but see bug 1757156 for an example where it's
causing some issues (granted, they could use `href="#"` or something
instead of an empty href).
It feels weird if a link looks like a link (because the CSS definition
of a link matches, which is "has an href") but then mostly doesn't
behave as a link.
We can't navigate anywhere if we don't have a valid URI but maybe JS
handles the relevant events as in bug 1757156.
Use the CSS definition (has href) since that's interoperable across
browsers. This should also make some stuff much faster (since checking
'is link' is now just a bit check instead of a virtual call).
(Awaiting try results, if no tests need adjustments then I need to write
some)
Differential Revision: https://phabricator.services.mozilla.com/D142107
To run the script to generate test cases:
python layout/reftests/css-page/generate-page-name-two-page-test.py
This should work with Python 2 or Python 3, and from any working directory.
Differential Revision: https://phabricator.services.mozilla.com/D141671
The trickiest bits are the PrintTargetCG ones, the rest is just plumbing
and cleanups and tests, but let me know if you want those to be split
out, can do.
The GTK change to nsPrintSettingsGTK::GetResolution is a no-op (we only
read resolution on windows), but I did that because we assume that it
doesn't fail and GTK returns a sane default anyways.
Differential Revision: https://phabricator.services.mozilla.com/D142199
Instead of reasoning about whether items should be active with a yes/no granularity, we consider whether it could/should be and have some logic to weight that against the risk of causing extra layerization when making containers active.
For example a small image *could* be made active, but we might not make it so if it causes extra layerization in cases where larger images would have been made active.
Differential Revision: https://phabricator.services.mozilla.com/D142213
In particular, gather telemetry to evaluate the impact of unlabeled UTF-8
and how detector-triggered reloads would change if ASCII-only at initial
guess was treated as UTF-8.
Differential Revision: https://phabricator.services.mozilla.com/D140818
With this change, `has-scroll-linked-effect` flag won't persist so that we can
avoid choosing either the one-frame delayed scroll offset or the latest scroll
offset in cases where there's no longer effective scroll linked effect. It will
mitigate scroll jittering.
Differential Revision: https://phabricator.services.mozilla.com/D141457
In subsequent commits, our ScrollLinkedEffectDetector is changed to;
1. Don't consider having scroll linked effect if changing properties values
are not going to be changed, we don't currently check whether the value is
changed or not.
2. Consider having scroll linked effect per refresh driver's most recent time
stamp
With these changes, a reftest, disable-apz-for-sle-pages.html will no longer
work as it is. Fortunately our new ScrollLinkedEffectDetector is still per
document basis. So to make it work as expected, we need to;
1. Add a new invisible scrollable element
2. Keep listening scroll events for the element
3. Invoke scrolling the element
4. Change one of scroll linked effect CSS properties in the listener
Then our new ScrollLinkedListener still considers the document has a scroll
linked effect all the time.
This revised reftest fails with apz.disable_for_scroll_linked_effects=false,
which means it works as expected.
Differential Revision: https://phabricator.services.mozilla.com/D142010
I forgot we were doing this "revert-or-initial" shenanigans (which is needed
for stuff like link colors to be honored), so we need to early-return.
Use a more explicit test rather than a reftest for this.
Differential Revision: https://phabricator.services.mozilla.com/D142063
They are just convenience for :root[lwthemetextcolor="light"] (and dark,
respectively), but they generally shouldn't be used for dark mode
theming. In the past it was the only way to do it but now we have
prefers-color-scheme.
While at it, change lwthemetextcolor to be "lwtheme-brighttext" for
consistency with similar code we have for popups etc, and move it to
_setDarkModeAttributes.
While at it, remove layout.css.moz-lwtheme.content.enabled (which is
false always, we unshipped these from content successfully).
Differential Revision: https://phabricator.services.mozilla.com/D141593
Use mMoveToRectPopupRect popup constrains in nsMenuPopupFrame::SetPopupPosition only and make it pernament.
In such setup works as screen size constraints.
Don't call SetPopupPosition from move-to-rect callback and let layout code to handle that.
Remove MoveToRectPopupRectClear() as it's not needed, we keep mMoveToRectPopupRect
in nsMenuPopupFrame as well as we keep screen sizes there.
Differential Revision: https://phabricator.services.mozilla.com/D141602
Use mMoveToRectPopupRect popup constrains in nsMenuPopupFrame::SetPopupPosition only and make it pernament.
In such setup works as screen size constraints.
Don't call SetPopupPosition from move-to-rect callback and let layout code to handle that.
Remove MoveToRectPopupRectClear() as it's not needed, we keep mMoveToRectPopupRect
in nsMenuPopupFrame as well as we keep screen sizes there.
Differential Revision: https://phabricator.services.mozilla.com/D141602
In addition to adding test support for dynamic-range and video-dynamic-range,
this expands tests of pixelDepth and colorDepth to allow 30 as an acceptable
value.
Differential Revision: https://phabricator.services.mozilla.com/D141307
The flags stylo cares about reading and writing potentially at the same
time are disjoint, so there's no need for any strong memory ordering.
Differential Revision: https://phabricator.services.mozilla.com/D141829
The flags stylo cares about reading and writing potentially at the same
time are disjoint, so there's no need for any strong memory ordering.
Differential Revision: https://phabricator.services.mozilla.com/D141829
Emilio Cobos Álvarez
Iulian Moraru
Cristian Tuns
Ryan VanderMeulen
Mark Banner
Andreea Pavel
David Shin
Emily McDonough
Nicolas Silva
Henri Sivonen
stransky
Hiroyuki Ikezoe
Timothy Nikkel
Norisz Fay
Olli Pettay
Brad Werth
Miko Mynttinen
Butkovits Atila