When the indicated column-span is greater than the implicit grid (like
in cases when the grid has the default size of 1x1, and the column is
supposed to span any number greater than that), then previously were
crashing.
Fixes a bug in the maybe_add_column() implementation of the
OccupationGrid. Previously were checking for the width of the grid based
off of the first row, and so when augmenting the column count row-by-row
the latter rows would have differing column counts.
Also, were doing an unnecessary + 1 which I imagine comes from before
when I wasn't quite clear on whether I was referring to columns by
index or by the css-value of the column (column 1 in the css is
column index 0).
This implementation includes a first cut at run the unfocusing steps
from the spec, with many things left unimplemented.
The viewport related spec steps in particular don't seem to map to
LibWeb concepts, which makes figuring out if things are properly focused
much more difficult.
GCC seems to get tripped up over this inheritance when converting from
an ErrorOr<StringView> to the partially specialized ErrorOr<void>. See
the following snippet:
NEVER_INLINE ErrorOr<StringView> foo()
{
auto string = "abc"sv;
outln("{:p}", string.characters_without_null_termination());
return string;
}
NEVER_INLINE ErrorOr<void> bar()
{
auto string = TRY(foo());
outln("{:p}", string.characters_without_null_termination());
VERIFY(!string.starts_with('#'));
return {};
}
int main()
{
MUST(bar());
}
On some machines, bar() will contain a StringView whose pointer has had
its upper bits set to 0:
0x000000010cafd6f8
0x000000000cafd6f8
I'm not 100% clear on what's happening in the default-generated Variant
destructor that causes this. Probably worth investigating further.
The error would also be alleviated by making the Variant destructor
virtual, but rather than that, let's make ErrorOr simply contain a
Variant rather than inherit from it.
Fixes#15449.
All the required bits were already there. Also, this would probably
work on FreeBSD without modification but I don't currently have
a system to test this on.
For percentage cross min/max sizes that resolve against indefinite
available space, we now essentially ignore them instead of resolving
them to 0 at the start of layout.
This fixes `combine_hangul_code_points` which would try to combine
a LVT syllable with a trailing consonant, resulting in a wrong
character.
Also added a test for this specific case.
Yet another legacy "is inline-block?" condition was causing us to insert
inline nodes directly as children of inline-flex containers (instead of
wrapping them in anonymous blocks, which would then cause them to become
flex items.)
We're supposed to hit test positive z-index stacking contexts first,
and negative z-index stacking contexts later. Instead, we were hit
testing all stacking contexts both times.
This made hit testing unbearably slow on some websites.
While we're here, also add an extra comment about why stacking contexts
are traversed in reverse order. It tripped me up while looking at this,
so I'm sure it could trip someone else up too.
Regressed in 44057c9482.
An "inherit attribute" calls an ancestor's getter with the same name,
but defines its own setter. Since a parent class's public methods are
exposed to child classes, we don't have to do any special handling here
to call the parent's methods, it just works. :^)
Previously, every Editor instance had two instances of tooltip windows
& `OutOfProcessWebView`s, one for documentation and one for parameter
hints.
They were initialized with the Editor, which slowed down creation of new
tabs.
We use a single global tooltip & OOPWV instance that is shared between
tabs.
Closes#15488
Co-authored-by: Sam Atkins <atkinssj@serenityos.org>
Ensure that when a grid item is passed with a span and a fixed end
position, that if the resulting start of this item is less than 0 then
it won't throw. This is a temporary measure until the correct
functionality is implemented.
These changes improve the parsing of the span property, including
handling negative values for the span (defaults to 1), as well as when
no number is passed (also defaults to 1).
After having corrected the tracking of span variables in the
GridTrackPlacement class, now can fix some small bugs for its correct
implementation in the GridFormattingContext class.
Implement span correctly when indicated in the grid-column-start,
grid-row-start, etc. CSS properties. Previously it had been implemented
as if span was something that went alongside the position property, but
actually it seems like if you do 'span 3' in the grid-column-start
property, for example, this means it literally spans 3 blocks, and the
3 has nothing to do with position.
This fixes something I thought I had already fixed everywhere, where
previously there wasn't the possibility to have an Auto
GridTrackPlacement and so the Auto "implementation" was simply checking
if the position of the track was 0.
We were skipping over inline flex containers when looking for an
insertion parent. This made us not generate flex items in those cases.
This commit changes the behavior, so that non-inline-level items can
get inserted into an inline-outside parent, as long as the parent isn't
just flow-inside.
