Before we ask a replaced box about its intrinsic dimensions, we have
to "prepare" the box, which tells it to go and work out what its
intrinsic dimensions are.
I've added a FIXME about how this is silly (and clearly bug-prone)
but this patch only patches it locally in FFC for now.
Used by Google seemingly almost all around account sign in and
management. The modern sign in page has this near the beginning:
```html
<base href="https://accounts.google.com">
```
All of the XHRs performed by sign in are relative URLs to this
base URL. Previously we ignored this and did it relative to the
current URL, causing the XHRs to 404 and sign in to fall apart.
I presume they do this because you can access the sign in page
from multiple endpoints, such as `/ServiceLogin` and
`/o/oauth2/auth/identifier`
Previously, this was slightly off and not doing what the spec comment
above asked for. This led to really small values for x_step and
y_step, making the `backgrounds.html' example use crazy amounts of
CPU whist painting.
From the spec:
> This property previously accepted the values optimizeSpeed and
optimizeQuality. These are now deprecated; a user agent must accept
them as valid values but must treat them as having the same behavior
as pixelated and smooth respectively, and authors must not use them.
- https://www.w3.org/TR/css-images-3/#the-image-rendering
It's probably not in 1:1 as spec says, as it wants us to first upscale
the image to the nearest integer and then downscale it bilinearly.
But this mode still falls into the general description of the value:
> The image is scaled in a way that preserves the pixelated nature of
> the original as much as possible, but allows minor smoothing instead
> of awkward distortion when necessary.
Also, this way we don't have to allocate the memory just for the integer
scale. :^) :^)
This is a helper class for clipping the corners off a element.
This works in a similar way to how (outline) borders are painted.
The steps are:
1. A small bitmap that fits only the corners is allocated
2. The corners are painted into the bitmap
3. The existing pixels (where the corners will be painted)
are copied using the (inverse) corner bitmap as a mask
(done before the element is painted)
4. The element is painted
5. The areas outside the corner radii are restored
Like with the borders, this only requires allocation on the first
paint.
Implement parsing of rgb(..) and hsl(..) in both the modern level 4
syntax without commas, and the legacy syntax with commas.
The parser accepts non-integer numbers but rounds to integer values
for now.
This commit reimplements the (normally) 45 degree (depends on
the widths) connection between to adjacent borders. Which is
needed to paint the 'caret' icon seen in a few buttons on GitHub.
The issue of overlapping pixels while painting this has also
been solved for the 45 degree case (the the most likely case,
the other cases only occur of mixed-with borders).
This commit adds some much nicer border painting, which now supports:
- Elliptical corners
- Blending between different border thicknesses, with rounded corners
- Anti-aliasing
There are some little TODOs left to tackle:
- Painting the corners with line styles other than solid
- Blending between colors on the corners (see comments)
The painting requires allocating a small bitmap, that only fits the
corners (so in most cases this is very small).
This bitmap is then cached so for all paints but the first there will
be no further allocations.
Using auto& when indexing an NNRPVector doesn't cause it to hold a
strong reference and is instead just a plain old reference.
If m_rules was the only storage holding a strong reference to old_rule,
we would remove it in step 4 and subsequently UAF it in step 5.
Previously, floating elements computed the width by only using the
`width` property. Now, they will also use the `min-width` and
`max-width` properties. :^)
The new steps are from "10.4. Minimum and maximum widths: 'min-width'
and 'max-width'" in the CSS 2 spec.
Found it when looking at curl.se.
This improves our spec compliance by allowing the user to click
non-element nodes (like text) and having the click be registered with
the parent element (like a div or button). This makes Fandom's cookie
accept button work if you click the text. Additionally, the events test
page contains a test to check the target element, which would previously
not exist when we fired the event at a non-element.
