Turns out compute_position should be invoked before placing the element
in normal flow. Otherwise, the position isn't set on the first layout.
The effect was that the block would "jump" into place on a secondary
layout.
This is a follow-up to commit:
deda7c8995
1. Allow Value(size_t) and use it for array length properties.
If an array length can't fit in an Int32 value, we shouldn't go out of
or way to force it into one. Instead, for values above INT32_MAX,
we simply store them as Double values.
2. Switch to generic indexed property storage for large arrays.
Previously we would always allocate array storage eagerly when the
length property was set. This meant that "a.length = 0x80000000" would
trivially DOS the engine on 32-bit since we don't have that much VM.
We now switch to generic storage when changing the length moves us over
the 4M entry mark.
Fixes#5986.
Previously, when jumping to the next word on the last column of a line,
or when jumping to the previous word on the first column, it would
crash. This checks if that is the case, and if so, will do nothing.
This prevents the undefined behaviour that would come up as a result of
doing so. (For example: opening "infinite" devices like /dev/full will
result in an infinite loop until exhaustion of memory)
And overhaul resize and paint events to fix layout edge cases in
which Calendar wasn't filling its parent widget completely. Ensures
month views always display prior month days for click navigation.
Converts Calendar app layout to GML.
Section 10.3 "Calculating widths and margins" indicates that the 'left'
and 'right' properties of relatively positioned elements should be set
in accordance with the rules of section 9.4.3.
This is particularly useful when wanting to open files in ~/.config
from the Text Editor. The option is currently not persistent, but could
be hooked into File Manager's configuration.
While iterating the items contained by the rubberband we need to skip
the correct number of items either vertically or horizontally, depending
on which direction the items flow.
Fixes#5993
Most coredumps contain large amounts of consecutive null bytes and as
such are a prime candidate for compression.
This commit makes CrashDaemon compress files once the kernel finishes
emitting them, as well as adds the functionality needed in LibCoreDump
to then parse them.
PNGs use deflate with zlib, however we were just skipping the zlib
bytes and then piping it into deflate decompressor. Since we have a
zlib decompressor, lets use that instead.
This has the added benefit of extra error checking.
These simply use StringBuilder::appendvf() internally which is not
optimal in terms of heap allocations, but simple enough and I don't
think they are performance sensitive functions anyway.
Since the central directory offset in the end of central directory
record and the local file offset in each central directory header
are user-controlled arbitary data, we have to bounds check them
before using them.
We now also check we have enough space in the incoming buffer for the
various signatures and optional (length specified) fields. This helps
prevents a possible heap overflow read.
Because it's what it really is. A frame is composed of 1 or more samples, in
the case of SerenityOS 2 (stereo). This will make it less confusing for
future mantainability.
Just a sanity check, this must never happen. Manual invocations of
call() e.g. in LibWeb bindings must pass js_undefined() if no specific
this value is desired, which OrdinaryCallBindThis will then use as-is or
turn into the global this value in non-strict mode.
Section 10.6.4 rule 5 of the CSS height property spec outlines a method
to compute the height of an absolutely positioned block when the 'top'
and 'bottom' CSS properties are specified.
The case for computing auto-height of block elements which have block-
level children was erroneously skipping some children:
1. If the block element itself is absolute or floating, all children
were skipped due to a likely typo ("box" vs. "child_box" inside the
for-each loop).
2. Floating children should only be skipped if the block element's
'overflow' property computes to 'visible', per section 10.6.3 of the
CSS height property spec. If the property computes to another value,
section 10.6.7 only indicates that absolutely positioned children
should be skipped.
In single process mode, the browser will display a page's favicon in
both the location bar and tab. This adds the same support for multi-
process mode.
This leaves menu applets running but invisible, and that's a regression
we need to take care of obviously. But not today, because it's getting
too late.
