Clip frames for overflow were applied based on whether the box in
question had a non-identity matrix transformation associated with it.
That however is not correct, since specifying a no-op transform like
`scale(1)` still needs to apply clip overflow rectangles. So instead we
need to check whether the element associated with the box in question
has any CSS transforms.
This appears to have been a regression from
9bbc1cd618 and effectively reverts that
commit, but keeps its effect by unifying on the check for CSS transforms
instead.
This fixes some background boxes being rendered for the invisible items
of the carousels on https://computerbase.de/.
From what I can tell BMP files with an alpha channel always store
unpremultiplied alpha. So let's load them as such to avoid rendering
artifacts from using the wrong alpha type.
The style propagation logic in `NodeWithStyle::apply_style()`
was incomplete for anonymous nodes created during layout
(e.g., within `wrap_in_button_layout_tree_if_needed`).
1. **Non-inherited CSS values** were not being propagated to the
anonymous wrappers.
2. Propagation did not recurse into **nested anonymous wrappers**
(descendants).
This fix adds calls to `propagate_non_inherit_values(child)` and
`child.propagate_style_to_anonymous_wrappers()`, ensuring all computed
styles reach the entire anonymous wrapper hierarchy.
Fixes a bug where we would clip `box-shadow` when `overflow: hidden`
was set, which is not supposed to happen since `overflow` only affects
clipping of an element's content.
Per the CSS Namespaces spec, an empty string declared in an
@namespace rule represents no namespace.
Fixes WPT:
- css/css-namespaces/prefix-002.xml
- css/css-namespaces/prefix-003.xml
If there are multiple nested `position: fixed` or `position: absolute`
elements that are positioned based on their static position due to not
specifying any insets, we sum up all their ancestor offsets to calculate
said static position.
However, these offsets represent the offset to the containing block. So
summing up all the ancestor blocks will count elements multiple times
for cases where the containing block is not based on the closest element
capable of forming a containing block (i.e. absolute and fixed position
elements) when multiple such elements are nested.
With this change we only iterate over ancestors forming containing
blocks instead of over all ancestors boxes. To sum up everything between
the box currently being positioned and its containing block, we start
the iteration on the parent box of the current box.
This fixes 3 WPT tests that I could find. But these tests are not
intended to test the error cases fixed here, they just incidentally rely
on the correct behavior. As such, I have added dedicated tests myself.
Note that two of the tests already pass on master, but they seemed like
a good cases to have anyway.
The CSS spec says the baseline of an inline-block should be the bottom
margin when either the overflow property is not 'visible' or there are
no in-flow line boxes. Previously, only the latter case was checked.
This fixes 1 WPT test:
https://wpt.live/css/css-align/baseline-of-scrollable-1a.html
property_accepts_type() only looks at the property itself, not any
longhands it might have, so we thought that `font` didn't accept
`<custom-ident>`s, and seeing "-apple-..." makes us throw out the
declaration even though it's valid as a font name.
We'll reject these like any other unrecognized value if it's somewhere
that's not supported, so this was really just an optimization for a
rare edge case, and removing the check doesn't have any observable
effect except fixing this bug and any similar cases.
Changing property_accepts_type() to look at longhands is not
straightforward, as not all longhand values are valid in the shorthand.
This is required because bounding rect used in `saveLayer()` is computed
in stacking context's coordinate space.
Fixes regression introduced in ba2926f
When displaying SVGs inside a navigable directly, we want to display
them in the size specified by their width and height attributes instead
of stretching them to the viewport as layout normally would.
However, when doing so, we need to actually check that the SVG we are
laying out is indeed directly inside the navigable. Otherwise we just
blindly overwrite whatever content sizes have been calculated by layout
code for e.g. SVG elements inlined somewhere in an HTML document.
Due to the way this was written originally, the bug was not very
noticable. The code overwrote the content width/height with the computed
width/height, which was often still correct in the sense that those two
had the same value. However, content size may also be the result of
{min,max}-{width,height} constraints, which can make it differ from the
computed values.
This bug was likely a regression introduced in
f5e01192cc.
...in clip and scroll frames calculation algorithm.
Fix a regression from 719a50c where display-list recording disagreed
with the clipping logic about whether a stacking context is transformed.
`has_css_transform()` returns true whenever the computed transform is
not `none`, which differs from an identity-matrix check. These yield
different results for cases like `translate(0, 0)`.
This fixes an issue where text decorations (e.g. underlines) of text
split across multiple fragments would have unintended 1px gaps.
Gains us 2 WPT passes (imported)
Implements `::slotted()` to enough extent we could pass the imported WPT
test and make substantial layout correctness improvement on
https://www.rottentomatoes.com/
Fixes rendering of elements with large border-radius values by scaling
radii proportionally when they exceed element dimensions per CSS spec.
Co-authored-by: Samyat Gautam <thesamyatgautam@gmail.com>
If `will-change` is set to a property value where that property could
create a stacking context, then we create a stacking context regardless
of the current value of that property.
We should calculate whether we need to truncate text with an ellipsis
exclusive of any trailing collapsible whitespace.
This was causing issues where an inline element was automatically sized
(e.g. min-content) as we would calculate available width exclusive of
trailing collapsible whitespace and then our text chunk would be wider,
always inserting an ellipsis.
Fixes the visual element of #4048 but we still are incorrect in how we
collapse whitespace more generally
As of 7dc8062 paintables compute and cache their visibility (which
depends on opacity) at construction - this cached value can fall out of
sync with reality if if the opacity changes to/from zero within the
lifetime of that paintable.
This commit invalidates layout when an opacity changes to/from zero so
that we reconstruct paintables with the correct visibility.
