It was a bit short-sighted to combine the tag and attribute names into
one string when the Inspector requests a context menu. We will want both
values for some context menu actions. Send both names, as well as the
attribute value, when requesting the context menu.
Currently, when editing a DOM attribute, the replacement method first
removes the attribute, then adds the replacement attributes. This
results in the edited attribute jumping to the end of the attribute
list in the Inspector.
This patch will try to avoid removing the attribute if one of the
replacements has the same name. This will keep the edited attribute in
the same location.
The FIXME added to ConnectionFromClient::remove_dom_node is copied from
Web::EditEventHandler. The same behavior is observed here, with many
lingering Layout::TextNodes, for example.
The Inspector will have context menu support to manipulate the DOM, e.g.
adding or removing nodes/attributes. This context menu will require some
detailed knowledge about what element in the Inspector has been clicked.
To support this, we intercept the `contextmenu` event and collect the
required information to be sent to the Inspector client over IPC.
This is a first step towards removing the various Page& and Page*
we have littering the engine with "trust me bro" safety guarantees.
Co-Authored-By: Andreas Kling <kling@serenityos.org>
This is a first step towards simplifying the ownership model of
Web::Page. Soon Web::Page will store its WebClient as a
NonnullGCPtr to help solve lifetime issues of the client being
destroyed before the page.
This adds APIs to allow Ispector clients to:
* Change a DOM text or comment node's text data.
* Add, replace, or remove a DOM element's attribute.
* Change a DOM element's tag.
The Inspector will have an <input> element to execute user-provided JS.
This adds an IDL method and IPC to forward that JS from the Inspector
WebView to the Inspector client.
In order for same-origin NavigableContainers (iframe, frame, embed, ...)
and window.open() WindowProxies to have the proper JS access to their
embedder/opener, we need to host multiple top level traversables in the
same WebContent process. As a first step, make WebContent::PageHost hold
a HashMap of PageClient objects, each holding their own Web::Page that
represents a TraversableNavigable's API surface with the UI process.
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.
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().
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 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.
The roll-up feature allows the user to set the window content to be
hidden, while retaining the window title bar visibility.
While in roll-up mode, the window height size is not changeable.
However, tiling the window or maximizing (as well as unmaximize) it will
instruct exiting the roll-up mode.
We now create a WorkerAgent for the parent context, which is currently
only a Window. Note that Workers can have Workers per the spec.
The WorkerAgent spawns a WebWorker process to hold the actual
script execution of the Worker. This is modeled with the
DedicatedWorkerHost object in the WebWorker process.
A start_dedicated_worker IPC method in the WebWorker IPC creates the
WorkerHost object. Future different worker types may use different IPC
messages to create their WorkerHost instance.
This implementation cannot yet postMessage between the parent and the
child processes.
Co-Authored-By: Andreas Kling <kling@serenityos.org>
Previously, a DNS packet containing an invalid name would be returned
with an empty name. With this change, an error is returned if any error
is encountered during parsing.
Framebuffer object is allocated using OpenGL's API and is not platform
specific which means it could be used on both macOS and Linux unlike
EGL specific PBuffer.
The QuickLaunchWidget can now also parse the old config format, so that
we stay compatible with the old format. After loading, it deletes the
old config values and saves them in the new format.
The entries in the QuickLaunchWidget are now saved properly. This means
that the format with which they are saved needed to be changed, since we
now also need to store the order of the entries. To do this, the entries
are now saved using the following value format: "<index>:<path>". When
loading, we simply parse this structure out and sort by the index,
before parsing the path into `QuickLaunchEntry`s.
You can now add applications to Quick Launch via the context
menu option of their windows. Clicking it creates an event with the
stored PID of the process that created the window. The Taskbar receives
the event and tells the QuickLaunchWidget to add the PID, which then
gets the executable using /sys/kernel/processes. It also looks for an
AppFile using the name from the process object and if there is one, it
uses that, since it should contain a better formatted name.
The "Window" classes in LibGUI and WindowServer now store the PID of the
process that created the window. LibGUI's Window obtains the PID in the
constructor via getpid(), and passes it in Window::show() to
WindowServer via the create_window() IPC route. WindowServer then saves
it in its own Window class.
This allows us to find the process that created a window in order to add
process-specific actions to the window.
