Before we used the value of days which may also contain a fraction.
The algorithm expects it to be an integer.
This was addressed upstream in: tc39/proposal-temporal@02379da
This starts moving code equally shared between the OOPWV and Ladybird
WebContentView implementations to WebView::ViewImplementation, beginning
with the client state.
On many keyboards, Ctrl++ is actually Ctrl+Shift+=, and Ctrl+= makes
more sense as it's symmetric with Ctrl+-.
Both Firefox and Chrome already support this alternate shortcut,
so let's be nice and support it in Ladybird as well. :^)
Before this patch, we were expressing the current selection as a range
between two points in the layout tree. This was a made-up concept I
called LayoutRange (2x LayoutPosition) and as it turns out, we don't
actually need it!
Instead, we can just use the Selection API from the Selection API spec.
This API expresses selection in terms of the DOM, and we already had
many of the building blocks implemented.
To ensure that selections get visually updated when the underlying Range
of an active Selection is programmatically manipulated, Range now has
an "associated Selection". If a range is updated while associated with
a selection, we recompute layout tree selection states and repaint the
page to make it user-visible.
Instead of sifting through the layout tree to extract the selected text,
look at the DOM selection instead.
Note that we can't just stringify the DOM Range, as that would include
non-visible things (like the content of <style> elements, etc.) so we
run it through an ad-hoc variant of the range stringification algorithm.
This can probably be factored better, but it's a start. :^)
If we failed to decode a sample we'd presumably want to tell the user,
and we definitely don't want to just go into another round of decoding
somewhere in the middle of a broken sample.
Especially if buffered streams are involved, not filling the span
completely can also mean that we just ran out of filled buffer space and
we need to refill it on the beginning of the next read call.
This utility when given a .tff font provides options for disassembling:
- The 'fpgm' table, this a program that's run once when the font is
loaded. It's used to define instructions and functions used by used
by other programs.
- The 'prep' table, this is a general program that's run when ever
the font size (or other properties) changes.
- And the programs associated with any individual glyph.
The disassembly is printed in a format that matches the examples from:
https://learn.microsoft.com/en-us/typography/opentype/spec/tt_instructions
I'm mainly adding this because I think it's neat to be able to look
at these things, and think it'll be helpful for debugging an
interpreter.
With this you can see that all of the LiberationSerif-XXX.tff fonts in
Serenity have these programs ready to go.
This defines all the OpenType opcodes/instructions from the
specification:
https://learn.microsoft.com/en-us/typography/opentype/spec/tt_instructions
Each instructions has mnemonic and a range of possible opcodes (as some
of the bits are pretty much immediate value flags).
There's a little helper Instruction struct for accessing the flags and
any associated data (in the case of PUSH instructions).
Then the InstructionStream provides a way of iterating over all the
instructions in some bytes.
This was unintuitive, and only useful in a few cases. In the majority,
users had to immediately call `stop()`, and several who did want the
timer started would call `start()` on it immediately anyway. Case in
point: There are only two places I had to add a manual `start()`.
