In some cases, we have a timestamp as a double in milliseconds. We then
would convert it to nanoseconds as a BigInt, just to bring it back to a
double for TZDB lookups. Add an overload to avoid this needless round
trip.
Even though the underlying time zone is already cached by LibUnicode, JS
performs additional expensive lookups with that time zone. There's no
need to do those lookups again until the system time zone has changed.
Note that we can currently only use simdutf for Base64 decoding if the
provided stopBeforePartial option is loose, which is the default. There
is an open issue for simdutf to implement strict and stop-before-partial
options. Until then, for those options, we implement a slow decoder that
is written exactly as the spec steps dictate.
See: https://github.com/simdutf/simdutf/issues/440
Choosing options from the `<select>` will load and display that style
sheet's source text, with some checks to make sure that the text that
just loaded is the one we currently want.
The UI is a little goofy when scrolling, as it uses `position: sticky`
which we don't implement yet. But that's just more motivation to
implement it! :^)
This will be used by the inspector, for showing style sheet contents.
Identifying a specific style sheet is a bit tricky. Depending on where
it came from, a style sheet may have a URL, it might be associated with
a DOM element, both, or neither. This varied information is wrapped in
a new StyleSheetIdentifier struct.
This is to enable the inspector to show this source.
There's a fairly hefty FIXME here because duplicating the source text is
a significant waste of memory. But I don't want to get too sidetracked.
This is only used for CSS style sheets. One case wants it as a String,
and the others don't care, but will in future also want to have the
source as a String.
When trying to use pkgconfig for finding libjxl, the build fails
trying to link the cross-compiler's libc++.
Using this way libjxl also requires hwy library.
Findlibjxl.cmake was taken from SDL_image and altered to include its license.
Calls to `Document::set_needs_display()` and
`Paintable::set_needs_display()` now invalidate the display list by
default. This behavior can be changed by passing
`InvalidateDisplayList::No` to the function where invalidating the
display list is not necessary.
By checking the lengths and then looking directly at the bytes, the
generated code becomes a lot nicer.
This gives a 1.23x speedup when parsing the JS from x.com
Use offset from ScrollFrame which is an actual value a box is shifted by
while painting.
Also change `update_paint_and_hit_testing_properties_if_needed()` to
refresh scroll frames state, because `getBoundingClientRect()` now
depends on them.
Fixes wrong file tree sidebar location and excessive layout
invalidations caused by some miscalculation on JS-side when wrong
bounding client rect is provided on Github PR pages like
https://github.com/LadybirdBrowser/ladybird/pull/1232/files
Scroll offset of body does not affect position of fixed elements, so
nearest scrollable lookup should early return from ancestor scrollable
lookup loop once "position: fixed" box is encountered.
Fixes regression introduced in 866608532a
Otherwise, it looks a bit awkward where the cursor position does not
update while the selection is elsewhere.
Note that this requires passing along the raw selection positions from
`set the selection range` to the elements. Otherwise, consider what will
happen if we set the selection start and end to the same value. By going
through the API accessor, we hit the case where the start and end are
the same value, and return the document cursor position. This would mean
the cursor position would not be updated.
The test changes here more closely match what Firefox produces now. It
is not a 100% match; the `select event fired` test case isn't right. The
problem is the event fires for the input element, but we most recently
focused the textarea element. Thus, when we retrieve the selection from
the input element, we return the document's cursor position, which is
actually in the textarea element. The fix will ultimately be to fully
implement the following:
https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#concept-textarea/input-cursor
That is, each input / textarea element should separately track its own
text cursor position.
Append text chunks to either the start or end of the text fragment,
depending on the text direction. The direction is determined by what
script its code points are from.
Implements:
"If the product of the hypothetical fr size and a flexible track’s flex
factor is less than the track’s base size, restart this algorithm
treating all such tracks as inflexible."
Fixes https://github.com/LadybirdBrowser/ladybird/issues/1211
Sticky positioning is implemented by modifying the algorithm for
assigning and refreshing scroll frames. Now, elements with
"position: sticky" are assigned their own scroll frame, and their
position is refreshed independently from regular scroll boxes.
Refreshing the scroll offsets for sticky boxes does not require display
list invalidation.
A separate hash map is used for the scroll frames of sticky boxes. This
is necessary because a single paintable box can have two scroll frames
if it 1) has "position: sticky" and 2) contains scrollable overflow.