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.
We currently implement several forms of this method across the Ladybird
chromes. As such, we see commits to add special URL handling that only
affects a single chrome. Instead, let's consolidate all special handling
in a single location for all chromes to make use of.
This method can handle resolving file:// URLs, falling back to a search
engine query, and validation against the Public Suffix List. These cases
were gathered from the various chromes.
This most importantly gets rid of a chain of "String to DeprecatedString
to String" transformations when setting a tooltip from GUI::Widget's
set_tooltip function.
Which pretty much needs to be done together due to the amount of places
where they are compared together.
This also involves porting over StackOfOpenElements over to FlyString
from DeprecatedFly string to prevent a gazillion calls to
`.to_deprecated_fly_string` calls in HTMLParser.
This commit introduces 3 things:
- Support for the color type in HTMLInputElement itself
- A mechanism for handling non event loop blocking dialogs in Page
- The associated plumbing up to ViewImplementation
Frontends may add support for the color picker with the
ViewImplementation.on_request_color_picker function
After moving to navigables, we started reusing the code that populates
session history entries with the srcdoc attribute value from iframes
in `Page::load_html()` for loading HTML.
This change addresses a crash in `determine_the_origin` which occurred
because this method expected the URL to be `about:srcdoc` if we also
provided HTML content (previously, it was the URL passed along with the
HTML content into `load_html()`).
Previously, we used `on_load_finish` to determine when the text test
was completed. This method did not allow testing of async functions
because there was no way to indicate that the runner should wait for
the async call to end.
This change introduces a function in the `internals` object that is
intended to be called when the text test execution is completed. The
text test runner will now ignore `on_load_finish` which means a test
will timeout if this new function is never called.
`test(f)` function in `include.js` has been modified to automatically
terminate a test once `load` event is fired on `window`.
new `asyncTest(f)` function has been introduces. `f` receives function
that will terminate a test as a first argument.
Every test is expected to call either `test()` or `asyncTest()` to
complete. If not, it will remain hanging until a timeout occurs.
These classes are used as-is in all chromes. Move them to LibWebView so
that non-Serenity chromes don't have to awkwardly reach into its headers
and sources.
If we set m_waiting_for_messages to true for the intial message request,
we might never receive a response, and block the console from requesting
any more messages indefinitely. Instead, issue a non-blocking initial
request, which is how the Qt and Serenity chromes behaved before the
ConsoleClient abstraction.
This also changes ConsoleClient::clear() to use run_javascript() rather
than js_console_input(), as that is also how the chromes used to behave.
This creates WebView::ConsoleClient to handle functionality that will be
common to the JS consoles of all Ladybird chromes. This will let each
chrome focus on just the UI.
Note that this includes the `console.group` functionality that only the
Serenity chrome previously had. This was a FIXME in the Qt chrome, and
it is implemented such that all chromes will receive this functionality
for free.
This tokenizes a page's source to produce HTML with syntax highlighting.
The first implementation here is rather simple; we do not yet implement
code folding, line numbers, etc.
The goal is for this to be used as the View Source implementation for
all Ladybird chromes.
Move the methods to set the native/user style sheets to the base
ViewImplementation class. We must also generate the native style sheet
explicitly for now, as LibWebView on Lagom isn't able to include the
main LibWebView CMakeLists.txt file yet.
The old names sounded like awkward English to me, as they implied the
WebContent process is asking for information. In reality, WebContent is
*providing* the information.
We can easily add hooks to notify the browsers of these events if any
implementation-specific handling is needed in the future, but for now,
these only repaint the client, which we can do in ViewImplementation.
Storing the backup bitmap is the same across Browser and Ladybird. Just
peform that work in LibWebView, and handle only the implementation-
specific nuances within the browsers.
This also sets the default callback to do what every non-Serenity
browser is doing, rather than copy-pasting this callback into every
implementation. The callback is still available for any platform which
might want to override the default behavior. For example, OOPWV now
overrides this callback to use FileSystemAccessClient.
