We would previously always generate string parameters to pass through
to functions as a `String`. This works fine if the argument is a
`FlyString const&`, but falls apart for optional types where we need to
accept an `Optional<FlyString> const&`.
Support this by implementing a [FlyString] extended attribute which
if present results in the parameter for the function being generated
as a FlyString.
We cannot port over Optional<FlyString> until the IDL generator supports
passing that through as an argument (as opposed to an Optional<String>).
Change to FlyString where possible, and resolve any fallout as a result.
Other readers do this too, and files depend on this.
Fixes opening these four files from the PDFA 0000.zip dataset:
* 0000015.pdf
Starts with `C:\web\webeuncet\_cat\_docs\_publics\` before header
* 0000408.pdf
Starts with UTF-8 BOM
* 0000524.pdf
Starts with 867 bytes of HTML containing a PHP backtrace
* 0000680.pdf
Starts with `C:\web\webeuncet\_cat\_docs\_publics\` too
A local (non-public) PDF I have lying around contains this in
a page's operator stream:
```
[<00b4003e> 3 <002600480051> 3 <005700550044004f0003> -29
<00330044> 3 <0055> -3 <004e0040> 4 <0003> -29 <004c00560003> -31
<0057004b> 4 <00480003> -37 <0050
>] TJ
```
That is, there's a newline in a hexstring after a character.
This led to `Parser error at offset 5184: Unexpected character`.
The spec says in 3.2.3 String Objects, Hexadecimal Strings:
"""Each pair of hexadecimal digits defines one byte of the string.
White-space characters (such as space, tab, carriage return, line feed,
and form feed) are ignored."""
But we didn't ignore whitespace before or after a character, only
in between the bytes.
The spec also says:
"""If the final digit of a hexadecimal string is missing—that is, if
there is an odd number of digits—the final digit is assumed to be 0."""
In that case, we were skipping the closing `>` twice -- or, more
accurately, we ignored the character after it too. This has been
wrong all the way back in #6974.
Add a test that fails if either of the two changes isn't present.
In the UI process, we encode generated HTML as Base64 to avoid having to
deal with things like arbitrarily nested quotes. The HTML is encoded as
UTF-8, and the raw bytes of that encoding are transcoded to Base64.
In the Inspector process, we are decoding the Base64 string using atob,
which has awkward non-Unicode limitations. The resulting string is only
a byte string. We must further decode the bytes as UTF-8, which we do
using TextDecoder.
Instead of implementing stacking context painting order exactly as it
is defined in CSS2.2 "Appendix E. Elaborate description of Stacking
Contexts" we need to account for changes in the latest standards where
a box can establish a stacking context without being positioned, for
example, by having an opacity different from 1.
Fixes https://github.com/SerenityOS/serenity/issues/21137
With this, it's possible to build Ladybird without having Qt installed.
(Previously, the build required `moc` to exist.)
In fact, it's possible to build Ladybird without anything off `brew`
as long as you have `ninja` and `gn` (both of which don't have any
dependencies themselves and are easy to build).
This change fixes the initial tool selection when pixelpaint is started
with a path. Previously an already existing editor was expected when
the default tool was initially propagated - which was not the case if
pixelpaint was launched to directly load an existing image.
The JS::Value being passed through is not a bigint, and needs to be
converted using ConvertToInt, as per:
https://webidl.spec.whatwg.org/#es-unsigned-long-long
Furthermore, the IDL definition also specifies that this is associated
with the [EnforceRange] extended attribute.
This makes it actually possible to pass through an autoAllocateChunkSize
to the ReadableStream constructor without it throwing a TypeError.
This is how the spec tells us we should be converting to these integer
types.
Also leave around a FIXME to pass through information about the [Clamp]
and [EnforceRange] extended attributes, and port over these instances to
the new WebIDL integer typedefs.
JS::modulo was yielding a result of '0' for the input:
```
modulo(1., 18446744073709551616.)
```
Instead of the expected '1'.
As far as I can tell the reason for this is that the repeated calls to
fmod is losing precision in the calculation, leading to the wrong
result. Fix this by only calling fmod once, and preserving the negative
value behaviour by an 'if' check.
Without this, the LibWeb text test:
`/Streams/ReadableByteStream-enqueue-respond.html`
Would hang forever after using this function in the IDL conversion of a
u64 in ConvertToInt.
This should also be more efficient :^)
These IPCs are different than other IPCs in that we can't just set up a
callback function to be invoked when WebContent sends us the screenshot
data. There are multiple places that would set that callback, and they
would step on each other's toes.
Instead, the screenshot APIs on ViewImplementation now return a Promise
which callers can interact with to receive the screenshot (or an error).
This overload is currently unused. When used, it doesn't compile due to
mismatched return types in the handler provided to the function and the
type of `on_resolution`.
Some servers decide to add newlines (and not \r\n) into that field, this
commit makes us tolerate that and not crash in cases like in #22463.
Fixes#22463.
Instead of returning HeapBlock memory to the kernel (or a non-type
specific shared cache), we now keep a BlockAllocator per CellAllocator
and implement "deallocation" by basically informing the kernel that we
don't need the physical memory right now.
This is done with MADV_FREE or MADV_DONTNEED if available, but for other
platforms (including SerenityOS) we munmap and then re-mmap the memory
to achieve the same effect. It's definitely clunky, so I've added a
FIXME about implementing the madvise options on SerenityOS too.
The important outcome of this change is that GC types that use a
type-specific allocator become immune to use-after-free type confusion
attacks, since their virtual addresses will only ever be re-used for
the same exact type again and again.
Fixes#22274
In XYZ space, gray doesn't have three equal values. Instead, it is
a line through the whitepoint.
(Multiplying by the whitepoint has the same effect as multiplying
the sRGB matrix with a (g, g, g) vector, since the numbers on
the matrix's rows add up to the whitepoint.)
Fixes the very slight red tint on all the figures in chapter 4
of the PDF 1.7 spec.
RISC-V uses a different convention for storing stack frame information
described here: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-cc.adoc#frame-pointer-convention
This part of the psABI is not yet in a ratified version, but both GCC
and Clang seem to use this convention.
Note that the backtrace dumping code still won't work for the initial
stack, as it is located before `kernel_mapping_base`.
