This makes sure that the URLExtraData contains the right referrer info,
and thus that mChromeRulesEnabled is correct.
Remove some useless includes while at it.
Differential Revision: https://phabricator.services.mozilla.com/D193047
The top layer fixed list CB and the regular fixed list CB are always the
same (the viewport frame). We're currently using two different
AbsoluteFrameList for these, but that's wrong. Make sure to use the same
AbsoluteFrameList. This makes sure that placeholders for the fixed list
are properly ordered.
Revert bug 1799036 (for now at least), since this also fixes that issue
in a better, less breaking way.
While at it, also insert the top layer abspos list after the
non-top-layer one. This is needed so that a non-top-layer abspos element
and a top layer abspos element are laid out in the right order.
We don't need to share a list for those tho, because all top-layer
abspos items are also abspos containers themselves, so a non-top-layer
descendant of a top layer item can't escape the top layer chain. This
fixes a couple non-fatal asserts.
Differential Revision: https://phabricator.services.mozilla.com/D192908
Disabling `test_minimum_select_one_character_textarea` and
`test_minimum_select_one_character_textarea_disabled` is OK since we still test
minimum select one character on other types elements.
`test_carets_not_show_after_key_scroll_down_and_up()` is not robust since the
selection highlight often disappears after page down and page up. I feel it is
OK to disable it since bug 1833081 (where test is added) is an edge case that
requires some user interaction, and AccessibleCaret code does not change much
these days.
Differential Revision: https://phabricator.services.mozilla.com/D193155
We introduce a different rust type for `<line-name-list>` for subgrid,
which keeps `repeat()` information at computed time. At this moment,
we don't expand `repeat()`.
Also, we precompute the possible expanded list length, so we can expand
`repeat(auto-fill)` in a single iteration in nsGridContainerFrame. If we
don't have this precompution, we have to go through `<line-name-list>`
first to know how many items we have after expanding `repeat(Integer)`.
Differential Revision: https://phabricator.services.mozilla.com/D192876
This requires moving some code around to PreferenceSheet, but that makes
stuff actually a bit simpler.
Depends on D192574
Differential Revision: https://phabricator.services.mozilla.com/D192575
We might want to do this more generally at the PreferencesSheet level
all the times we're forcing colors, but this should be uncontroversial
and fix the default behavior.
Differential Revision: https://phabricator.services.mozilla.com/D192574
This matches the behavior of other browsers, and avoids having to keep
alive the link element and thus associated document etc for too long.
Differential Revision: https://phabricator.services.mozilla.com/D192834
This fixes rendering of background-image when CSS zoom is in effect.
Note that we want to scale the resolution by the _inverse_ of the
zoom, since having a higher image resolution means that the CSS
size gets shrunk and viceversa.
Differential Revision: https://phabricator.services.mozilla.com/D192130
Instead, use forced-color-adjust: none to disable HCM forced colors in
DevTools, for now. It's a more straight-forward way of doing it.
Differential Revision: https://phabricator.services.mozilla.com/D192669
The spec explicitly requires that we "must ensure that tab stops continue to line up"
when applying justification to content with preserved white-space that includes tabs.
So when we're computing justification spacing adjustments, we must not apply adjustments
if there is a preserved tab later on the same line; only text after the last tab is to
be justified.
Differential Revision: https://phabricator.services.mozilla.com/D191996
When looking pernos debug session, since `nsLayoutStatics` isn't destroyed,
`nsLanguageAtomService` isn't destroyed. It seems to be some objects are
leaked according to stdout and stderr on debug build.
So we should destroy this service to avoid other debug assertion even if
`nsLayoutStatics` isn't destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D192607
Fixing this also resolves a couple of text-transform test failures, because what was
failing was not the text-transform itself, but rather the trailing-ideographic-space
treatment.
Differential Revision: https://phabricator.services.mozilla.com/D192396
This fixes gradient interpolation when CSS4 gradient color interpolation methods are enabled (pref is off by default), or if color management is set to ALL (pref is off by default).
Differential Revision: https://phabricator.services.mozilla.com/D190903
See comments in the bug for reasoning. macOS hasn't used subpixel AA for
quite a while.
Emulating this macOS AA on vibrant backgrounds was the only point of
this feature.
This allows to simplify the WebRender code quite a bit, too.
Differential Revision: https://phabricator.services.mozilla.com/D192311
This accidentally broke in 119 and nobody noticed on the whole nightly +
beta cycle (other than due to bug 1861669).
Given sidebars are not super-commonly used these days, this makes the
code a bit less fragile, and it still looks pretty good IMO. Also, since
we want to get rid of <xul:tree>s, this is one less thing to worry
about.
Depends on D192102
Differential Revision: https://phabricator.services.mozilla.com/D192103
When colors are converted to sRGB to render onto the display, make sure
that they are within sRGB gamut limits.
Gamut mapping is implemented according to:
https://drafts.csswg.org/css-color-4/#gamut-mapping
The color-mix-non-srgb-001 test is checking the expected result in
sRGB, which happens to be out of gamut limits, but because the test
is for color-mix and not gamut mapping, I changed the expected
results to the color space of the mix.
The svg reftest now has an increased fuzzy to allow for the final colors
to be gamut mapped. Gamut mapping is dependent of available hardware, so
we can't pin down exact colors for the result.
Differential Revision: https://phabricator.services.mozilla.com/D191083
When colors are converted to sRGB to render onto the display, make sure
that they are within sRGB gamut limits.
Gamut mapping is implemented according to:
https://drafts.csswg.org/css-color-4/#gamut-mapping
The color-mix-non-srgb-001 test is checking the expected result in
sRGB, which happens to be out of gamut limits, but because the test
is for color-mix and not gamut mapping, I changed the expected
results to the color space of the mix.
The svg reftest now has an increased fuzzy to allow for the final colors
to be gamut mapped. Gamut mapping is dependent of available hardware, so
we can't pin down exact colors for the result.
Differential Revision: https://phabricator.services.mozilla.com/D191083
Emilio Cobos Álvarez
Ting-Yu Lin
Norisz Fay
Boris Chiou
Stanca Serban
Tooru Fujisawa
Ashley Hale
Sandor Molnar
Gregory Pappas
Natalia Csoregi
Cristian Tuns
Jonathan Kew
Robert Longson
owlishDeveloper
David Shin
Cathie Chen
Makoto Kato
Sean Feng
Tiaan Louw
Narcis Beleuzu
Razvan Cojocaru