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.
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.
Other browsers have a nice little feature where right-clicking on a
`mailto` or `tel` link will let you copy the email address or telephone
number, instead of the full URL. So let's do that!
Pages like the new tab page, error page, etc. all belong solely to
Ladybird, but are scattered across a couple of subfolders in Base. This
moves them all to Base/res/ladybird.
This allows a limited amount of DOM manipulation through the Inspector.
Users may edit node tag names, text content, and attributes. To initiate
an edit, double-click the tag/text/attribute of interest.
To remove an attribute, begin editing the attribute and remove all of
its text. To add an attribute, begin editing an existing attribute and
add the new attribute's text before or after the existing attribute's
text. This isn't going to be the final UX, but works for now just as a
consequence of how attribute changes are implemented. A future patch
will add more explicit add/delete actions.
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.
This adds a JS console to the bottom section of the Inspector WebView.
Much of this code is based on the existing WebView::ConsoleClient, but
ported to fit the inspector model. That is, much of the code from that
class is now handled in the Inspector's JS.
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.
It is currently a bit messy to pass these options along from main() to
where WebContent is actually launched. If a new flag were to be added,
there are a couple dozen files that need to be updated to pass that flag
along. With this change, the flag can just be added to the struct, set
in main(), and handled in launch_web_content_process().
Provides a nicer experience on pages with large trees so that the window
isn't just a large blank screen while it is loading. Instead, send the
trees to the Inspector WebView once they have arrived and have been
transformed to HTML.
We Base64 encode the HTML to avoid needing to deal with all kinds of
nested quotes that may appear in the HTML. We could instead send the
JSON to the WebView, but generating the HTML in C++ feels a bit easier
for now.
The Inspector will have a split view, where the top view is that of the
exisiting DOM and accessibility trees, and the bottom view is that of
the currently inspected node's style properties. This patch generalizes
some of the generated code to support having these 2 views.
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.
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.
We currently have StylePropertiesModel and AriaPropertiesStateModel in
LibWebView. These depend on GUI::Model and GUI::ModelIndex, which is the
only reason that the non-Serenity Ladybird chromes require LibGUI.
Further, these classes are very nearly idenitical.
This creates a PropertyTableModel to provide the base functionality for
all table-based model types used by all Ladybird chromes. It contains
code common to the style / ARIA table models, and handles the slight
differences between the two (namely, just the manner in which the values
are flattened into a list during construction).
The Qt and Serenity chromes can create thin wrappers around this class
to adapt its interface to their chrome-specific model classes (i.e.
QAbstractItemModel and GUI::Model).
We currently have DOMTreeModel and AccessibilityTreeModel in LibWebView.
These depend on GUI::Model and GUI::ModelIndex, which is the only reason
that the non-Serenity Ladybird chromes require LibGUI. Further, these
classes are very nearly idenitical.
This creates a TreeModel class to provide the base functionality for all
tree-based model types used by all Ladybird chromes. It contains code
common to the DOM / accessibility tree models, and handles the slight
differences between the two (namely, just the formatting of each node's
text for display).
The Qt and Serenity chromes can create thin wrappers around this class
to adapt its interface to their chrome-specific model classes (i.e.
QAbstractItemModel and GUI::Model).
The current helpers assume that a valid URL is a full URL (i.e. contains
the "://" separator between the scheme and domain). This isn't true, as
"file:" alone is parsed as a valid URL.
We must also avoid simply searching for the parsed public suffix in the
original URL string. For example, "com" is a public suffix. If we search
for that in the URL "com.com", we will think the public suffix starts at
index 0.
This will create a string of the form:
Search DuckDuckGo for "Ladybird is awesome!"
If the provided query URL is unknown, the engine name is excluded (e.g.
for custom search URLs).
These engines and their query URLs are duplicated in several places.
Before implementing search support in the AppKit chrome, let's move
these engines to LibWebView.
This is meant to serve as the method all Ladybird chromes can use to
highlight the eTLD+1 substring of the URL. It uses the Public Suffix
List to break the URL into 3 parts: the scheme and subdomain, the
eTLD+1, and all remaining parts (port, path, query, etc.).
After d2c7e1ea7d, there is now only one
user of LibPublicSuffix - the URL sanitation utility within LibWebView.
Rather than having an entire library for the small Public Suffix data
accessor, merge it into LibWebView.
