There is a difference in y offset position calculation for floats when
LineBuilder provides final y position while for blocks it needs to be
adjusted by `y_offset`. This difference already accounted in floating
box position calculation and this patch also makes it accounted in check
whether a floating boxes on the same line intersect between each other.
If valid grid-template-areas were given, then place grid items within
these areas. Grid-template-areas take precedence over named line
tracks, meaning if there are grid-areas as well as named tracks, should
use the grid-areas.
When starting the GridFormattingContext, calculate the valid grid areas
as declared in the `grid-template-areas` property. Since this doesn't
change, are able to do this once and store the results.
In some sections of the code, previously would use the values passed to
`grid-column-start`, `grid-row-end`, etc. literally. Since these values
start at grid-column 1 instead of 0 (as represented in most areas in
the code), this made the code unnecessarily complicated.
Now the values are zero-indexed from the getgo.
1. Don't use double_hash. This is not for doubles, as its name implies.
2. Specialize traits and formatters using the underlying DistinctNumeric
type of Web::DevicePixels and Web::CSSPixels.
The idea is that we'll have one type for each tag type.
For now, this treats all tag types as unknown, but it puts most
of the infrastructure for reading tags in place.
If a spec step hasn't been marked as fallible, but might throw due to
OOM, this is to make it clear that OOM is the only thing that may cause
a failure.
For now, this is limited to strings that are 3 bytes or less. We can use
7 bytes on 64-bit platforms, but we do not yet assume 64-bit for Lagom
hosts (e.g. wasm).
This happened because the reader was incrementing the byte index of it
after each read of a byte from the Span, so by the end of the frame
method, we could be at the end of the mapped file, so the next call
on the same decoder will just resume from that point and will be quickly
out of boundary.
To ensure this doesn't happen we only set the bitmap to m_context member
at the end of the method, and call to that method again will just give
the already-generated bitmap.
In case of setting the bitmap as volatile, we test for that case and
re-generate a reader to read the frame again correctly.
Change `compute_auto_height_for_block_level_element` to use max height
(`m_automatic_content_height` produced from TFC) for tables with auto
height which is more correct behaviour than treating them like block
containers.
When trying to figure out the correct implementation, we now have a very
strong distinction on plugins that are well suited for sniffing, and
plugins that need a MIME type to be chosen.
Instead of having multiple calls to non-static virtual sniff methods for
each Image decoding plugin, we have 2 static methods for each
implementation:
1. The sniff method, which in contrast to the old method, gets a
ReadonlyBytes parameter and ensures we can figure out the result
with zero heap allocations for most implementations.
2. The create method, which just creates a new instance so we don't
expose the constructor to everyone anymore.
In addition to that, we have a new virtual method called initialize,
which has a per-implementation initialization pattern to actually ensure
each implementation can construct a decoder object, and then have a
correct context being applied to it for the actual decoding.
Originally I simply thought that passing file paths is quite OK, but as
Linus pointed to, it turned out that passing file paths to ensure some
files are able to be decoded is awkward because it does not work with
images being served over HTTP.
Therefore, ideally we should just use the MIME type as an optional
argument to ensure that we can always fallback to use that in case
sniffing for the correct image type has failed so we can still detect
files like with the TGA format, which has no magic bytes.
Currently, if you have a fallible function with an Optional return type
and try to return OptionalNone like this:
ThrowCompletionOr<Optional<SomeType>> { return OptionalNone {}; }
Then ThrowCompletionOr's m_value (whose type is an Optional<ValueType>)
will be set to empty, rather than containing an empty Optional. This is
due to the ThrowCompletionOr's WrappedValueType constructor.
This patch adds a constructor specifically for OptionalNone. If someone
attempts to construct a ThrowCompletionOr with OptionalNone, but the
ValueType is not an Optional, a compile error like the following will
occur:
ThrowCompletionOr<String> foo() { return OptionalNone {}; }
error: no matching constructor for initialization of 'AK::String'
Otherwise, it will fill ThrowCompletionOr's m_value with an empty
Optional.
This might've been needed at some point to disambiguate between another
function of the same name that is in LibLocale. But now that it takes a
VM parameter, it is for sure clear to the compiler what is being called.
In order to prevent this commit from having to refactor almost all of
Intl, the goal here is to update the internal parsing/canonicalization
of locales within LibLocale only. Call sites which are already equiped
to handle String and OOM errors do so, however.
The macOS FileWatcher depends on macOS dispatch queues, which run on a
different thread than the Core::EventLoop. This implementation handles
filesystem events on its dispatch queue, then forwards the event back to
the main Core::EventLoop for notifying the FileWatcher owner.
