When scrolling to the inspected element, if we scroll to its exact
position, it would often be placed behind the fixed header at the top of
the WebView. This patch gives the scroll a bit of an offset to scroll
comfortably beneath the header.
The `page_did_request_scroll_to` API takes a CSS position, and thus
callers should not scale to device pixels before invoking it. Instead,
align this API with (most) other PageHost APIs which scale to device
pixels before sending the corresponding IPC message.
In the AppKit chrome, convert the provided device pixel position to a
widget position.
This matches the negation of the vertical scroll delta value. This makes
the scroll events behave as follows on macOS:
Natural scrolling enabled:
* Scrolling up on the trackpad scrolls down on the page.
* Scrolling right on the trackpad scrolls left on the page.
Natural scrolling disabled:
* Scrolling up on the trackpad scrolls up on the page.
* Scrolling right on the trackpad scrolls right on the page.
This is necessary for being able to use the qemu `-kernel` option.
The QEMU virt machine uses OpenSBI's FW_DYNAMIC feature to pass
the kernel entry address, which is the virtual entry point address
specified in the kernel ELF. If we instead `objcopy` the kernel into a
raw binary, OpenSBI will jump to the physical kernel load address, which
is what we want it to do.
ASAN was crying way too much when running the LibJS JIT since the old
OFFSET_OF implementation was too wild for its liking.
By turning off the invalid-offsetof warnings, we can use the offsetof
builtin instead. However, I'm leaving this as a wrapper macro, since
we may still want to do something different for other compilers.
The CardPainter in LibCards caches already painted bitmaps. This adds a
helper that gets the bitmap from a cache or creates a new one, if the it
doesn't exist yet. It does this by calling a creator function with the
new bitmap, which can then paint into the bitmap. This makes the code a
bit simpler and shorter.
In Spider, cards that can't be moved are now shown as disabled using the
helpers in LibCards. This makes it much easier to see what can be moved
and to where, overall improving the game significantly!
This adds a little helper in Cards::CardStack that updates the disabled
flags for its cards depending on a movement rule. It does this by
searching from the bottom up for the last card that is valid. It then
sets the disabled flag for all cards above that card, if it isn't upside
down.
These wrappers will make it much easier to do various operations on the
different ArrayBuffer-related classes in LibWeb compared to the current
solution, which is to just accept a Handle<Object> everywhere (and use
"any" in the *.idl files).
Co-Authored-By: Matthew Olsson <mattco@serenityos.org>
The one deviation from the spec here is to use this in the WOFF
TableDirectoryEntry's tag field. However, *not* making that a Tag made
a lot of things more complicated than they need to be.
A few small changes that didn't seem to deserve separate commits:
- Mark it as packed to remove compiler complaints when it's a member of
a packed struct.
- Add a default constructor for places where we fill in a struct
gradually.
- Restrict the constructor to exactly 4-character string literals.
- Add a to_u32() method for the one place that needs that.
While creating a new VM feels warm and fuzzy from an isolation
perspective, having multiple JS heaps in the same process is a footgun
waiting to happen. Additionally, there are still many places in LibWeb
that reach for the main thread VM to check for the current realm to do
things, such as Web::HTML::incumbent_settings_object().
The streams and other common APIs require byte spans to operate on
arbitrary data. This is less than helpful when wanting to serialize
spans of other data types, such as from an Array or Vector of u32s.
For each stacking context with an opacity less than 1, we create a
separate framebuffer. We then blit the texture attached to this
framebuffer with the specified opacity.
To avoid the performance overhead of reading pixels from the texture
into Gfx::Bitmap, a new method that allows for direct blitting from
the texture is introduced, named blit_scaled_texture().
This was used to provided base functionality for model-based chromes for
viewing the DOM and accessibility trees. All chromes now use the WebView
inspector model for those trees, thus this class is unused.
This is modeled after a similar implementation for the JS console.
This client takes over an inspector WebView (created by the chrome) to
create the inspector application. Currently, this application includes
the DOM tree and accessibility tree as a first pass. It can later be
extended to included the style tables, the JS console itself, etc.
This is an internal object that must be explicitly enabled by the chrome
before it is added to the Window. The Inspector object will be used by a
special WebView that will replace all chrome-specific inspector windows.
The IDL defines methods that this WebView will need to inform the chrome
of various events, such as the user clicking a DOM node.
Setting the marker's content width here is causing the text that follows
the marker to be indented a bit too much. This is noticeable when a line
with a disclosure marker is followed by a line with any other marker. It
previously would look something like:
> Text inline with disclosure-closed marker
* Text inline with circle marker
# Text inline with square marker
Now the disclosure marker line matches other marker types:
> Text inline with disclosure-closed marker
* Text inline with circle marker
# Text inline with square marker
