Having the pull_request 'labeled' event trigger the main CI is much too
impactful, since it cancels running jobs and does not start anything if
the label is anything else than 'windows'. Let's go with a different
approach and put the Windows CI job in a separate workflow.
How this works:
* Jobs are only run if the 'windows' label is present on the PR.
* If a PR is opened or updated, existing jobs are canceled.
* If a PR is (un)labeled, existing jobs are only canceled if the label
was 'windows'. Other labels cause the job to be rescheduled.
As far as I can see, there's no way to prevent the job from being
rescheduled when labels other than 'windows' are being added or removed.
However, by not canceling the existing Windows job, we can try to create
a cache so the next run will be much quicker.
Each matrix item now defines whether it is enabled, and if not, the job
conditionally disables itself. Apparantly we cannot use expressions in
`matrix.exclude`, but it should work in the items' definitions.
This has the added benefit that this makes the job show up as "skipped",
which could serve as a hint that it could be run on a PR.
Our CI matrix now includes Windows if the 'windows' label is added to
the PR. The job still takes too long to include it for every PR, but it
is certainly useful to have it run on Windows-specific PRs and PRs that
might break Windows builds.
`getComputedStyle()` for grid tracks returns style value produced during
layout. This is needed to return resolved track sizes values which are
thrown away after layout is done. Now GFC produces more correct style
value by not ignoring grid line names.
Reimplements `grid`, `grid-template`, `grid-template-rows`, and
`grid-template-columns` in a way that uses a separate function for each
grammar rule defined in the specification. This change results in many
additional passing tests from the already imported WPT suite. Most of
the remaining test failures are related to incorrect serialization of
grid properties.
Any optional or nullable attribute will end up in an `if/else` branch
when we collect the attribute values, and this is inherently
incompatibly with an `auto {attr}_wrapped = ...` expression. Define the
variable as an `JS::Value` before generating the wrap statement so we
can properly support `toJSON()` for an attribute like:
readonly attribute double? altitude;
In `InlineLevelIterator`, whenever we call `skip_to_next()` and enter a
node with box model metrics, we could potentially accumulate leading and
trailing metrics. This lead to a weird situation where an element with
`display: inline-block` could adopt the leading metrics of an inline
element that follows it, since we perform the call to
`add_extra_box_model_metrics_to_item()` too late.
Move `skip_to_next()` down so it no longer interferes with the `Item`
we're creating.
The test expectation for
`atomic-inline-with-percentage-vertical-align.html` is updated, although
neither the old nor new results are 100% accurate since either box jumps
one pixel to the right.
When expanding "required line breaks", we now write directly into the
final StringBuilder instead of doing a pass of Vector remove/insert
operations first.
This removes a hot profile item on https://serpapi.com/
There are multiple things happening here which are interconnected:
- We now use AbstractElement to refer to the source of a counter, which
means we also need to pass that around to compute `content`.
- Give AbstractElement new helper methods that are needed by
CountersSet, so it doesn't have to care whether it's dealing with a
true Element or PseudoElement.
- The CountersSet algorithms now walk the layout tree instead of DOM
tree, so TreeBuilder needs to wait until the layout node exists
before it resolves counters for it.
- Resolve counters when creating a pseudo-element's layout node. We
awkwardly compute the `content` value up to twice: Once to figure out
what kind of node we need to make, and then if it's a string, we do
so again after counters are resolved so we can get the true value of
any `counter()` functions. This will need adjusting in the future but
it works for now.
This is one of those cases where the spec says "element" and
means "element or pseudo-element". The easiest way to handle both is to
make these be free functions that take an AbstractElement, and then
give AbstractElement some helper methods so that the caller doesn't
have to care which it's dealing with.
There are some FIXMEs here because PseudoElement doesn't have a
CountersSet yet, and because the CountersSet currently uses a
UniqueNodeID to identify counter sources, which doesn't support
pseudo-elements.
We were calculating the scroll delta based on the last known mouse
position, even if that position ventured far beyond the scroll bar's
rect. This caused weird behavior such as scrolling when the mouse was
clearly not on the scrollbar.
This reworks the scrollbar logic to use the mouse's absolute position
instead of a delta, and to always calculate and set the absolute scroll
offset. This makes it much easier to reason about the scrollbar's
position, plus we don't need the last mouse position anymore.
As far as I can tell, our scroll bar behavior now closely resembles
Firefox' behavior.
