The CSSWG has recently resolved that layout containment
suppress baseline alignment, while size containment does not:
https://github.com/w3c/csswg-drafts/issues/2995
Spec text (https://drafts.csswg.org/css-contain/#containment-layout):
"7. For the purpose of the vertical-align property,
or any other property whose effects need to relate
the position of the containing element's baseline
to something other than its descendants,
the containing element is treated as having no baseline."
And a note in (https://drafts.csswg.org/css-contain/#containment-size):
"Note: size containment does not suppress baseline alignment.
See layout containment for that."
This patch does this change just switching IsContainSize()
by IsLayoutSize() in several places related to baseline alignment
in the source code.
With the patch several WPT tests start to pass. Apart from that,
some of the tests under vendor-imports are updated to follow
the new behavior.
--HG--
extra : amend_source : 05dc9a320afeb1d58981e2bd8bc47b435999f2f9
To avoid trimming pixels at the top / left.
This makes it closer to non-WR[1], and fixes both the checkboxes getting
cut off and the master password field.
[1]: non-WR at least at 124 scaling on a hiDPI display is still perfect, though I saw nin symmetric borders at other resolutions, so we might be able to improve here further.
Differential Revision: https://phabricator.services.mozilla.com/D7251
--HG--
extra : moz-landing-system : lando
The animation in this reftests runs on the compositor. In the mean time,
reftest harness waits for the state where there is no pending paint in the
initial phase (STATE_WAITING_TO_FIRE_INVALIDATE_EVENT, i.e. before sending
a MozReftestInvalidate event). So if the animation starts running on the
compositor before a MozReftestInvalidate event is received, it means that
the reftest harness has to wait for the 'no pending paint' state until the
animation finishes because the reftest harness keeps flushing styles in the
initial phase which means the animation causes a paint on every flush.
To avoid above situation, we start the animation in question after we get a
MozReftestInvalidate event.
Differential Revision: https://phabricator.services.mozilla.com/D7681
--HG--
extra : moz-landing-system : lando
This revert reftest changes in bug 1431255 Part VIII (c42039f3ffe7)
so that we could test UA Widget in these tests.
Depends on D5085
Differential Revision: https://phabricator.services.mozilla.com/D7543
--HG--
extra : moz-landing-system : lando
Judging from the description in comment 3 and the fact that this test started
failing shortly after bug 1308876 landed, it is highly likely that this test is
being hit by the same issue as bug 1428670.
This also makes sense given that this test is supposed to test the clamping of
the effective container width for font inflation by the actually visible area of
that frame - be that the viewport for a top level document as in bug 1428670, or
the width of an <iframe> as in this test.
Without the patches for bug 1428670, this test is still failing very frequently.
With those patches applied on the other hand, no more failures are encountered.
Differential Revision: https://phabricator.services.mozilla.com/D5580
--HG--
extra : moz-landing-system : lando
Before bug 1308876, child frames marked themselves as dirty during reflow if
their parent was dirty, too. After bug 1308876, the point where dirtiness is
being propagated to a frame's descendants has been shifted: Now, dirty parents
are responsible for marking all their children as dirty, too, when the parent
starts reflowing.
This means that if a frame wants to mark a whole subtree as dirty *during its
own* reflow, it's no longer sufficient to just mark the root of the subtree as
dirty and then rely on all further children marking themselves as dirty as well
when reflow reaches them.
The font inflation code is one such case. When the font inflation data on a font
inflation flow root has become dirty, or we're resizing the top-level frame
(which because of the effective container width clamping from bug 707855 can
affect the font inflation font size as well), we now need to explicitly mark all
affected children as dirty.
Differential Revision: https://phabricator.services.mozilla.com/D5577
--HG--
extra : moz-landing-system : lando
The failure mode this test is testing is the following:
Apart from the relevant preferences (which cannot change without reloading the
page, so they're not relevant in this case), the magnitude of font size
inflation for all content governed by a particular font inflation flow root
depends on the flow root's effective container width, which is calculated by
taking the smaller of the following two values:
- The font inflation flow root's calculated NCAIsize.
- The ISize of the PresContext's currently visible area.
Minimum font size for font inflation then scales linearly with the effective
container width.
While for a plain document without frames, the visible area normally
corresponds to the viewport size, the MobileViewportManager will only calculate
the viewport after the "load" event or the first paint, whichever is sooner.
This means that the initial reflow will proceed using the current window
dimensions (on mobile this is corresponding to the display size) for the
currently visible area, which in portrait mode typically means around
300 - 500 px width.
After the MVM has done its viewport calculations, we'll reflow again using the
new viewport size as our visible area. For non-mobile friendly pages where font
inflation is relevant, the standard viewport width is 980 px.
If a font inflation flow root is wider than the initial window size, this means
that its effective container width is governed by the visible area and will
therefore increase during the second reflow, as will correspondingly font
inflation's minimum font size.
While the font inflation code detects changes in a font inflation flow root's
NCAISize, respectively ISize resizes of the top-level (Viewport)Frame, after bug
1308876 it no longer correctly marks all descendants of the affected flow root
as dirty. If the text is contained inside an element with a fixed width, which
has therefore been unaffected by the viewport width change, this means that
we'll skip reflow for that text entirely, so the text gets rendered at the new,
increased font size, but continues using the old layout laid out assuming the
smaller initial font size.
I didn't manage to force the visible area to be larger than the initial window
size of 800 px using meta viewport tags, so I'm adjusting browser.viewport.
desktopWidth for this test instead. This also more closely mimics the real-life
failure case described above, where the viewport width gets set to a value
larger than the initial window size through the special desktop page viewport
width handling.
Differential Revision: https://phabricator.services.mozilla.com/D5579
--HG--
extra : moz-landing-system : lando
Judging from the description in comment 3 and the fact that this test started
failing shortly after bug 1308876 landed, it is highly likely that this test is
being hit by the same issue as bug 1428670.
This also makes sense given that this test is supposed to test the clamping of
the effective container width for font inflation by the actually visible area of
that frame - be that the viewport for a top level document as in bug 1428670, or
the width of an <iframe> as in this test.
Without the patches for bug 1428670, this test is still failing very frequently.
With those patches applied on the other hand, no more failures are encountered.
Differential Revision: https://phabricator.services.mozilla.com/D5580
--HG--
extra : moz-landing-system : lando
Before bug 1308876, child frames marked themselves as dirty during reflow if
their parent was dirty, too. After bug 1308876, the point where dirtiness is
being propagated to a frame's descendants has been shifted: Now, dirty parents
are responsible for marking all their children as dirty, too, when the parent
starts reflowing.
This means that if a frame wants to mark a whole subtree as dirty *during its
own* reflow, it's no longer sufficient to just mark the root of the subtree as
dirty and then rely on all further children marking themselves as dirty as well
when reflow reaches them.
The font inflation code is one such case. When the font inflation data on a font
inflation flow root has become dirty, or we're resizing the top-level frame
(which because of the effective container width clamping from bug 707855 can
affect the font inflation font size as well), we now need to explicitly mark all
affected children as dirty.
Differential Revision: https://phabricator.services.mozilla.com/D5577
--HG--
extra : moz-landing-system : lando
The failure mode this test is testing is the following:
Apart from the relevant preferences (which cannot change without reloading the
page, so they're not relevant in this case), the magnitude of font size
inflation for all content governed by a particular font inflation flow root
depends on the flow root's effective container width, which is calculated by
taking the smaller of the following two values:
- The font inflation flow root's calculated NCAIsize.
- The ISize of the PresContext's currently visible area.
Minimum font size for font inflation then scales linearly with the effective
container width.
While for a plain document without frames, the visible area normally
corresponds to the viewport size, the MobileViewportManager will only calculate
the viewport after the "load" event or the first paint, whichever is sooner.
This means that the initial reflow will proceed using the current window
dimensions (on mobile this is corresponding to the display size) for the
currently visible area, which in portrait mode typically means around
300 - 500 px width.
After the MVM has done its viewport calculations, we'll reflow again using the
new viewport size as our visible area. For non-mobile friendly pages where font
inflation is relevant, the standard viewport width is 980 px.
If a font inflation flow root is wider than the initial window size, this means
that its effective container width is governed by the visible area and will
therefore increase during the second reflow, as will correspondingly font
inflation's minimum font size.
While the font inflation code detects changes in a font inflation flow root's
NCAISize, respectively ISize resizes of the top-level (Viewport)Frame, after bug
1308876 it no longer correctly marks all descendants of the affected flow root
as dirty. If the text is contained inside an element with a fixed width, which
has therefore been unaffected by the viewport width change, this means that
we'll skip reflow for that text entirely, so the text gets rendered at the new,
increased font size, but continues using the old layout laid out assuming the
smaller initial font size.
I didn't manage to force the visible area to be larger than the initial window
size of 800 px using meta viewport tags, so I'm adjusting browser.viewport.
desktopWidth for this test instead. This also more closely mimics the real-life
failure case described above, where the viewport width gets set to a value
larger than the initial window size through the special desktop page viewport
width handling.
Differential Revision: https://phabricator.services.mozilla.com/D5579
--HG--
extra : moz-landing-system : lando
This test now passes with WebRender enabled, but it's still fuzzy with WebRender
disabled, so just enable it when WebRender is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D7157
--HG--
extra : moz-landing-system : lando
Mostly straight-forward, the bordercol.css changes are just color renames, but
that file had bogus newlines and such so it looks much bigger.
Differential Revision: https://phabricator.services.mozilla.com/D6604
See the discussion in https://github.com/servo/webrender/issues/1280. I think we
should do this sooner rather than later.
Need to update a couple reftests to hardcode the new colors, waiting on try for
that but should be trivial.
This makes a few more tests pass which are just marked as failure in bug 1487407,
because I implementing the border-collapsing reusing a bunch of Gecko code,
including the table 3d border stuff.
Differential Revision: https://phabricator.services.mozilla.com/D6565
The previous border-collapse beveling implementation assumed that there would
only be one beveled border per side in the whole table, which is... not true at all.
So a bunch of borders ended up clobbering other values in mBevelBorders and
never getting painted.
I'm actually somewhat scarily surprised that only this reftest seems to fail
without this patch...
Here we reuse most of the existing one-off beveling / border rendering support
in nsCSSRendering, and convert the Gecko bevels into a WebRender display list
using rects and borders. This is only remotely possible thanks to Gecko not
supporting dotted / dashed beveled borders :)
This would slightly easier and presumably also more efficient with a triangle
display item in WR instead of (ab)using the border display item to render the
bevel, but this is probably relatively edge-casey so maybe not worth it... In
any case I've left a TODO comment there, that can be a nice followup if we deem
it worth it.
Anyway, I'm _so_ sorry for the border trick, I was this (||) close to go and
rewrite our border collapsing code, but after a few tries I realized it'd take
me a whole lot of time (instead of the day that this has taken me).
Differential Revision: https://phabricator.services.mozilla.com/D4793
This code is no longer necessary since we now invalidate using Display List
Based Invalidation instead of using recursive calls up the frame tree.
The tests that are marked as failing have only been passing due to a bug in the
code that's being removed from nsSVGIntegrationUtils.cpp which coincidentally
hides the fact that we are actually invalidating in those tests given their
particular structure (which the tests are supposed to be checking we're not
doing).
Differential Revision: https://phabricator.services.mozilla.com/D6850
--HG--
extra : rebase_source : cb95359d694dafeca915a22b3c48f580a69679ef
extra : amend_source : 7074f5837170ce0a9243811291782f689666e122
