Previously, the find in page function would fail to find text which was
split across multiple text nodes. For example, given the following
markup: `WH<span>F` the query `WHF` would previously fail to be
matched.
This is done by traversing all of the document's text nodes -
constructing a complete string to query against and keeping track of
the locations where that string is split across multiple nodes.
This is actually safe everywhere but in the topmost program scope.
For web compatibility reasons, we have to flush all top-level bindings
to the environment, in case a subsequent separate <script> program
comes looking for them.
Instead of displaying locals as "locN", we now show them as "name~N".
This makes it a lot easier to follow bytecode dumps, especially in
longer functions.
Note that we keep displaying the local index, to avoid confusion in case
there are multiple separate locals with the same name in one executable.
Linking LibLocale publicly ensures that libicudata.a is also available
in all embedders of LibJS. Otherwise, ICU crashes in hard-to-track-down
ways at runtime when the data is not available.
The proposal has undergone quite a few normative changes since we last
synced with it. There was a time when it could not be implemented as it
was written, which is no longer the case. The resulting proposal has had
so many changes compared to our implementation, that it wouldn't make
sense to implement them commit-by-commit as we normally do. So instead,
this just implements the HEAD revision of the spec in one pass.
For Intl.DurationFormat, we will need to know a locale's hours-minutes
time separator, minutes-seconds time separator, and whether the locale
prefers digital hours to always display as 2 digits.
...and shadow tree with TextNode for "value" attribute is created.
This means InlineFormattingContext is used, and button's text now
respects CSS text-decoration properties and unicode-ranges.
Previously, navigating to or from `about:newtab` caused a crash due to
inadvertent null dereferences when checking whether a request or
response to a request should be blocked as mixed content.
The big improvement included in this commit is stack height mismatch
validation. There are other minor improvements included (related to the
validation algorithm). The method of supporting stack polymorphism has
changed to be more like the spec, which was necessary for confidently
handling stack height mismatches.
See:
https://webassembly.github.io/spec/core/appendix/algorithm.html
Previously, the validator had a lot of extraneous information related to
frames. Now, there's just one stack with all the necessary information
derived from it.
Previously, `memory.fill` filled memory with 4-byte values, even though
`memory.fill` should fill with just one byte. Also fixes some other
issues with some of the bulk memory instructions, like `memory.init`.
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.
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.
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.
