This fixes some off-by-one wrapping issues that became visible when
running on x86_64. The problem still existed on i686, but by chance
did not show up due to a -/+ 0.000001 difference between the two.
In particular, StringView::contains(char) is often used with a u32
code point. When this is done, the compiler will for some reason allow
data corruption to occur silently.
In fact, this is one of two reasons for the following OSS Fuzz issue:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=49184
This is probably a very old bug.
In the particular case of URLParser, AK::is_url_code_point got confused:
return /* ... */ || "!$&'()*+,-./:;=?@_~"sv.contains(code_point);
If code_point is a large code point that happens to have the correct
lower bytes, AK::is_url_code_point is then convinced that the given
code point is okay, even if it is actually problematic.
This commit fixes *only* the silent data corruption due to the erroneous
conversion, and does not fully resolve OSS-Fuzz#49184.
Add ability to use values passed to grid-template-columns and
grid-template-rows for CSS Grid layout within a repeat() function.
E.g. grid-template-columns: repeat(2, 50px); means to have two columns
of 50px width each.
Hopefully no one else will forget to call set_prototype with the cached
prototype they just retrieved from a realm and spend a long time
wondering why their object has no properties...
Get rid of the bespoke NavigatorObject class and use the modern IDL
strategies for creating platform objects to re-implement Navigator and
its associcated mixin interfaces. While we're here, implement it in a
way that brings WorkerNavigator up to spec :^)
We can now properly add the prototypes and constructors to the global
object of the Worker's inner realm, so we don't need this window for
anything anymore.
The intent is to use these to autogenerate prototype declarations for
Window and WorkerGlobalScope classes.
And the spec links are just nice to have :^)
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.
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.
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.
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.
Now that we don't have to deal with the ad-hoc "inline" flag on layout
nodes anymore, we're free to simply obey the inline-outside flag from
the CSS display value when choosing whether to insert as an inline-level
node or not.
Before this, whenever encountering something other than dumb text
content in an inline flow, we assumed it had to be either a replaced
element, or an inline-block.
This removes the special-casing of inline-block so that IFC can size and
layout anything as long as it's inline on the outside.
There's no need to make the assumption that any inline-block box will
be represented by a BlockContainer. Nothing we do with the box here
requires that specific type anyway.
