For some reason we were not considering the last *two* characters from
the line's ByteBuffer, with the comment next to it talking about \n and
\0. However the buffer doesn't contain a null-byte, so we were
effectively removing the newline and the last character from each
history line!
When create_with_shared_buffer() is called in the next line, the
RefPtr::operator* asserts that the RefPtr is not null. That can happen when
we're low-ish on memory, and the image is huge.
I don't know why basing the available space between floats on the y
coordinate in the middle of each line seemed like a good idea. It just
creates situations with a few pixels of floats overlapping text!
I'm not sure what this was trying to achieve, but it was moving all
line fragments upwards and a lot of things look a lot better if we
just stop doing that.
I had guessed that floating boxes should somehow be hoisted up to the
nearest block ancestor that creates a block formatting context, but
that's just wrong. They move up to the nearest block ancestor like any
other box that's not absolutely (or fixed) positioned. :^)
Boxes can now be floated left or right, which makes text within the
same block formatting context flow around them.
We were creating way too many block formatting contexts. As it turns
out, we don't need one for every new block, but rather there's a set
of rules that determines whether a given block creates a new block
formatting context.
Each BFC keeps track of the floating boxes within it, and IFC's can
then query it to find the available space for line boxes.
There's a huge hack in here where we assume all lines are the exact
line-height. Making this work with vertically non-uniform lines will
require some architectural changes.
We now lazily create an "arguments" array inside functions when code
tries to access it.
This doesn't follow the spec at all but still covers a lot of the
basic uses of arguments, i.e "arguments.length" and "arguments[n]"
Here's a reasonably faithful implementation of ECMAScript 2021 18.2.5.
Some corner cases are not covered, I've left them as FIXME's in the
included unit test.
Also I had to tweak JS::Value::to_i32() to always convert infinity to
zero, which is in accordance with ToInt32 AFAICT.
We were not accounting for space occupied by borders when computing
the vertical (y) position of blocks. This meant that blocks with wide
top/bottom borders could bleed into each other incorrectly.
Fix this by using the combined padding+border geometry instead of just
the padding when placing blocks on the y axis.
We were incorrectly resolving relative length units (ex, em, etc.)
against the containing block in many cases. Fix this to resolve them
against the descendant box we're currently processing.
Instead of doing a CSS property lookup for the line style of each
border edge during paint, we now cache the final CSS::LineStyle to use
in the Layout::BorderData.
TerminalWidget will now automatically scroll up or down when the user
drags the mouse out of its bounds while selecting text. This happens
at a fixed speed.
In order for inline elements (e.g <span>) to contribute padding etc.
to line boxes, we now create special "leading" and "trailing" fragments
for Layout::InlineNode and size them according to the horizontal
padding values.
The height of these fragments is taken from the tallest fragment on the
line. (Perhaps we should stop having per-fragment heights and just keep
a single height per line box, but that's a separate issue.)
In order to make things look nice, we now also adjust the height of all
fragments on a line so that nobody is shorter than the CSS line-height.
Fragment painting was very limited by only being called during the
foreground paint phase. We now paint fragments as part of every phase
(and the phase is passed to paint_fragment() of course!)
We were rejecting perfectly valid z-index values like '1000' since we
were passing all CSS values through the length parser and unit-less
lengths are not valid in this context.
It's yet another hack for the ad-hoc CSS parser (its days are numbered)
but this makes the top header links on google.com actually work. :^)
Calling Frame::set_size() already triggered a relayout, so calling
layout() again right after meant we did all the work one more time.
Not being dumb like this makes resizing significantly smoother. :^)
Layout was using an outdated viewport rect that we set *after* doing
a layout due to resize. That meant that layout-in-response-to-resize
was always lagging behind the current size of the view.
The root of this problem was how Frame kept both a viewport rect
(with both scroll offset and size) and a frame size. To fix this,
only store the viewport scroll offset, and always use the frame size.
This way they can't get out of sync and the problem goes away. :^)
Fixes#4250.
This is how the spec describes it, and it allows sharing data between
multiple typed arrays.
Typed arrays now support constructing from an existing ArrayBuffer,
and has been prepared for constructing from another typed array or
iterator as well.
We should pay more attention to using the well-defined abstract
operations from the spec rather than making up our own, often slightly
different rules. This is another step in that direction.
We have multiple array types now, so ArrayInvalidLength has been
replaced with a generic InvalidLength.
Also fixes a small issue in the Array constructor, it should throw
RangeError for invalid lengths, not TypeError.
Previously, in the case of RLE4, parsing took suspiciously long.
What happened was that 'pixel_count' was 255, and 'i' was incremented
by *two* in each iteration, so the for-loop continued until the
entire output buffer was full, and then rejected the RLE data
as bogus.
This little diff allows pixel_count to reach 256, be greater than
pixel_count, and thus terminate the loop in the intended way.
The Audio::Loader class is able to load different types of audio files
by using a generic plugin interface for all file formats. Every new
loader will have to derive from Audio::LoaderPlugin to provide a common
API.
This makes it easy to add support for more audio file formats in the future.
We need to call waitpid until no more waitable children are available.
This is necessary because SIGCHLD signals may coalesce into one when
multiple children terminate almost simultaneously.
Also, switch to EventLoop's asynchronous signal handling mechanism,
which allows more complex operations in the signal handler.
