Introduced in 2c98eff, support for non-interleaved scans was not working
for frames with a number of MCU per line or column that is odd. Indeed,
the decoder assumed that they have scans that include a fabricated MCU
like scans with multiple components.
This patch makes the decoder handle images with a number of MCU per line
or column that is odd. To do so, as in the current decoder state we do
not know if components are interleaved at allocation time, we skip over
falsely-created macroblocks when filling them. As stated in 2c98eff,
this is probably not a good solution and a whole refactor will be
welcome.
It also comes with a test that open a square image with a side of 600px,
meaning 75 MCUs.
If the previous sibling of an out-of-flow box has been wrapped in an
anonymous block, we now stuff the out-of-flow box into the anonymous
block as well.
Co-authored-by: Aliaksandr Kalenik <kalenik.aliaksandr@gmail.com>
We were not testing this logic and I caused a regression while
modifying some of the hashing code, so let's add these. Note that I only
added two tests to test both 'families' of implementations for the SHA
hashes.
This builds on the existing ad-hoc ResourceLoader code for HTTP fetches
which works for files as well.
This also includes a test that checks that stylesheets loaded with the
"file" URL scheme actually work.
This would previously assert in InlineFormattingContext because we had
an outwardly inline box that wasn't inwardly flow.
Fix this by converting text-based input boxes to inline-blocks. This is
an ad-hoc solution, and there might be a much better way to solve it.
Before this change `apply_clip_overflow_rect` might crash trying to
access `clip_rect` that does not have value because we currently
support calculation of visible rectangle when `overflow: hidden`
is applied for both axis.
The deallocation of the test cases at the very end happens through a
NonnullRefPtr<TestCase>, meaning the deallocation will assume the wrong
object size and trip up ASAN. Therefore, we cannot use a TestCase
subclass.
I also took this opportunity and made use of the new LoaderError
formatter.
This fixes an issue where e.g `height: 100%` on a flex item whose
container has indefinite height was being resolved to 0. It now
correctly behaves the same as auto.
Previously, when having inline contexts consisting of just a `<br/>`
tag, we would not create a line box.
Ensure that there is always a line box when a line is explicitly being
broken and also ensure it won't be trimmed due to being empty.
This will a fix a number of sites that use `<br>` tags for layouts
between block elements (even though the spec says they shouldn't).
With Clang, the previous/next pointers in buckets of an
`OrderedHashTable` are not cleared when a bucket is being shifted up as
a result of a removed bucket. As a result, an unfortunate pointer mixup
could lead to an infinite loop in the `HashTable` iterator, which was
exposed in `HashMap::keys()`.
Co-authored-by: Luke Wilde <lukew@serenityos.org>
The image made the test flaky when running on my machine, so this
doesn't seem safe at the moment. We can just hardcode the dimensions.
Eventually we should make it possible to use external images in tests,
but for now let's not flake up the CI.
According to CSS Inline Layout Module Level 3 § 2.2 Step 1. atomic
inlines should be layed out in a line box based on their margin box.
However, up until this patch we were unconditionally considering only
the border box during line box height calculation. This made us
essentially drop all vertical margins for atomic inlines.
Similar to POSIX read, the basic read and write functions of AK::Stream
do not have a lower limit of how much data they read or write (apart
from "none at all").
Rename the functions to "read some [data]" and "write some [data]" (with
"data" being omitted, since everything here is reading and writing data)
to make them sufficiently distinct from the functions that ensure to
use the entire buffer (which should be the go-to function for most
usages).
No functional changes, just a lot of new FIXMEs.
Before, some loader plugins implemented their own buffering (FLAC&MP3),
some didn't require any (WAV), and some didn't buffer at all (QOA). This
meant that in practice, while you could load arbitrary amounts of
samples from some loader plugins, you couldn't do that with some others.
Also, it was ill-defined how many samples you would actually get back
from a get_more_samples call.
This commit fixes that by introducing a layer of abstraction between the
loader and its plugins (because that's the whole point of having the
extra class!). The plugins now only implement a load_chunks() function,
which is much simpler to implement and allows plugins to play fast and
loose with what they actually return. Basically, they can return many
chunks of samples, where one chunk is simply a convenient block of
samples to load. In fact, some loaders such as FLAC and QOA have
separate internal functions for loading exactly one chunk. The loaders
*should* load as many chunks as necessary for the sample count to be
reached or surpassed (the latter simplifies loading loops in the
implementations, since you don't need to know how large your next chunk
is going to be; a problem for e.g. FLAC). If a plugin has no problems
returning data of arbitrary size (currently WAV), it can return a single
chunk that exactly (or roughly) matches the requested sample count. If a
plugin is at the stream end, it can also return less samples than was
requested! The loader can handle all of these cases and may call into
load_chunk multiple times. If the plugin returns an empty chunk list (or
only empty chunks; again, they can play fast and loose), the loader
takes that as a stream end signal. Otherwise, the loader will always
return exactly as many samples as the user requested. Buffering is
handled by the loader, allowing any underlying plugin to deal with any
weird sample count requirement the user throws at it (looking at you,
SoundPlayer!).
This (not accidentally!) makes QOA work in SoundPlayer.
Percentage line-height values are relative to 1em (i.e the font-size
of the element). We have to resolve their computed values before
proceeding with inheritance.
If normal flow layout has caused us to progress past the current
innermost float in the block axis, we still need to consider the floats
stacked outside of it.
Fix this by always walking the currently stacked floats from innermost
to outermost when placing new floats.
When using the flex shrink factor, the flexible length resolution
algorithm was incorrectly ignoring the `frozen` flag on items and would
update the same items again, causing overconsumption of the remaining
free space on the flex line.
In case flex items had `margin: auto` on the primary flex axis, we were
still also distributing remaining space according to `justify-content`
rules. This lead to duplicated spacing in various places and overflows.
It looks like this issue was observed previously but missidentified
because there was logic to ignore margins at the start and end which
would partially paper over the root cause. However this created other
bugs (like for example not having a margin at beginning and end ;-)) and
I can find nothing in the spec or other browser behaviour that indicates
that this is something that should be done.
Now we skip justify-content space distribution alltogether if it has
already been distributed to auto margins.
The draft CSS-FLEXBOX-1 spec had a more detailed description of this
algorithm, so let's use that as our basis for the implementation.
Test by Aliaksandr. :^)
When resolving these constraints to CSS pixel sizes, we have to resolve
padding-top and padding-bottom against the flex container's *width*,
not its height.
The padding-top and padding-bottom properties are relative to the
*width* of the containing block, not the height.
It's funny how we keep making this same mistake again and again. :^)
