The Web::CSS::Parser's GradientParsing ignores color-stops if
it is only a single one. This change allows to have color-stops
with double positions against a single color.
Further, also allows for `linear-gradient(black)` and similar
other gradient functions
Allow wheel event to be consumed by a `overflow: scroll` box only if it
has content that overflows a scrollport.
This fixes the timing issue in the
`Text/input/scroll-window-using-wheel-event.html` test, where a `<body>`
element with `overflow: scroll` was incorrectly consuming wheel events
that should have propagated to the window.
Using https://github.com/whatwg/html/pull/9457
(with some changes made to catch up with the current spec)
to fix a spec bug and a crash when removing a visible popover.
If a calculation was simplified down to a single numeric node, then most
of the time we can instead return a regular StyleValue, for example
`calc(2px + 3px)` would be simplified down to a `5px` LengthStyleValue.
This means that parse_calculated_value() can't return a
CalculatedStyleValue directly, and its callers all have to handle
non-calculated values as well as calculated ones.
This simplification is reflected in the new test results. Serialization
is not yet correct in all cases but we're closer than we were. :^)
The focus chain always consists of newly created GC::Root objects, so
the condition always produced `false`. The fix is to use GC::Root's
overloaded operator== method, which compares the pointers of the stored
type.
This fixes Figma dropdowns and context menus instantly disappearing
upon opening them. This is because they become focused when they insert
them. Because of this bug, it would fire blur events all the way up to
and including the window. Figma listens for the blur event on the
window, and when received, it will instantly hide dropdowns and context
menus. The intention behind this seems to be hiding them when the user
clicks off the browser window, or switches tab.
Several interfaces that return a high resolution time require that
time to be coarsened, in order to prevent timing attacks. This
implementation simply reduces the resolution of the returned timestamp
to the minimum values given in the specification. Further work may be
needed to make our implementation more robust to the kind of attacks
that this mechanism is designed to prevent.
We have an optimization that allows us to invalidate only the style of
the element itself and mark descendants for inherited properties update
when the "style" attribute changes (unless there are any CSS rules that
use the "style" attribute, then we also invalidate all descendants that
might be affected by those rules). This optimization was not taking into
account that when the inline style has custom properties, we also need
to invalidate all descendants whose style might be affected by them.
This change fixes this bug by saving a flag in Element that indicates
whether its style depends on any custom properties and then invalidating
all descendants with this flag set when the "style" attribute changes.
Unlike font relative lengths invalidation, for elements that depend on
custom properties, we need to actually recompute the style, instead of
individual properties, because values without expanded custom properties
are gone after cascading, and it has to be done again.
The test added for this change is a version of an existing test we had
restructured such that it doesn't trigger aggressive style invalidation
caused by DOM structured changes until the last moment when test results
are printed.
My previous attempt at resolving the continuation chain tried to deal
with `pointer-events: none` by repeatedly falling back to the parent
paintable until one was found that _would_ want to handle pointer
events. But since we were no longer performing hit-tests on those
paintables, false positives could pop up. This could happen for
out-of-flow block elements that did not overlap with their parent rects,
for example.
This approach works much better since it only handles the continuation
case that's relevant (the "middle" anonymous box) and it does so during
hit-testing instead of after, allowing all the other relevant logic to
come into play.
We do not fire `beforeinput` events since other browsers do not seem to
do so either.
The spec asks us to check whether a command's action modified the DOM
tree. This means adding or removing nodes and attributes, or changing
character data anywhere in the tree. We have
`Document::dom_tree_version()` for node updates, but for character data
a new version number is introduced that allows us to easily keep track
of any text changes in the entire tree.
Both Chrome and Firefox return `true` whenever the value string provided
is an invalid color or the current color. Spec issue raised:
https://github.com/w3c/editing/issues/476
Instead of ignoring any paintable immediately when they're invisible to
hit-testing, consider every candidate and while the most specific
candidate is invisible to hit-testing, traverse up to its parent
paintable.
This more closely reflects the behavior expected when wrapping block
elements inside inline elements, where although the block element might
have `pointer-events: none`, it still becomes part of the hit-test body
of the inline parent.
This makes the following link work as expected:
<a href="https://ladybird.org">
<div style="pointer-events: none">Ladybird</div>
</a>
Our layout tree requires that all containers either have inline or
non-inline children. In order to support the layout of non-inline
elements inside inline elements, we need to do a bit of tree
restructuring. It effectively simulates temporarily closing all inline
nodes, appending the block element, and resumes appending to the last
open inline node.
The acid1.txt expectation needed to be updated to reflect the fact that
we now hoist its <p> elements out of the inline <form> they were in.
Visually, the before and after situations for acid1.html are identical.
When an element is displayed as table, an anonymous table wrapper box
needs to be created for it. Among others, the position property of the
table element is then applied to the anonymous table wrapper box
instead. If the table happens to be positioned absolutely, the table
wrapper box may become the containing block for absolutely positioned
elements inside the table.
In the original code however, anonymous layout nodes were excluded from
becoming the containing block for an absolutely positioned element.
Because of this, the containing block was calculated to be the first
suitable parent block of the table wrapper box.
This incorrect containing block would result in a crash later on when
trying to size the absolutely positioned element inside the table. To
prevent this crash, the anonymous table wrapper box is now allowed to
become the containing block for absolutely positioned elements inside
a table.
The definition of containing block for an absolutely positioned element
in the spec does not mention anything about skipping anonymous boxes.
Additionally the rules for absolute positioning of tables
(https://www.w3.org/TR/css-tables-3/#abspos-boxes-in-table-root) imply
that a table wrapper box is indeed able to be the containing block for
absolutely positioned elements.
For example, running `alert(1)` will pause the event loop, during which
time no JavaScript should execute. This patch extends this disruption to
microtasks. This avoids a crash inside the microtask executor, which
asserts the JS execution context stack is empty.
This makes us behave the same as Firefox in the following page:
<script>
queueMicrotask(() => {
console.log("inside microtask");
});
alert("hi");
</script>
Before the aforementioned assertion was added, we would execute that
microtask before showing the alert. Firefox does not do this, and now
we don't either.
This is sub-optimal but let's rebuild the whole tree for now, since this
case gets quite complicated and there are more valuable things to chase
after first.
Thanks to Gingeh for the reduced test case!
