We can now tell the difference between an own property access and a
subsequent (automatic) prototype chain access.
This will be used to implement caching of prototype chain accesses.
This was resulting in a whole lot of rebuilding whenever a new IDL
interface was added.
Instead, just directly include the prototype in every C++ file which
needs it. While we only really need a forward declaration in each cpp
file; including the full prototype header (which itself only includes
LibJS/Object.h, which is already transitively brought in by
PlatformObject) - it seems like a small price to pay compared to what
feels like a full rebuild of LibWeb whenever a new IDL file is added.
Given all of these includes are only needed for the ::initialize
method, there is probably a smart way of avoiding this problem
altogether. I've considered both using some macro trickery or generating
these functions somehow instead.
Before this change we were recording and executing sample/blit commands
for each painting phase, even if there are no painting commands
in-between sample and blit that produce result visible on a canvas.
This change adds an optimization pass that goes through recorded
painting commands list and marks sample and blit commands that could
be skipped.
Reduces sample and blit corners executing from 17% to 8% on Discord.
Fetched bodies can be on the order of gigabytes, so rather than crashing
when we hit OOM here, we can simply invoke the error callback with a DOM
exception. We use "UnknownError" here as the spec directly supports this
for OOM errors:
UnknownError: The operation failed for an unknown transient reason
(e.g. out of memory).
This is still an ad-hoc implementation. We should be using streams, and
we do have the AOs available to do so. But they need to be massaged to
be compatible with callers of Body::fully_read. And once we do use
streams, this function will become infallible - so making it infallible
here is at least a step in the right direction.
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! :^)
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.
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.
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 `->`.
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.
The HTMLLinkElement caller is a bit hairy, so we shove an await() in
there temporarily. This is sure to cause fun times for anyone debugging
task/microtask execution order.
We have to unregister link element stylesheets from the old document's
StyleSheetList when moving them into a new document.
This makes it possible to load GitHub contributor graphs. :^)
Capturing a struct that owns bunch of JS::Handle makes it very hard to
understand what keeps these handles alive in the GC-graph.
Instead let's capture only members of a struct used in the callback.
Changes the signature of queue_global_task() from AK:Function to
JS::HeapFunction to be more clear to the user of the function that this
is what it uses internally.
This refactor eliminates the need for a second "fd passing socket" on
Lagom, as it uses SCM_RIGHTS in the expected fashion, to send fds along
with the data of our Unix socket message.
Add factory functions to distinguish between when the owner of the File
wants to transfer ownership to the new IPC object (adopt) or to send a
copy of the same fd to the IPC peer (clone).
This behavior is more intuitive than the previous behavior. Previously,
an IPC::File would default to a shallow clone of the file descriptor,
only *actually* calling dup(2) for the fd when encoding or it into an
IPC MessageBuffer. Now the dup(2) for the fd is explicit in the clone_fd
factory function.
Navigation should not run for <object> element until it is inserted into
a document. Spec deoes not seem to explicitely say that, but that
matches other browsers behavior.
Fixes hanging after reloading in Acid3 test.
I haven't found this being mentioned in the current spec, but that is
what chromium (atm the only other Navigation API implementer) does.
Fixes crashing when location.hash is changed subsequently more than once
using JS.
Fixes bug when "navigate forward" button in UI is disabled after
performing following steps:
1. Load page with an iframe (top step = 0, iframe step = 0)
2. Navigate iframe to different document (top step = 0, iframe step = 1)
3. Navigate back from browser UI (top step = 0, iframe step = 0)
No test because change is only observable from browser UI.
