When the grid layout gets to
`resolve_items_box_metrics(GridDimension::Column)`, we've already
determined the width of each column. However, the widths of the
individual grid items themselves haven't been set. Rather than using
`get_available_space_for_item()`, which returns an indefinite size if
an item's width/height hasn't been set, we should use the already
known track width as the available size to calculate the fit-content
width.
We can just create a `BigEndianInputBitStream` where it is needed
instead of storing one in the class. After making `read_header()`
static, the only other user of the field was `read_size_information()`,
so let's do that there and then remove the field.
This makes the checks for a frame header more consistent, so if the
conditions for allowed frame headers change, there are less scattered
lines that will need to be changed.
`synchronize()` will now also properly scan the second byte of the hex
sequence `FF FF F0` as a sync code, where previously it would see
`FF F` and skip on to `F0`, ignoring its preceding `FF` that would
indicate that it is a sync code.
`synchronize()` can be simplified greatly by checking whole bytes with
bitwise operations, and doing so also avoids the overhead of reading
individual bits from a bitstream.
Making `read_frame()` also take a `SeekableStream` will allow it to be
used inside `synchronize()` in the next commit.
Prevously, the header size was used to calculate the `slot_count` field
of `MP3::Header`, but `build_seek_table()` just used the maximum size
of the header instead, causing it not to seek far enough, and in cases
where a possible sync code occurred two bytes before the next frame, it
would read that possible sync code as if it was a real frame. It would
then either reject it due to bad field values, or could possibly skip
over the next real frame due to a larger calculated frame size in the
bogus frame.
By fixing this issue, we now properly calculate the duration of MP3
files where these fake sync codes occur. In the case of the raw file
for this podcast:
https://changelog.com/podcast/554
the duration goes from 1:21:57 to 1:22:47, which is the real duration
according to the player user interface.
The seek table must locate the first MP3 frame in the file, so it makes
sense to locate the samples for the sample table first, then that
information to seek to the first frame.
Previously, we would just start from byte 0 and check individual bytes
of the file until we find two bytes starting with `FF F`, and then
assume that that was the MP3 frame sync code. However, some ID3v2 tags
do not have to be what is referred to as "unsynchronized", meaning that
they can contain that `FF F` sequence and cause our decoder to think it
has found a frame.
To avoid this happening, we can read a minimal amount of the ID3 header
to determine how many bytes to skip before attempting to find the MP3
frames.
This allows the recent podcast with Andreas to play here:
https://changelog.com/podcast/554
Seek points were being created after adding to the sample count in
`build_seek_table()`, meaning that they would be offset forward by
`MP3::frame_size` samples.
This also allows us to remove the hardcoded sample 0 seek point that
was previously added, since a seek point at sample 0 will now be added
by the loop.
This is intended to annotate conversions from unknown floating-point
values to CSSPixels, and make it more obvious the fp value will be
rounded to the nearest fixed-point value.
In general it is not safe to convert any arbitrary floating-point value
to CSSPixels. CSSPixels has a resolution of 0.015625, which for small
values (e.g. scale factors between 0 and 1), can produce bad results
if converted to CSSPixels then scaled back up. In the worst case values
can underflow to zero and produce incorrect results.
Move the methods to set the native/user style sheets to the base
ViewImplementation class. We must also generate the native style sheet
explicitly for now, as LibWebView on Lagom isn't able to include the
main LibWebView CMakeLists.txt file yet.
This means StyleComputer::resolve_unresolved_style_value() always
returns a value, so we can change its return type.
However, it does still return an UnresolvedStyleValue sometimes, so we
can't remove those checks from the user code.
These options are not relevant and are actually meaningless on pure TTY
devices, as they are meant to be effective only for the VirtualConsole
devices.
This also removes the virtual marking from two methods because they're
no longer declared in the TTY class as well.
There is a bug in the "search by typing" feature of
AbstractView, where the highlighted text shown in items' title won't
match the search query if the search query contains whitespace.
This commit fixes that bug.
The bug is caused by a bad assumption made in
AbstractView::draw_item_text about the Painter::draw_text API.
Specifically that the function passed to it will be called for each
code point of the string instead of for each drawable glyph.
This is fixed by not relying on looking at the length of the highlight
string, but instead looking at its content.
This function returns the first element which matches both the filter
for the LiveNodeList collection itself, and a further filter that is
supplied as an argument to this function.
- Ambiguous `raw_value()` method is replaced with `line_number()` and
`span()`.
- `line_name()` that before returned either line name or area name is
replaced with `line_name()` and `area_name()`.
- `Position` type is replaced with `Line` and `Area` type so we don't
have to guess while doing layout.
Affected test expectations:
- `template-lines-and-areas` - improvement over what we had before.
- `named-tracks` - rebaseline a giant test. will have to split it into
smaller tests in the future.
The invariants for these property getters are supposed to be checked by
the has_entries_and_events_disabled AO, but we don't have all the
plumbing hooked up between Navigables and Navigation yet.
Add a test to make sure that these methods don't assert when calling
them on a fresh page.
The spec allows for these either to be based on the OS, or to be defined
by the browser. Looking at the other browser engines, there's a mix of
the two options. Since we've had issues with using OS colors as
defaults, let's use hard-coded colors for now. Some of these are based
on the definitions in
https://html.spec.whatwg.org/multipage/rendering.html
