Remove 11 heavy includes from Document.h that were only needed for
pointer/reference types (already forward-declared in Forward.h), and
extract the nested ViewportClient interface to a standalone header.
This reduces Document.h's recompilation cascade from ~1228 files to
~717 files (42% reduction). Headers like BrowsingContext.h that were
previously transitively included see even larger improvements (from
~1228 down to ~73 dependents).
A version of this was added in a610639119
and reverted in 70671b4c11. The bugs
there (confusing scroll-to-position and scroll-by-delta, and not having
an execution context in some cases) have been fixed in this version.
A lot of our scrolling code is quite old, and doesn't match the spec,
but does use some similar names. This is quite confusing. In particular
`perform_scroll_of_viewport()` is not the same as the spec algorithm.
That algorithm is actually almost implemented in
`scroll_viewport_by_delta()`.
To clarify things, this commit makes a few changes:
- Rename perform_scroll_of_viewport() to
perform_scroll_of_viewport_scrolling_box(). This is a better match
for how we use this method, even if it's not actually a match for the
algorithm. (:yakbait:)
- Move `scroll_viewport_by_delta()`'s code into a new
`perform_a_scroll_of_the_viewport()` method, and make it take a
position like it should. `scroll_viewport_by_delta()` now calls it
with a calculated position.
I've avoided reusing the original `perform_scroll_of_viewport()` name to
avoid accidents.
This was causing GC-related crashes on various websites, most
prominently on any site that contains embedded YouTube videos. The issue
can be reproduced by going to any YouTube video, using the _Share_
button below it and pasting the embed code into an empty HTML file and
loading it through localhost.
This is technically a regression from
89dbdd3411 in that the problem became
visible with that commit. However, there is nothing wrong with the
commit by itself. It just happens that `Origin::is_same_origin_domain()`
prior to that commit was completely bogus and would mistakenly return
true in almost all cases, so the cross-origin code paths were not
exercised.
I am uncertain how to make a automatic test case for this problem, given
the nature of it being GC- and cross-origin-related. So there is no
regression test included in this commit.
This makes it so that view-transition pseudo-element styles are
updated before returning them from window.getComputedStyle(). This
is necessary because they could be outdated, in case JS has
modified the styles of the elements they are trying to stay in sync
with since last frame.
The corresponding WPT test has not been imported, since it still
fails for unrelated reasons.
This has quite a lot of fall out. But the majority of it is just type or
UDL substitution, where the changes just fall through to other function
calls.
By changing property key storage to UTF-16, the main affected areas are:
* NativeFunction names must now be UTF-16
* Bytecode identifiers must now be UTF-16
* Module/binding names must now be UTF-16
The storage type was being incorrectly set to Session instead of Local,
apparently because of copying the implementation from
`Window::session_storage()`.
Bug introduced in commit 2066ed2318
This change follows the pattern of our cookies persistence
implementation: the "browser" process is responsible for interacting
with the sqlite database, and WebContent communicates all storage
operations via IPC.
The new database table uses (storage_endpoint, storage_key, bottle_key)
as the primary key. This design follows concepts from the
https://storage.spec.whatwg.org/ and is intended to support reuse of the
persistence layer for other APIs (e.g., CacheStorage, IndexedDB). For
now, `storage_endpoint` is always "localStorage", `storage_key` is the
website's origin, and `bottle_key` is the name of the localStorage key.
In upcoming changes StorageBottle will own pointers to GC-allocated
objects, so it needs to be a GC-allocated object itself to avoid
introducing more GC roots.
Despite what the spec suggests, modern displays are not progressive, and
WPT expects `@media (scan: progressive)` to fail. So, return `none`
here to accurately represent that.
I've left a FIXME in case we can detect the display type from the OS
somehow in the future.
Gets us 4 WPT subtest passes.
For unscrolled viewports (already at 0, 0), we can short-circuit here
and avoid doing a synchronous relayout of the page.
This avoids a bunch of synchronous layouts on Speedometer3's NewsSite
(Nuxt version) subtests.
Corresponds to 03ab71775b
I've also split the `Document::has_focus()` method for clarity. Actually
implementing the "has focus steps" turns out to be quite involved so
I've left it for now.
These callbacks are evaluated synchronously via JS::Call. We do not need
to construct an expensive RootVector container just to immediately
invoke the callbacks.
Stylistically, this also helps indicate where the actual arguments start
at the call sites, by wrapping the arguments in braces.
This fixes the frame-ancestors WPT tests from crashing when an iframe
is blocked from loading. This is because it would get an undefined
location.href from the cross-origin iframe, which causes a crash as it
expects it to be there.
This adds a basic settings page to manage persistent Ladybird settings.
As a first pass, this exposes settings for the new tab page URL and the
default search engine.
The way the search engine option works is that once search is enabled,
the user must choose their default search engine; we do not apply any
default automatically. Search remains disabled until this is done.
There are a couple of improvements that we should make here:
* Settings changes are not broadcasted to all open about:settings pages.
So if two instances are open, and the user changes the search engine
in one instance, the other instance will have a stale UI.
* Adding an IPC per setting is going to get annoying. It would be nice
if we can come up with a smaller set of IPCs to send only the relevant
changed settings.
The intent is that this will replace the separate Task Manager window.
This will allow us to more easily add features such as actual process
management, better rendering of the process table, etc. Included in this
page is the ability to sort table rows.
This also lays the ground work for more internal `about` pages, such as
about:config.
