This also adds spec comments to parseFloat to make it clear that we are
now deviating a bit from the spec (the TrimString invocation should be
infallible, but we want to propagate OOM errors).
CSS 2.2 section 9.5.1:
The outer top of a floating box may not be higher than the
outer top of any _block_ or floated box generated by an
element earlier in the source document.
Where block is `BlockContainer` in LibWeb type system.
Which means `current_boxes` need to be cleared before
leaving block container.
```html
<style>
.wrapper {
width: 100px;
height: 300px;
background-color: lightgray;
}
.box {
margin: 10px;
width: 50px;
height: 50px;
float: left;
}
.a { background-color: salmon; }
.b { background-color: slateblue; }
.c { background-color: green; }
</style>
<div class="wrapper">
<div class="box a"></div>
<div class="box b"></div>
</div>
<div class="box c">
</div>
```
While at it, rename the `read_trivial_value` and `write_trivial_value`
functions to `read_value` and `write_value` respectively, since we'll
add compatibility for non-trivial types down the line.
This error was introduced by 9a7accdd and had a significant impact on
`BufferedFile` behavior. Hence, we started seeing crash in test262.
By itself, the issue was a wrong calculation of the internal reading
spans when using the `read` and `until` parameters. Which can lead to
at worse crash in VERIFY and at least weird behaviors as missed needles
or detections out of bounds.
It was also accompanied by an erroneous test.
This patch fixes the bug, the test and also provides more tests.
Assert that the type of offsetString is either undefined or
string in order to avoid unnecessary ToString
Temporal commit: tc39/proposal-temporal@24ebcbd
The only part of TemporalDateTimeToString that can fail is
MaybeFormatAnnotateCalendar which cannot fail if showCalendar is
"never" as it simply makes an empty string.
Temporal commit: tc39/proposal-temporal@a1faee6
As for Solitaire, we previously had a warning when trying to exit Spider
while a game was in progress. This adds the same functionality to other
actions that would end the current game: Starting a new one, or
changing the number of suits. When changing the number of suits, we do
apply the setting, so it will take effect for the next game that is
started.
We previously had a warning when trying to exit Solitaire while a game
was in progress. This adds the same functionality to other actions that
would end the current game: Starting a new one, or changing the number
of cards drawn. When changing the number of cards drawn, we do apply
the setting, so it will take effect for the next game that is started.
I used this utility to check if the possible TGA images' cases for
different origins (explictly the Y origin) are generating the same
bitmap, as I felt that my eyes are not a good-enough measurement tool
for this kind of task.
This might be useful in the future for testing other implementations so
I rather have this nice utility in our codebase.
RLE is an old technique being used for decades, as is known as
Run-Length-Encoding, which means that for repeating sequence of bytes,
we keep an indicator for the length of the sequence and only one sample
of it, to save storage space.
GIMP can generate lossless-compressed TGA images, with RLE compression
being used. It means that for a compressed image, the data is no longer
arranged in sequence of pixels, but a sequence of pixel packets.
There are two possible pixel packets:
- RLE packets, which are encoded with one byte for indicating the
run-length and another one pixel (3 bytes for TrueColor pixel), so
essentially in runtime, the TGA decoder will use the length to plot
the same pixel in multiple pixels of the output pixel bitmap.
- Raw packets, which are encoded with one byte as indicator for the
length of the whole pixel sequence and N-length pixel sequence
afterwards.
This is not used for any sort of compression by the TGA format, but
still needed to be supported for full compatibility with TGA images
that uses the RLE compression.
GIMP allows a user to export a TGA image with either of these possible
orientations, so we can easily support it by looking at the X origin and
Y origin values to determine where to put the pixels in the bitmap.
The file `limits.h` had definitions for x86. This PR removes these
definitions and fixes the upper limit for the type ssize_t which was
defined to be 0x7fffffff.
