This has to cheat and use a screenshot but thanks to the "Take Full
Screenshot" feature of Ladybird, it is very easy to update this test.
The steps are documented in the test.
These were added when Gfx::Rect was made endpoint exclusive, however,
for this code an offset of ±1 makes no visible difference (but makes the
code look a little confusing).
On Serenity and on my Linux machine, we have a 1:1 CSS-to-device pixel
ratio. On macOS, we have a 2:1 ratio. This did not affect the Qt chrome,
because we are ignoring this position and placing the context menu at
the globally-accessible mouse position. The AppKit chrome will be using
this position, though.
This might be what caused the issue worked around by commit 8177ecb.
Having all 4 of these methods together makes it more immediately obvious
that the 2 moved here are not correct (we are not converting the CSS
pixel point to a device pixel point).
When a box is sized under max-content constraint, any percentage value
set for max-width should be considered as if it were infinite. In other
words, it should have no effect on restricting the box's width.
This effectively makes it per-Document, but we hang it off of
StyleComputer since that's what it's used for.
The purpose of this is to prevent downloaded fonts from escaping the
context that loaded them. There's probably a more elegant solution where
we still share caching of system fonts, but let's start here.
This change introduces a very basic GC graph dumper. The `dump_graph()`
function outputs JSON data that contains information about all nodes in
the graph, including their class types and edges.
Root nodes will have a property indicating their root type or source
location if the root is captured by a SafeFunction. It would be useful
to add source location for other types of roots in the future.
Output JSON dump have following format:
```json
"4908721208": {
"class_name": "Accessor",
"edges": [
"4909298232",
"4909297976"
]
},
"4907520440": {
"root": "SafeFunction Optional Optional.h:137",
"class_name": "Realm",
"edges": [
"4908269624",
"4924821560",
"4908409240",
"4908483960",
"4924527672"
]
},
"4908251320": {
"class_name": "CSSStyleRule",
"edges": [
"4908302648",
"4925101656",
"4908251192"
]
},
```
This doesn't seem to actually have fixed any bugs, as having
FillOpacity instead of StrokeOpacity in the call to parse_css_value
doesn't seem to have actually been causing bugs. But, I still think it's
worthwhile correcting.
The reason that it wasn't causing bugs is that having FillOpacity
instead of StrokeOpacity in the call to parse_css_value means that when
parsing the value is compared to the acceptable values for that property
(for example the value can only be a percentage, or a number, etc.). In
this case both FillOpacity and StrokeOpacity seem to accept the same
values.
The SVG G container should have the same size as its children. This
fixes a bug when there was an opacity value on the G element, as in
StackingContext it would try and get a bitmap of the element which would
be empty due to it having no size.
We had `parse_calculated_value()` which parsed the contents of `calc()`,
and `parse_dynamic_value()` which parsed any math function, both of
which produce a CalculatedStyleValue, but return a plain StyleValue.
This was confusing, so let's combine them together, and return a
CalculatedStyleValue.
This also makes the other math functions work in
`StyleComputer::expand_unresolved_values()`.
Note that we already have Size::scaled(T). While subjectively providing
API symmetry, this is mostly to allow using these methods in templated
helpers without caring what the exact underlying type is.
Ignoring Size for a second, we currently have:
Rect::scale_by
Rect::scaled
Point::scale_by
Point::scaled
In Size, before this patch, we have:
Size::scale_by
Size::scaled_by
This aligns Size to use the same method name as Rect and Point. While
subjectively providing API symmetry, this is mostly to allow using this
method in templated helpers without caring what the exact underlying
type is.
Trying to run a worker right now just results in the WebContent process
asserting down the road, so let's throw and log a FIXME instead.
This makes it easier to see what's failing. We'll obviously remove this
once we get workers working correctly. :^)
This would cause a nullptr-deref during painting of invalid
linear-gradients, such as `linear-gradient(top, #f8f9fa, #ececec)`
found in googles sign-in button
If we double-click on a TextEditor that has spans, but the click itself
was not on a span, fall back to the without-spans behavior. Previously
the cursor would instead jump to the end of the document.
We now keep the color value as a StyleValue up until we go to paint the
gradient, which makes `currentColor` work, along with any other color
values that can't be immediately converted into a `Gfx::Color` while
parsing.
It wasn't enough to do it only for simple glyphs, we need to do it for
composite glyphs as well.
Fixes an issue where some glyph data was misaligned in the output and
thus ended up rendered incorrectly or not at all.
