We were previously embedding the original text to handle the special
case where the text is empty. We generate an extra span to hold the
string "#text" as a placeholder, so that we don't generate a 0px-wide,
unclickable (and therefore uneditable) node. Instead, we can just detect
when this is the case in the Inspector JS.
This further reduces the generated HTML for the Inspector on
https://github.com/SerenityOS/serenity from 1.9MB to 1.8MB (about 94KB,
or 4.7%).
Attribute values may contain HTML, and may contain invalid HTML at that.
If the latter occurs, let's not generate invalid Inspector HTML when we
embed the attribute values as data attributes. Instead, cache the values
in the InspectorClient, and embed just a lookup index into the HTML.
This also nicely reduces the size of the generated HTML. The Inspector
on https://github.com/SerenityOS/serenity reduces from 2.3MB to 1.9MB
(about 318KB, or 13.8%).
As of commit ccd701809f, the formatter for
JsonValue now fully serializes the value. The serializer will surround
the string value with quotes. We want control over when we add quotes to
the generated Inspector HTML, so avoid formatting attributes as raw JSON
values.
These IPCs are different than other IPCs in that we can't just set up a
callback function to be invoked when WebContent sends us the screenshot
data. There are multiple places that would set that callback, and they
would step on each other's toes.
Instead, the screenshot APIs on ViewImplementation now return a Promise
which callers can interact with to receive the screenshot (or an error).
All DOM node mutation IPCs now invoke an async completion IPC after the
DOM is mutated. This allows consolidating where the Inspector updates
its view and the selected DOM node.
This also allows improving the response to removing a DOM node. We would
previously just select the <body> tag after removing a DOM node because
the Inspector client had no idea what node preceded the removed node.
Now the WebContent process can just indicate what that node is. So now
after removing a DOM node, we inspect either its previous sibling (if it
had one) or its parent.
This commit un-deprecates DeprecatedString, and repurposes it as a byte
string.
As the null state has already been removed, there are no other
particularly hairy blockers in repurposing this type as a byte string
(what it _really_ is).
This commit is auto-generated:
$ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \
Meta Ports Ladybird Tests Kernel)
$ perl -pie 's/\bDeprecatedString\b/ByteString/g;
s/deprecated_string/byte_string/g' $xs
$ clang-format --style=file -i \
$(git diff --name-only | grep \.cpp\|\.h)
$ gn format $(git ls-files '*.gn' '*.gni')
If the Inspector widget already exists, be sure to inspect the page when
it is re-opened. However, this should be a no-op if the page was already
inspected (as any existing Inspector will be reset if a new page load
began).
Note this is not an issue in the AppKit chrome.
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.
