This was seen in Browser when hotkey activations were processed twice.
If we open the Inspector with a hotkey (F12) and quickly activate that
hotkey again, we could try sending a JS command (inspector.loadDOMTree)
before the inspector.js file was actually loaded in the WebContent.
The window for this bug is larger on Serenity, where loading WebContent
is a bit slower than on Linux. So even with the Browser bug fixed, it is
pretty easy to hit this window still.
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%).
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')
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.
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.
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.
