...and use it to make HashMap::ensure() do a single hash lookup instead
of three.
We achieve this by factoring out everything but the bucket construction
logic from HashTable::write_value() into a lookup_for_writing() helper
so we can use it from more places.
We are often forced to convert numbers to strings inside LibJS, e.g when
iterating over the property names of an array, but it's also just a very
common operation in general.
This patch adds a 1000-entry string cache for the numbers 0-999 since
those appear to be by far the most common ones we convert.
To detect system time zone changes on Windows, the event we need to look
for is WM_TIMECHANGE. The problem is how the callback with said message
actually gets invoked is very particular. (1) We must have an active
message pump (event loop) for the message to ever be processed. (2) We
must be a GUI application as WM_TIMECHANGE messages are seemingly sent
to top level windows only. It doesn't say that in the docs for the
event, but attempts of creating a LibTest-based application with a
message pump and a message only window and never receiving the event
point to that probably being true.
This workaround is built off the fact that Qt's message pump defined
internally in QEventDispatcherWin32::processEvents does in fact receive
WM_TIMECHANGE events, even though it is not exposed as a QEvent::Type.
Given the requirements stated above it makes sense that it works here as
the message pump is executing in a QGuiApplication context. So we use a
native event filter to hook into the unexposed WM_TIMECHANGE event and
forward it along to the on_time_zone_changed() callback.
Note that if a Windows GUI framework is done in the future, we'll have
to re-add support to ensure the TimeZoneWatcher still gets invoked.
icu::TimeZone::createDefault() was returning the timezone that was set
when current_time_zone() was first called or the timezone set via
set_current_time_zone().
This meant that even when the system timezone changed and we instructed
all WebContent processes to invoke
ConnectionFromClient::system_time_zone_changed(), the updated timezone
system was not being used as we fetched from icu's default timezone.
icu::TimeZone::detectHostTimeZone() gets the timezone from the current
host system configuration and ensures we are always synced with the host
if we have no timezone cache.
Before this change, we'd construct a ByteBuffer for the internal buffer,
and then move-construct StringBuilder::m_buffer from it.
Due to ByteBuffer's inline capacity, this meant we had to memmove the
inline buffer an extra time for every StringBuilder created.
With this commit, only direct CSSStyleValues created from internal
StyleValues can be converted back to a StyleValue. More subtests will
pass as create_an_internal_representation() is implemented for the
various CSSStyleValue subclasses. :^)
Gets us... a LOT of WPT passes, because there's a ton of coverage for
each property.
When setting style to a CSSStyleValue we need to convert it to a
StyleValue. If we already have one, we might as well use it avoid the
work of serialization and re-parsing.
I realised I misunderstood what "constructed from a USVString" means, so
I've adjusted based on that. It does raise a question on what the source
USVString is if that string resulted in multiple CSSStyleValues being
created - see the linked issue.
Typed-OM requires us to have a generic way of asking "does property X
accept a list or a single value?" so this exists mainly for that.
Coordinating lists are annotated too - I'm not clear on exactly what
will be needed for those, but giving them a unique value now at the
worst will make them easier to find later.
This commit modifies the `compute_foo()` code for `font-style` and
`math-depth`. They previously assumed that their StyleValue was always
a special kind: FontStyleStyleValue or MathDepthStyleValue. This was
always true, because that's how we parse them, but it stops being true
once StylePropertyMap is involved: An author can set font-style to a
CSSKeywordValue of "italic", and this should work.
There are multiple ways that we could solve this, but the simplest and
easiest to maintain seems to be to handle those more basic StyleValues
in this computation code. Going forward, we'll have to be aware that
similar properties could have a basic StyleValue from the typed-OM
instead of the property-specific one we'd expect.
This fixes a crash on initial load of the page http://demo.actualbudget.org.
Minimal repro of the issue (error in the console without this PR):
<script>
const r = indexedDB.open("t", 1);
r.onupgradeneeded = e => e.target.result.createObjectStore("s", { keyPath: "id" });
r.onsuccess = () => r.result.transaction("s", "readonly").objectStore("s").getAllKeys();
</script>
of `PaintableBox` and `PaintableWithLines`.
If we ended up with non-identity transform in `hit_test()` of PB or PWL
and have to account for transforms, means we forgot to skip stacking
context while iterating through children.
- Add missing check to skip paintable that eastablishing a stacking
context in `PaintableBox::hit_test_children()`
- Otherwise it mostly reverts changes done by 4070f5a7e
...before falling back to containing block. Fixes a bug when we can't
scroll innermost scrollable element, because wheel event dispatching
immediately falls back to containing block.
I spotted this leak when WebContent was exiting with ASan enabled on a
page with a media element. MediaPaintable calls Gfx::Font::width(),
which calls through to measure_text_width(), which then drops an
hb_buffer_t* without freeing it.
This is a normative change in the ECMA-262 spec. See:
https://github.com/tc39/ecma262/commit/541b2f6
Note we already handled this case well, but let's update our impl to
match the latest spec text.
The optimization for non-shared ArrayBuffers operates on incorrect
values of from_byte_index and to_byte_index because they will have been
modified in the preceding steps. This causes the incorrect range to be
copied within the buffer.
