When a DOM text node is empty, we currently render the node name (which
is "#text") in the Inspector. This is just to prevent displaying nothing
at all, which looks a bit off. However, the patch to allow editing text
fields neglected to allow editing these empty fields.
This patch attaches the original text data as a data attribute, much
like we do for DOM attributes. That is used as the editable text in the
inspector, and the empty text fields are now wrapped in an editable
span.
Currently, when editing a comment, the `<!--` and `-->` start and end
sequences would be included in the generated <input> field. This would
result in including that text in the updated comment text. So, for
example, in a comment such as:
<!-- foo -->
Changing "foo" to "bar" would result in the comment:
<!--<!-- bar -->-->
And this would repeatedly nest for each edit.
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 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.
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 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.
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 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.
