This API is a relic from the time when it was important for objects to
have easy access to the Window, and to know it was the global object.
We now have more spec-related concepts like relevant_global_object and
current_global_object to pull the Window out of thin air.
Choosing options from the `<select>` will load and display that style
sheet's source text, with some checks to make sure that the text that
just loaded is the one we currently want.
The UI is a little goofy when scrolling, as it uses `position: sticky`
which we don't implement yet. But that's just more motivation to
implement it! :^)
When working on the Inspector's HTML, it's often kind of tricky to debug
when an element is styled / positioned incorrectly. We don't have a way
to inspect the Inspector itself.
This adds a button to the Inspector to export its HTML/CSS/JS contents
to the downloads directory. This allows for more easily testing changes,
especially by opening the exported HTML in another browser's dev tools.
We will ultimately likely remove this button (or make it hidden) by the
time we are production-ready. But it's quite useful for now.
This commit introduces a WEB_SET_PROTOTYPE_FOR_INTERFACE macro that
caches the interface name in a local static FlyString. This means that
we only pay for FlyString-from-literal lookup once per browser lifetime
instead of every time the interface is instantiated.
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 outlined in: https://www.w3.org/TR/selectors-4/#compat
We now do not treat unknown webkit pseudo-elements as invalid at parse
time, and also support serializing these elements.
Fixes: #21959
No functional impact intended. This is just a more complicated way of
writing what we have now.
The goal of this commit is so that we are able to store the 'name' of a
pseudo element for use in serializing 'unknown -webkit-
pseudo-elements', see:
https://www.w3.org/TR/selectors-4/#compat
This is quite awkward, as in pretty much all cases just the selector
type enum is enough, but we will need to cache the name for serializing
these unknown selectors. I can't figure out any reason why we would need
this name anywhere else in the engine, so pretty much everywhere is
still just passing around this raw enum. But this change will allow us
to easily store the name inside of this new struct for when it is needed
for serialization, once those webkit unknown elements are supported by
our engine.
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.
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.
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.
