This uses ICU for the Intl.DateTimeFormat `format` `formatToParts`,
`formatRange`, and `formatRangeToParts`.
This lets us remove most data from our date-time format generator. All
that remains are time zone data and locale week info, which are relied
upon still for other interfaces. So they will be removed in a future
patch.
Note: All of the changes to the test files in this patch are now aligned
with other browsers. This includes:
* Some very incorrect formatting of Japanese symbols. (Looking at the
old results now, it's very obvious they were wrong.)
* Old FIXMEs regarding range formatting not including the start/end date
when only time fields were requested, but the dates differ.
* Day period inconsistencies.
Methods and attributes marked with [FIXME] are now implemented as
direct properties with the value `undefined` and are marked with the
[[Unimplemented]] attribute. This allows accesses to these properties
to be reported, while having no other side-effects.
This fixes an issue where [FIXME] methods broke feature detection on
some sites.
Properties marked with the [[Unimplemented]] attribute behave as normal
but invoke the `VM::on_unimplemented_property_access callback` when
they are accessed.
On my system `QKeySequence::StandardKey::ZoomIn` includes both `Ctrl++`
and `Ctrl+=`, so explicitly adding the secondary `Ctrl+=` shortcut
ourselves results in an ambiguous shortcut error message being shown.
According to the Qt documentation the key bindings returned by
`QKeySequence::StandardKey::*` are platform specific, so we may still
need to add the secondary shortcut on some systems. Therefore, we now
check whether our secondary shortcut is already in the shortcut list
before adding it.
This now matches the behavior of did_request_link_context_menu and
friends. Previously the coordinates relative to the page rather than
viewport were sent to the chrome.
The placeholder text is there to prompt the user as to what could be
added in the address bar. The current text tells the user that they can
"Search or enter web address" even when the search setting is disabled.
When attempting to "Search" the user is instead sent to page ":", with
an error in the console:
WebContent(575249): (FIXME) Don't know how to navigate to :
This patch fixes this by checking whether the search feature is enabled
and setting the placeholder appropriately. This provides a slightly
better user experience.
Closes#132
Previously, part of the procedure we used to sanitize URLs entered via
the command line would check the host against the public suffix
database. This led to some valid, but not publicly accessible URLs
being treated as invalid.
The IntlMV is meant to be arbitrarily precise. If the user provides a
string value to be formatted, we lose precision by converting extremely
large values to a double. We were never able to address this, as support
for arbitrary precision was a big FIXME. But ICU can handle it by just
passing the raw string on through.
This uses ICU for the Intl.NumberFormat `formatRange` and
`formatRangeToParts` prototypes.
Note: All of the changes to the test files in this patch are now aligned
with both Chrome and Safari.
This uses ICU for the Intl.NumberFormat `format` and `formatToParts`
prototypes. It does not yet port the range formatter prototypes.
Most of the new code in LibLocale/NumberFormat is simply mapping from
ECMA-402 types to ICU types. Beyond that, the only algorithmic change is
that we have to mutate the output from ICU for `formatToParts` to match
what is expected by ECMA-402. This is explained in NumberFormat.cpp in
`flatten_partitions`.
This lets us remove most data from our number format generator. All that
remains are numbering system digits and symbols, which are relied upon
still for other interfaces (e.g. Intl.DateTimeFormat). So they will be
removed in a future patch.
Note: All of the changes to the test files in this patch are now aligned
with both Chrome and Safari.
Turns out vcpkg does not yet support Universal binaries. While they are
working on it, lets produce arm64 binaries only for now to unblock the
pipeline.
This change allows the results of a find in page query to be reported
back to the user interface. Currently, the number of results found and
the current match index are reported.
Before we had HTTP::HeaderMap (which preserves multiple headers with the
same name), we collected multiple "Set-Cookie" headers and bundled them
together as a JSON array.
This was a huge hack, and now we can stop doing that, since LibWeb gets
access to the full set of headers now.
Instead of using a HashMap<ByteString, ByteString, CaseInsensitive...>
everywhere, we now encapsulate this in a class.
Even better, the new class also allows keeping track of multiple headers
with the same name! This will make it possible for HTTP responses to
actually retain all their headers on the perilous journey from
RequestServer to LibWeb.
The [UTF-8](https://datatracker.ietf.org/doc/html/rfc3629#page-5)
standard says to reject strings with upper or lower surrogates. However,
in many standards, ECMAScript included, unpaired surrogates (and
therefore UTF-8 surrogates) are allowed in strings. So, this commit
extends the UTF-8 validation API with `AllowSurrogates`, which will
reject upper and lower surrogate characters.
Adds all the arithmetic ops for f32x4 and f64x2 SIMD instructions.
With this, we pass 8375 additional tests :)
Quite a few of the spec tests for this are still failing.
I confirmed with the wasmer runtime manually for a number of them,
and we seem to match their and results. I'm not really sure
what's happening here, a spec bug or wasmer is broken in
the same way.
18476 failed before.
10101 failed after.
