Absolutely positioned elements inside SVG foreignObject were being
positioned relative to an ancestor containing block outside the SVG,
instead of relative to the foreignObject itself. Per a W3C resolution
and the behavior of other browsers, foreignObject should establish a
containing block for absolutely and fixed positioned elements.
With this fix, the `has_abspos_with_external_containing_block` check
in `set_needs_layout_update()` and the abspos preservation loop in
`relayout_svg_root()` become dead code — remove both and simplify the
ancestor loops. Rename related tests to reflect the new behavior.
Fixes https://github.com/LadybirdBrowser/ladybird/issues/3241
The test triggers repeated partial relayout inside a nested SVG and
checks paintables on an outside-subtree SVG ancestor via
`internals.dumpPaintableTree()`. The count should stay stable, but
currently grows, revealing that partial relayout is creating extra
ancestor paintables instead of preserving existing ones.
No fix in this commit; this commit only captures the failing behavior.
When a CharacterData mutation inside a foreignObject triggered partial
SVG relayout, sibling absolutely positioned elements whose containing
block is outside the SVG were not being repositioned. This happened
because the check only walked ancestors of the changed node looking for
abspos elements — it never saw abspos siblings.
Fix by querying contained_abspos_children() on boxes outside the SVG
subtree, which finds all abspos elements regardless of their position
in the tree relative to the changed node.
When a text node changes inside an absolutely positioned element within
an SVG <foreignObject>, and the abspos element's containing block is
outside the SVG subtree, the layout invalidation was incorrectly
stopping at the SVG root boundary. This triggered partial SVG relayout,
which cannot re-layout the abspos element since it's laid out by its
containing block's formatting context (outside the SVG).
The previous check only tested whether `this` (the node triggering
invalidation, e.g. a text node) was absolutely positioned, missing the
case where an abspos *ancestor* in the path has its containing block
outside the SVG. Fix this by walking from `this` up to the SVG root and
checking every abspos node in the path. If any has a containing block
outside the SVG subtree, skip the SVG boundary so layout propagation
continues upward and a full layout runs.
This is a regression test for partial SVG relayout. When an absolutely
positioned element inside foreignObject has its containing block outside
the SVG subtree, changing its size should trigger a correct relayout.
This test covers the case where an absolutely positioned element inside
<foreignObject> has a containing block that is an ancestor of the <svg>.
It serves as a regression test for partial SVG relayout that is going
to be introduced in the upcoming changes.
SVG root elements (SVGSVGBox) have intrinsic sizes determined solely
by their own attributes (width, height, viewBox), not by their
children. SVGFormattingContext::automatic_content_width/height() both
return 0 unconditionally, confirming children never contribute to the
SVG root's intrinsic size from the CSS layout perspective.
This means changes inside an SVG subtree cannot affect ancestor
intrinsic sizes, so we can stop the cache invalidation traversal at
SVG root boundaries, just like we already do for absolutely positioned
elements.
When an SVGElement is removed from a <use> element's shadow tree, we
need to check if it was in a use element's shadow root to avoid
notifying use elements about the removal of their own clones.
The check was incorrectly using root() instead of old_root. Since the
element has already been detached when removed_from() is called,
root() no longer returns the shadow root, causing the early-return
check to fail.
This led to O(n) recursion depth when clearing a use element's shadow
tree, as each removed clone would trigger another round of
remove_all_children() on use elements referencing the same ID.
Per SVG2 spec (§ Geometry Properties: getBBox), getBBox() must throw
InvalidStateError if the element is not rendered and its geometry cannot
be computed. Previously we would crash on null paintables; now we throw
with a clear error instead.
From the SVG spec
The value of the ‘viewBox’ attribute is a list of four numbers <min-x>,
<min-y>, <width> and <height>, separated by whitespace and/or a comma...
Currently try_parse_view_box will fail to parse the attribute if the
values are separated by commas.
This change replaces try_parse_view_box with a more correct
implementation. It will reside in the AttributeParser.cpp. This new
implementation correctly handles comma-separated viewBox values, and is
also more robust against invalid inputs.
Additionally, it adds a new test case to ensure viewBox values with
various syntax are parsed correctly and invalid values are rejected.
An SVGLength can be read-only, e.g. all animVal values cannot be
modified. Implement this for all instantiations of SVGLength.
While we're here, add `fake_animated_length_fixme()` so we can easily
find all sites where we need to improve our animated length game.
We were failing to discriminate between DOM removals happening to SVG
elements cloned as part of an SVG use element instantiation.
When a "use source" element is removed, all clones of that source must
be updated to reflect the change. But when a "use clone" element is
removed, that's fine.
This was causing the surprising disappearance of use element subtrees,
seen for example on https://cal.com/
Since SVG gradients can reference each other, we have to keep track of
visited gradients when traversing the link chain, or we will recurse
infinitely when there's a reference cycle.
This attribute has some compatbility issues...
- The spec says it should be an SVGAnimatedRect which contains
a DOMRect and a DOMReadOnlyRect.
- Blink gives you an SVGAnimatedRect with 2x SVGRect
- Gecko gives you an SVGAnimatedRect with 2x SVGRect? (nullable)
I ended up with something similar to Gecko, an SVGAnimatedRect
with 2x DOMRect? (nullable)
With this fixed, we can now load https://polar.sh/ :^)
It does not currently handle any of the actual scripting, but this
should at least allow us to create an instance of the element.
The test being added here isn't actually testing much, but before the
previous commit we used to crash parsing the page due to a TODO().
