This change moves WebAssembly related data that was previously globally
accessible into the `WebAssemblyCache` object and creates one of these
per global object. This ensures that WebAssembly data cannot be
accessed across realms.
Previously we would look for a matching ID, and then for a matching
name. If there was an element in the collection which had a matching ID
as well as an element with a matching name, we would always return the
element with a matching ID irrespective of what order that element was
in.
Link elements that aren't "browsing-context connected" should not
trigger a resource fetch when their attributes change.
This fixes an issue where we'd waste time by loading every style sheet
twice! :^)
We were reading the value instead of setting it (as required by the
specification). This worked only when we booted with a bootloader which
initialized NVMe before us.
The default type for integer literals is signed int, so we were
accidentally smearing those bits to the upper 32 bit of the result.
This resulted in extremely unreasonable timeouts.
We were accidentally doing a 16-bit read instead of an 8-bit read,
meaning we would also read the 'CACHE_LINE_SIZE' field immediately
following it, and never actually continue.
Otherwise, the thread will continue to run and access the media data
buffer, which will have been freed.
The test here is a bit strange, but the issue would only consistently
repro after several GC runs.
This really only affects headless-browser when it is linked with Qt. In
that case, it currently uses Qt networking by default and does not have
a flag to use RequestServer instead. Change the default to use RS so it
can undergo sanitized testing in CI.
The spec doesn't tell us the exact value to use, but a minumum & maximum
range of supported values. Just to be consistent with another browser,
we follow the values that firefox appears to support from testing the
interface on my machine.
This function will be used in the AudioBuffer constructor, but is
defined in the spec as part of BaseAudioContext.
Fixes crashing after following steps:
1. Open https://github.com/SerenityOS/serenity
2. Click on "Pull requests" tab
The problem was `navigable` null pointer dereferencing in
`decode_favicon()`. But navigable is null because the document was
created by `parseFromString()` DOMParser API.
With this change we skip fetching initiated by HTMLLinkElement if
document does not have a browsing context:
- Favicon is not displayed for such documents so no need to fetch.
- Stylesheets fetching won't affect such document because style or
layout does not run for them.
This largely adapts the code from SingletonProcess.cpp to work a bit
closer with Core::Process. Ideally, we'll move the daemonizing feature
into Core::Process::disown() eventually.
We implement the move constructor already. A future commit will have
code of the form:
process = move(other_process);
which there is no reason to forbid.
The following command was used to clang-format these files:
clang-format-18 -i $(find . \
-not \( -path "./\.*" -prune \) \
-not \( -path "./Base/*" -prune \) \
-not \( -path "./Build/*" -prune \) \
-not \( -path "./Toolchain/*" -prune \) \
-not \( -path "./Ports/*" -prune \) \
-type f -name "*.cpp" -o -name "*.mm" -o -name "*.h")
There are a couple of weird cases where clang-format now thinks that a
pointer access in an initializer list, e.g. `m_member(ptr->foo)`, is a
lambda return statement, and it puts spaces around the `->`.
Currently, if the prebuilt toolchain cache gets used, we will not try to
build the toolchain. Thus, the toolchain's ccache does not get used, and
is then pruned entirely at the end of the run.
So for now, let's just not prune the toolchain ccache. After a few years
it only reached 0.8 GB in size. And now that we are starting from empty
again, it would likely be a few more years before we reach 0.8 GB again.
The only subclass was already GC-allocated, so let's hoist the JS::Cell
inheritance up one level. This ends up simplifying a bit of rather
dubious looking code where we were previously slicing ESOs.
