Because of the previous awkward factoring of Origin we had two
implementations of Origin serializing and creation. Move the
implementation of DOMURL::url_origin into URL::origin, and
instead use the implemenation of URL::Origin::serialize for
serialization (replacing URL::serialize_origin).
This happens to fix 8 URL subtests as the two implemenations had
diverged, and URL::serialize_origin was previously missing the spec
changes of: whatwg/url@eee49fd and whatwg/url@fff33c3
(cherry picked from commit 501f92b54eee7bcf7b60621aa4238fcbdc610d99;
amended to add leading whitespace to expectation due to serenity not
yet having LadybirdBrowser/ladybird#1603)
This closer matches specification - and removes any dependency on
LibWeb in the implementation of DOMURL::url_origin.
It is also one step closer to moving BlobURLRegistry to a singleton
process to match LibWeb's multiprocess Worker architecture.
(cherry picked from commit 12ea470417e837c9c7456ecc1cc81b0294a2d3bb)
While Origin is defined in the HTML spec - this leaves us with quite an
awkward relationship as the URL spec makes use of AO's from what is
defined in the HTML spec.
To simplify this factoring, relocate Origin into LibURL.
(cherry picked from commit dc401f49ea7e861064484e79594e35c3d93000ae;
amended to fix minor conflicts due to serenity not (yet?) having a
LibUnicode/Segmenter.h include in Document.cpp, and due to
BrowsingContext already having LadybirdBrowser/ladybird#2358 in
serenity)
Web specs do not return through javascript percent decoded URL path
components - but we were doing this in a number of places due to the
default behaviour of URL::serialize_path.
Since percent encoded URL paths may not contain valid UTF-8 - this was
resulting in us crashing in these places.
For example - on an HTMLAnchorElement when retrieving the pathname for
the URL of:
http://ladybird.org/foo%C2%91%91
To fix this make the URL class only return the percent encoded
serialized path, matching the URL spec. When the decoded path is
required instead explicitly call URL::percent_decode.
This fixes a crash running WPT URL tests for the anchor element on:
https://wpt.live/url/a-element.html
(cherry picked from commit cc557323326ba55514ef2a8a6e0efd7f09330f06;
amended heavily to call `URL::percent_decode()` on all results of
`url.serialize_path()` in the rest of serenity -- except in
LibGemini, where it looked incorrect, and in LibHTTP, where
LadybirdBrowser/ladybird#983 will add it.)
We were previously sorting using code points which could give the wrong
result for certain inputs.
Fixes the last two failing tests on:
https://wpt.live/url/urlsearchparams-sort.any.html
(cherry picked from commit d56da8cf9a0298d3e6e3ee8984f60d4a3217183b)
If given, the spec expects the input URL to be manipulated on the fly
as it is being parsed, and may ignore any errors thrown by the URL
parser.
Previously, we were not exactly following the specs assumption here
which resulted in us needed to make awkward copies of the URL in these
situations.
For most cases this is not an issue. But it does cause problems for
situations where URL parsing would result in a failure (which is
ignored by the caller), and the URL is _partially_ updated
while parsing.
Such a situation can occur when setting the host of an href alongside a
port number which is not valid. It is expected that this situation will
result in the host being updates - but not the port number.
Adjust the URL parser API so that it mutates the URL given (if any), and
adjust the callers accordingly.
Fixes two tests on https://wpt.live/url/url-setters-a-area.window.html
(cherry picked from commit ff71d8f2c97441bff5975c117a7e7c8820e33e44)
Because the type returned by to_string is a String, _not_ an
Optional<String>, the following code:
if (serialized_query.is_empty())
serialized_query = {};
Was achieving nothing at all! Make sure that the type is an
Optional<String> so that we're not just setting an empty string to an
empty string.
(cherry picked from commit d755a83c09a5fba82a91f9cc3f9e3b2e07880127)
Quick sort is not a stable sort. This meant we had a subtle issue
implementing this portion of the spec comment:
> The relative order between name-value pairs with equal names must
> be preserved.
Switch to insertion sort which is a stable sort, and properly handles
keys which are the same.
Fixes 8 tests on https://wpt.live/url/urlsearchparams-sort.any.html
(cherry picked from commit 1ba6dbd86c0a94e5f068e6586199866f7de6354e)
Made easier now that URL percent encode after encoding is also not
throwing any errors. This simplfies a bunch of error handling.
(cherry picked from commit df4739d7ced4159deb2b3e40ba6a1a08b7e7dd5b)
This fixes a crash using URLSearchParams when provided a percent encoded
string which does not percent decode to valid UTF-8.
Fixes a crash running https://wpt.live/url/urlencoded-parser.any.html
(cherry picked from commit 9c72fc9642266ac92dedbccac7d8c0bd238450cd)
This simplifies a bunch of places which were needing to error check and
convert from a ByteString to String.
(cherry picked from commit 84a7fead0eefd967d4319f4d71c0a0ca3095d2d1)
This passes the DOM encoding down to the URL parser, so the correct
encoder can be used.
(cherry picked from commit c1958437f983bb9761661534da34934c8dddcf6f)
Implements the corresponding encoders, selects the appropriate one when
encoding URL search params. If an encoder for the given encoding could
not be found, fallback to utf-8.
(cherry picked from commit 72d0e3284b604c4c1373fb019250cdf5bd492300)
Doing it is not part of the spec. Whenever needed, the spec will
explicitly percent decode the username and password.
This fixes some URL WPT tests.
(cherry picked from commit f511c0b441a591bc85f409242229c7b295e118e4)
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.
This URL library ends up being a relatively fundamental base library of
the system, as LibCore depends on LibURL.
This change has two main benefits:
* Moving AK back more towards being an agnostic library that can
be used between the kernel and userspace. URL has never really fit
that description - and is not used in the kernel.
* URL _should_ depend on LibUnicode, as it needs punnycode support.
However, it's not really possible to do this inside of AK as it can't
depend on any external library. This change brings us a little closer
to being able to do that, but unfortunately we aren't there quite
yet, as the code generators depend on LibCore.
This commit introduces a WEB_SET_PROTOTYPE_FOR_INTERFACE macro that
caches the interface name in a local static FlyString. This means that
we only pay for FlyString-from-literal lookup once per browser lifetime
instead of every time the interface is instantiated.
Along with putting functions in the URL namespace into a DOMURL
namespace.
This is done as LibWeb is in an awkward situation where it needs
two URL classes. AK::URL is the general purpose URL class which
is all that is needed in 95% of cases. URL in the Web namespace
is needed predominantly for interfacing with the javascript
interfaces.
Because of two URLs in the same namespace, AK::URL has had to be
used throughout LibWeb. If we move AK::URL into a URL namespace,
this becomes more painful - where ::URL::URL is required to
specify the constructor (and something like
::URL::create_with_url_or_path in other places).
To fix this problem - rename the class in LibWeb implementing the
URL IDL interface to DOMURL, along with moving the other Web URL
related classes into this DOMURL folder.
One could argue that this name also makes the situation a little
more clear in LibWeb for why these two URL classes need be used
in the first place.
