Resize the clipboard history size dynamically by listening for config
changes. This is currently not ideal since we don't have the callbacks
for `Config::Listener::config_i32_did_change`, so for now we are just
taking the string and attempting to convert it to an int.
The number of items in history was hardcoded to 20 earlier, now
we try to load this value from a config file. The default if none
is available is still 20.
If we hit an assertion while the heap isn't in a stable state, we can't
rely on dynamic memory allocation because the malloc mutex is already
held and the heap is most likely corrupted. Instead, we need to bail
out fast before we make the situation even worse.
Instead of trying to layout SVG boxes as if they are regular CSS boxes,
let's invent an "SVG formatting context" and let it manage SVG boxes.
To facilitate this, Layout::SVGBox no longer inherits from ReplacedBox,
and is instead a simple, "inline-block" style BlockBox.
The POSIX manpage just says that wctrans_t should be "a scalar type that
can hold values which represent locale-specific character mappings", and
doing switch statements with ints is much more pleasant than with
pointers.
If our parent in the FlexFormattingContext also was a flex-container, we
didn't give our children any meaningful width to play with into
layout_inside(), which resulted in way too narrow layouting.
Now the width of the parent gets borrowed if the own width isn't
specified.
The previous VERIFY_NOT_REACHED() could be reached when there were equal
coodinates. This could be the case for a small radius which lead to
rounding making the two coordinates equal.
This adds an option for even more magnification, when you really need to
count pixels, as well as pausing the capture by pressing Space and
switching between magnification levels with keys 2, 4 & 8.
This now uses the values in `InitialValues`, which is not ideal, but
it's better to have our defaults defined in two places, than in 3.
The default for `border-colors` is `currentcolor`, so we shortcut that
here and just grab the value of the `color` property. As noted, this is
not perfect, but it's somewhat better.
- The `text-decoration-foo` values now match the spec.
- Added values for `border-foo` since those are needed soon.
- Make `color`'s initial value be `-libweb-palette-base-text`.
When parsing shorthand values, we'd like to use
`property_initial_value()` to get their longhand property values,
instead of hard-coding them as we currently do. That involves
recursively calling that function while the `initial_values` map is
being initialized, which causes problems because the shorthands appear
alphabetically before their longhand components, so the longhands aren't
initialized yet!
The solution here is to perform 2 passes when generating the code,
outputting properties without "longhands" first, and the rest after.
This could potentially cause issues when shorthands have multiple
levels, in particular `border` -> `border-color` -> `border-left-color`.
But, we do not currently define a default value for `border`, and
`border-color` takes only a single value, so it's fine for now. :^)
This was specifically causing the string "0" to be parsed as an invalid
Dimension token with no units, instead of as a Number. That then caused
out generated `property_initial_value()` function to fail for those
values.
Shorthand properties were only checking for `ColorStyleValue`s, which
excludes identifier colors. Now they accept them too, including the
various `-libweb-foo` colors. :^)
The `currentcolor` identifier represents the current value of the
`color` property. This is the default value for `border-color` and
`text-decoration-color`, and is generally useful to have. :^)
For now this is just a standard implementation of the longest
common subsequence algorithm over the lines, except that it doesn't
do any coalescing of the lines. This isn't really ideal since
we get a single Hunk per changed line, and is definitely something
to improve in the future.
This patch ups the max number of heap allocations between each GC
from 10'000 to 100'000. This is still relatively aggressive but already
does a good job of cutting down on time spent in GC.
This prevents flickering by ensuring that WebContent is only ever
painting into the back buffer bitmap. Without this change, it was
possible for WebContent to paint into the front buffer bitmap.
These would cause the stack to overflow when LibWeb tried rendering a
CSS box-shadow for a large enough element.
Use Vector (with *some* inline capacity for smaller images) to avoid
this issue. If these heap allocations turn out to be too much work,
we can add something like a persistent scratch buffer cache.
