Add an implementation of CSS `contain: style`. This introduces two new
data structures, the ContainStyleScope and ContainStyleScopeManager.
ContainStyleScope manages one `contain: style` "world" which has its own
counter and quote lists. The contents of these lists depend on their
parent scopes, but are not affected by their children.
ContainStyleScopeManager manages a tree of scopes starting at a root
scope which is outside of any `contain: style` element.
Scopes are stored in a hash table that is keyed off of the nsIContent
which establishes the `contain: style` scope. When modifying quote or
content lists, the ContainStyleScopeManager is responsible for finding
the appropriate `contain: style` scope to modify.
Perhaps the most complex part of this is that counters and quotes have
read access to the state of counters and quotes that are in ancestor
`contain: style` scopes. In the case of counters, USE nodes that are at
the beginning of counter lists might have a counter scope that starts in
an ancestor `contain: style` scope. When nsCounterNode::SetScope() is
called, the code may look upward in the `contain: style` scope tree to
find the start of the counter scope. In the case of quotes, the first
node in the quote list must look for the state of quotes in ancestor
`contain: style` scopes.
Differential Revision: https://phabricator.services.mozilla.com/D149508
This matches UWP apps like Settings on Windows 11, and what we do for other
desktop platforms too.
The system colors match the ones from Win32 otherwise, but using UIUtils we can
access the accent color pallete from UWP apps.
Add a pref just to be safe in any case.
Differential Revision: https://phabricator.services.mozilla.com/D149905
It'd be weird otherwise, as in platforms where use-theme-accent is false
(Windows), form controls would be blue (the default accent color) but
the AccentColor color would be the system accent color still.
Differential Revision: https://phabricator.services.mozilla.com/D149877
The link was missing an event listener, that we add in this patch.
A test case is added to make sure the link does work.
Differential Revision: https://phabricator.services.mozilla.com/D149953
Automatic update from web-platform-tests
Properly handle floats leaving an inline formatting context.
Revert all code changes from CL:3613771 and replace with this. The bad
CL just did SetIsInLayoutNGInlineFormattingContext(false), which would
leave fragment items behind pointing to layout objects. When such a
layout object would later on be deleted, the fragment items wouldn't be
notified, since IsInLayoutNGInlineFormattingContext was false.
Notify the fragment items that layout object becoming in-flow
non-floated will be "moved", to properly clear the association. There
was already code for this when going out-of-flow, but we also need this
when becoming in-flow non-floated.
Bug: 1331189
Change-Id: I888d81495627952b75ec33a83edce165f6a3ad01
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3714111
Commit-Queue: Koji Ishii <kojii@chromium.org>
Reviewed-by: Koji Ishii <kojii@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1016000}
--
wpt-commits: d0cc6394218081bea51fc0352cd521fbf1fc1f47
wpt-pr: 34498
Automatic update from web-platform-tests
[TableFragmentation] Nested repeated table headers
If a table header was nested inside of another, we would end up
breaking forever. This happened because we would set if the header
ConstraintSpace IsRepeated() based on its parent's ConstraintSpace.
Because the parent's ConstraintSpace had IsRepeated() set to true in
this case, the inner header would never terminate repeating itself,
even when RelayoutAsLastTableBox() was called.
To fix this, don't rely on the parent ConstraintSpace to set this.
Also consider what repeat_mode is set to for the current header.
Once this was fixed, we also ran into an issue when cloning these
nested headers (because they were already repeated). To get this
working, NGFragmentRepeater::GetClonableLayoutResult() needed to be
updated to consider if the repeated break token was the result of
a different fragmentation context than the current header being
cloned.
Bug: 1336683
Change-Id: I13e7af8ce91144e4c3c22eca6dc2a45a0f1a9b80
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3710528
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Commit-Queue: Alison Maher <almaher@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1015548}
--
wpt-commits: 73380548ab5f7f6fe47ece278005b500e45f8c4d
wpt-pr: 34475
Automatic update from web-platform-tests
Reland "Implementing grid-template-columns/rows interpolation support"
This is a reland of commit b266b143ec994a7a97349cd2d54e18f52bf9534f
It was reverted due to failures in MSAN builds: https://crrev.com/c/3704863. The variable |progress_| in InterpolableGridTrackList was uninitialized, resulting in crashes in Add(...) and RawClone().
Original change's description:
> Implementing grid-template-columns/rows interpolation support
>
> This CL adds new interpolation types to represent grid track lists and
> their track sizes, allowing interpolation of grid-template-columns and
> grid-template-rows. A more detailed explanation of the design can be
> found in this doc: https://docs.google.com/document/d/1byO4UU-gFRNrqAEuhL3AKgUuFprz4ZQYNEeXSF9T6w0/edit?usp=sharing
>
> Bug: 759665
> Change-Id: Iecef825cd843c60bf6268cdbfc2f9180c884f853
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3403003
> Reviewed-by: Ethan Jimenez <ethavar@microsoft.com>
> Commit-Queue: Ana Sollano Kim <ansollan@microsoft.com>
> Reviewed-by: Robert Flack <flackr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1013983}
Bug: 759665
Change-Id: I71aba0c2be7e4cd56aa92521b9b0008ab25c0ed6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3705054
Commit-Queue: Ana Sollano Kim <ansollan@microsoft.com>
Reviewed-by: Robert Flack <flackr@chromium.org>
Reviewed-by: Daniel Libby <dlibby@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1015433}
--
wpt-commits: 97330944a2b19338d3f58955adb3250cf4b5279e
wpt-pr: 34480
Automatic update from web-platform-tests
May need paint invalidation on cache hit inside fragmentation.
When block-fragmented, LayoutBox stores the location in the flow thread
coordinate space, not the actual visual location. This means that we may
miss location changes, if the flow thread offset remains unchanged (if
the fragmentainer size changes without needing to re-lay out the
object).
Explicitly mark direct flow thread children for a paint invalidation
check, in case the cache was hit.
Bug: 1336180
Change-Id: I66342c80f2e6cb6478eff6f06d103a9a9c8ecd12
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3706987
Reviewed-by: Alison Maher <almaher@microsoft.com>
Reviewed-by: Koji Ishii <kojii@chromium.org>
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1015412}
--
wpt-commits: 8b9da29d2d6907de99c080562fdd9c69cda698f1
wpt-pr: 34470
Automatic update from web-platform-tests
Breaking before a float
In the added test case, the second float is processed in an earlier
fragmentainer than the first (nested) float. If the first float
ends up breaking before, we may try to break before the second
float, as well, even though it had already broken.
Instead, check if a float has broken previously before attempting to
add a break before it.
Bug: 1336847
Change-Id: Ic9231f3d93fbebae3bbf022641082c2b78829db6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3710174
Commit-Queue: Alison Maher <almaher@microsoft.com>
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1015370}
--
wpt-commits: 22d425520a0de4af40b56b5a35bc18b07cd9996c
wpt-pr: 34472
Automatic update from web-platform-tests
[intersection-observer] Add a test for clip-path being accounted for.
From https://w3c.github.io/IntersectionObserver/#calculate-intersection-rect-algo
step 3.3:
> If container has a content clip or a css clip-path property, update
> intersectionRect by applying container’s clip.
--
wpt-commits: d3d0aa492ab758a9b0ab55a27bd3957301071644
wpt-pr: 34400
Automatic update from web-platform-tests
Fix popup animation bug, and add more testing of animations
Primarily, this CL adds a test of popup animations for these two cases:
1. descendant elements have an animation: make sure "hide" waits for it
2. there are already-running animations: make sure "hide" doesn't wait
These were follow-up action items from [1].
While writing this test, I found and fixed a corner case bug: if there
are *only* pre-existing animations, a popup would never be hidden.
[1] https://chromium-review.googlesource.com/c/chromium/src/+/3688871
Bug: 1307772
Change-Id: I133f4d682bb8081b137fb23675137b06e6a15565
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3708115
Reviewed-by: Robert Flack <flackr@chromium.org>
Auto-Submit: Mason Freed <masonf@chromium.org>
Commit-Queue: Robert Flack <flackr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1015056}
--
wpt-commits: 93a98d6ac4785d3c78b57845d91c78e2bf12c6eb
wpt-pr: 34454
Automatic update from web-platform-tests
[intersection-observer] Allow to write promise-tests.
And port display-none.html to that.
--
wpt-commits: ec0a8769149aaf77d3520360ceb1277e9af43a22
wpt-pr: 34397
Alexandra Borovova
Jan de Mooij
Tooru Fujisawa
Mark Banner
Martin Robinson
Hubert Boma Manilla
Gabriele Svelto
Cristian Tuns
James Graham
Manuel Bucher
serge-sans-paille
Emilio Cobos Álvarez
Bogdan Szekely
Nicolas Chevobbe
moz-wptsync-bot
Morten Stenshorne
Maksim Sadym
Brad Triebwasser
Alison Maher
Romain Menke
Ana SollanoKim
Rune Lillesveen
dependabot[bot]
Mason Freed