Rework our hash functions a bit for significant better performance:
* Rename int_hash to u32_hash to mirror u64_hash.
* Make pair_int_hash call u64_hash instead of multiple u32_hash()es.
* Implement MurmurHash3's fmix32 and fmix64 for u32_hash and u64_hash.
On my machine, this speeds up u32_hash by 20%, u64_hash by ~290%, and
pair_int_hash by ~260%.
We lose the property that an input of 0 results in something that is not
0. I've experimented with an offset to both hash functions, but it
resulted in a measurable performance degradation for u64_hash. If
there's a good use case for 0 not to result in 0, we can always add in
that offset as a countermeasure in the future.
This adds the --expose-experimental-interfaces command line flag to
enable experimental IDL interfaces. Any IDL interface with Experimental
in its exposed attributes will be disabled by default.
The problem is that by stubbing out or partially implementing interfaces
in LibWeb, we actually make some sites behave worse. For example, the
OffscreenCanvas interface being exposed makes sites believe we fully
support it, even though we don't. If the interface was not exposed,
these sites may fall back to ordinary canvas objects. Similarly, to
use YouTube, we currently have to patch out MSE interfaces.
This flag will allow developers to iteratively work on features,
without breaking such sites. We enable experimental interfaces during
tests.
Unfortunately this is a bit of a pain to test as it is surprisingly
difficult to create a non secure context in our test harness.
This is because both file scheme URLs and localhost are considered
secure contexts.
To test this, add a very specific internals setter to change the
top level origin of the environment for the current realm.
Previously we computed font properties separately from other properties
for two reasons:
1) These font properties were computed using a different length
resolution context than the rest of the properties.
2) These properties were required to be computed before creating the
length resolution context for the rest of the properties.
The first issue was solved in the previous commit by introducing a
generic method to get the computation context for a property, and
the second is solved in this commit by computing properties in the
required order.
This simplifies the code a bit and opens up some opportunities for
optimization.
It was prevously translating it to just `bool` instead of
`Optional<bool>`.
Required elements in dictionary (such as in Notification.idl
for the NotificationAction) were treated as Optional<T> like the other
non-required elements. Now it's just the type without the Optional.
Co-authored-by: Zaggy1024 <gregory.bertilson@gmail.com>
Fold attribute setter handling into the shared [Replaceable] and
[PutForwards] paths, aligning the implementation more closely with the
WebIDL specification.
This change unfortunately introduces a regression in a WebAssembly
JS API test that expects attribute setters to throw when invoked
with no arguments (rather than treating the missing argument as
undefined). The exact specification text that mandates this
behavior for the WASM API is unclear to me.
The new behaviour seems like it would be more compatible in the
general case by not throwing an exception for all of the other
cases, so this commit accepts this as a regression until the
reasoning for needing to throw can be determined.
Intermediate classes in the initialize() chain set up prototypes and
define properties. Forgetting to call Base::initialize() in any
override would silently skip that setup.
Before, we had inefficient Vector usage in this code generator that
caused a lot of heap churn while loading in all the IDL files. Given
that this file will load in hundreds of IDL files, we can do better by
mmapping the files directly instead of reading them into two separate
file contents string buffers and then copying them into a growing vector
Commit 1b8e81cd6f added a check to prevent
assigning a default value when the default value itself is null. But we
had previously generated an uninitialized type, expecting it to become
defaulted later on. So we would have generated code such as:
bool value;
if (!property.is_null() && !property.is_undefined())
value = property.to_boolean();
options.value = value;
This is undefined behavior.
We know use the same default value check to ensure we generate Optional
types instead. So the above `value` initializer becomes:
Optional<bool> value;
First check if a string is a member of the enum before attempting
numeric conversion. This generates correct code for fields like:
AudioContextOptions {
latencyHint: AudioContextLatencyCategory | double;
}
Previously, getComputedStyle() would always call update_layout() for
most properties. This was expensive since layout involves a full tree
traversal even when only style information is needed.
This change introduces a more granular approach:
- Properties needing layout computation (used values like width/height)
still call update_layout()
- Properties needing a layout node for resolved value computation
(colors, border widths, etc.) also call update_layout()
- All other properties now only call update_style()
The set of properties needing layout node for resolution is now defined
in Properties.json via the "needs-layout-node-for-resolved-value" flag,
rather than being hardcoded. This is generated into a new function
property_needs_layout_node_for_resolved_value().
Any type ending in "Event" or "Element" does not need to be added to the
manually curated list of platform objects in is_platform_object().
Additionally, "WindowProxy" was already part of that list, so no need to
check for it separately. No functional changes.
The WebIDL spec requires that attributes marked [LegacyUnforgeable]
share the same getter and setter function objects across all instances
within the same Realm.
Previously, we were creating new JS::NativeFunction wrappers during
every instance initialization, which caused identity checks to fail.
This change moves these functions into Bindings::Intrinsics so they
are created once per Realm and reused.
The IDL generator was passing 'false' to generate_to_cpp when converting
a union containing a string type.
This broke WebIDL's LegacyNullToEmptyString behavior.
Pass the actual legacy_null_to_empty_string flag instead.
Fixes some WPTs:
domparsing/outerhtml-02
trusted-types/block-string-assignment-to-Element-outerHTML
trusted-types/block-string-assignment-to-HTMLElement-generic
trusted-types/block-string-assignment-to-ShadowRoot-innerHTML
This works by generating random values using XorShift128PlusRNG at
compute time and then caching them on the document using the relevant
random-caching-key