This adds a basic settings page to manage persistent Ladybird settings.
As a first pass, this exposes settings for the new tab page URL and the
default search engine.
The way the search engine option works is that once search is enabled,
the user must choose their default search engine; we do not apply any
default automatically. Search remains disabled until this is done.
There are a couple of improvements that we should make here:
* Settings changes are not broadcasted to all open about:settings pages.
So if two instances are open, and the user changes the search engine
in one instance, the other instance will have a stale UI.
* Adding an IPC per setting is going to get annoying. It would be nice
if we can come up with a smaller set of IPCs to send only the relevant
changed settings.
In order to maintain a consistent look and feel between internal about:
pages going forward, let's use a central CSS file to define Ladybird
colors and some common form control styles.
The intent is that this will replace the separate Task Manager window.
This will allow us to more easily add features such as actual process
management, better rendering of the process table, etc. Included in this
page is the ability to sort table rows.
This also lays the ground work for more internal `about` pages, such as
about:config.
This commit:
- Prevents path traversal via the about: scheme
- Prevents loading about:inspector
- Requires about: URIs to be opaque paths
- Prevents crashes with invalid percent encoded paths
Remember the query, so that if you're filtering for "color" on the
computed style tab, and switch to the resolved style tab, it's filtered
for "color" too.
This means we also can save looking up the filter text when a new node
is inspected.
If you have a search filter and then click on a different node, this now
applies the filter to the new node's properties, instead of showing all
of them.
The usage of color-scheme was introduced in commit:
ce5cd012b9
This reverts the Inspector to use self-selected colors, as the default
color-scheme colors do not look great in this window.
These used to serve as tests before we had proper testing infrastructure
set up. Now, they just sit forgotten about, gathering dust. Let's remove
them.
This adds a storage tab which contains just a cookie viewer for now. In
the future, storage like Local Storage and Indexed DB can be added here
as well.
In this patch, the cookie table is read-only.
It's getting a bit unwieldy to maintain as an inlined string. Move it to
its own file so it can be edited with syntax highlighting and other IDE
features.
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! :^)
This adds the following behavior for the DOM node/attribute editor in
the Inspector:
* If the user double clicks on an attribute name, the name is selected.
* If the user double clicks on an attribute value, the value text (sans
the surrounding quotes) is selected.
* Otherwise, double clicks select the entire text range.
- Expose table from console object
- Add new Table log level
- Create a JS object that represents table rows and columns
- Print table as HTML using WebContentConsoleClient
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.
After the refactor to use CSS variables for dark-mode colors in commit
ae25146b89, we had duplicated blocks for
some CSS rules. This patch just unites them into one block.
Currently, the feel of scrolling containers in the Inspector is a bit
awkward. We make the entire split-view container scrollable, then we
absolutely position the tab control buttons to force them to not scroll.
The result is that the scroll bar is painted over the tab controls, and
the tab content that we actually want to scroll has to scroll under the
tab controls. This never looked quite right.
It was basically:
<div tab-container> <!-- Scrollable -->
<div tab-controls /> <!-- Pinned to not be scrollable -->
<div tab-content /> <!-- The part we actually want to scroll -->
</div>
This patch moves the "scrollability" to just the tab content. We then
don't need to go out of our way to ensure only the content is actually
scrollable.
So we now have:
<div tab-container> <!-- Not scrollable -->
<div tab-controls /> <!-- Not pinned, uses normal layout -->
<div tab-content /> <!-- Scrollable -->
</div>
Previously, the legacy `-webkit-foo` properties would all be top of the
list, when they are generally not useful to inspect. Instead, put them
at the bottom, so that users can still see them if they want to, but
they're not in the way.
We currently display scroll bars for the JS console and its parent tab
container. We want the console output to be separately scrollable from
the tab content, but since both containers are scrollable, we end up
with nested scroll bars. This also makes actually scrolling feel pretty
awkward.
Prevent this by making the tab container non-scrollable when the JS
console is shown.
The previous character used, @, conflicted with CSS. % is used by other
templating engines, and doesn't conflict with language features (e.g.
media queries).
