Atlassian login gets the base URL for its module scripts by throwing an
error and pulling out the current script's URL from error.stack with
regex.
Since we only returned a basename for module scripts, it would fail to
match and try and use `/` as a base URL (because it does
[matched_string] + "/"), which is not a valid base URL.
The StyleValue stored in m_property_values is already in it's computed
form and it's trivial to pull the underlying value out so there is no
need to store this separately.
Also removes unnecessary handling of percentage values in
`absolutize_values` - this is already handled within `compute_font`.
Update a couple of focus-related spec steps and their implementations.
The most relevant change is that we no longer allow focusing on elements
that return false for `->is_focusable()`, which necessitates fixing a
broken test that tried to `.focus()` on `<div>`s that were not
focusable. That test's output now more accurately reflects the expected
outcome as seen in other browsers.
And make it a DOM::Node, not DOM::Element. This makes everything flow
much better, such as spec texts that explicitly mention "focused area"
as the fact that we don't necessarily need to traverse a tree of
elements, since a Node can be focusable as well.
Eventually this will need to be a struct with a separate "focused area"
and "DOM anchor", but this change will make it easier to achieve that.
If selection navigation happens through an editing host, we should
enforce that for collapsed navigations (i.e. moving the caret) it can
only happen if the focus node of the selection is editable.
Now elements with position `absolute` properly resolve their position
inside parent elements with `grid`. I also imported some WPT tests
related to that topic.
Part 2 of resolving issues on https://hack4krak.pl
All fragments inside an atomic inline box should stay within that box,
otherwise we'll screw up the paint order and paint them behind things
that they're supposed to be on top of.
This fixes an issue with inline-block content not appearing on sites
like Google Docs and Reddit, among others.
Otherwise, we just keep painting into the old backing store. This fixes
an issue where the main spreadsheet area in Google Sheets was not
visually updating, despite everything looking good in memory.
Fixes bug when we didn't use `tracks_to_grow_beyond_limits` and instead
distributed extra space to all affected tracks. Also implements missing
"when accommodating max-content" part.
This commit adds the toResizableBuffer() and toFixedLengthBuffer()
methods to WebAssembly.Memory. This includes the necessary hook to
HostResizeArrayBuffer. Some modifications to function signatures in
LibWeb/WebAssembly/Memory.h were also made (changing the return type
from WebIDL::ExceptionOr to JS::ThrowCompletionOr) to allow the use of
some code in the aforementioned hook.
Note: the hook for HostGrowSharedArrayBuffer isn't implemented, since
LibJS doesn't seem to have complete support for growable
SharedArrayBuffers; the relevant methods/getters don't even exist on
the prototype, let alone HostGrowSharedArrayBuffer!
This should help pass the WebAssembly.Memory WPT tests included in
Interop 2025, except those pertaining to growable SharedArrayBuffers.
This cache is referenced by a few parts of the JS API spec, including
the threads spec (such as in toFixedLengthBuffer), as well as the
"refresh the Memory buffer" algorithm, which was implemented as a method
of Memory before this change.
Now, this algorithm can be implemented in a spec-like fashion (though it
mostly seems to add extra complexity). This change also fixes a bug
where memories that were re-exported from an imported WebAssembly.Memory
were given a distinct WebAssembly.Memory object, since the caching that
existed in Instance.cpp was instance-local, not global to the realm.
We also make Memory::m_buffer non-lazy, since we have to implement
"initialize a memory object" correctly anyway.
For whatever reason, the implementation of "create a fixed length memory
buffer" was borked for shared Wasm memories, in that a new
SharedArrayBuffer was created, with the contents of the Wasm memory
copied into it. This is incorrect, since the SharedArrayBuffer should be
a view into the Wasm memory's span, not a copy of it. This helps pass a
WPT subtest in wasm/jsapi/memory/grow.any.html.
Previously, clicking in the middle of a multi-code point grapheme would
place the cursor at a code unit index somewhere in the middle of the
grapheme. This was not only visually misleading, but the user could then
start typing and insert characters in the middle of the cluster. This
also made text select pretty wonky.
The main issue was that we were treating the glyph index in a glyph run
as a code unit index. We must instead map that glyph index back to a
code unit index with help from LibGfx (via harfbuzz).
The distance computation used here was also a bit off, especially for
the last glyph in a glyph run. We essentially want the cursor to end
up on whichever edge of the clicked glyph it is closest to. The result
of the distance computation limited us to the left edge of the last
glyph. Instead, we can use the same edge tracking we use for form-
associated elements to handle this for us.
We currently have a mixup in LibWeb between code unit offset and glyph
offset during hit testing. These extra fields will allow us to correct
this discrepency.
