This is partially a revert of commits:
10a8b6d411561b67a1ad
Rather than adding the prot_exec pledge requried to use dlopen(), we can
link directly against LibUnicodeData in applications that we know need
that library.
This might make the dlopen() dance a bit unnecessary. The same purpose
might now be fulfilled with weak symbols. That can be revisted next, but
for now, this at least removes the potential security risk of apps like
the Browser having prot_exec privileges.
This implements:
- console.group()
- console.groupCollapsed()
- console.groupEnd()
In the Browser, we use `<details>` for the groups, which is not actually
implemented yet, so groups are always open.
In the REPL, groups are non-interactive, but still indent any output.
This looks weird since the console prompt and return values remain on
the far left, but this matches what Node does so it's probably fine. :^)
I expect `console.group()` is not used much outside of browsers.
Loading libunicodedata.so will require dlopen(), which in turn requires
mmap(). The 'prot_exec' pledge is needed for this.
Further, the .so itself must be unveiled for reading. The "real" path is
unveiled (libunicodedata.so.serenity) as the symlink (libunicodedata.so)
itself cannot be unveiled.
Having files in Base's user `.config` folder means that every time the
Serenity image is built, all user settings in that file are thrown away.
So, let's not do that! :^)
Modified the default value for the homepage url to match what was in
Browser.ini, so there is no visible change.
With this change, System::foo() becomes Core::System::foo().
Since LibCore builds on other systems than SerenityOS, we now have to
make sure that wrappers work with just a standard C library underneath.
This fixes#10940.
Previously, all presses of the Delete key without a modifier in Browser
were uselessly consumed by the "Delete" action in the bookmark context
menu.
There's a subtle difference here. A "block box" in the spec is a
block-level box, while a "block container" is a box whose children are
either all inline-level boxes in an IFC, or all block-level boxes
participating in a BFC.
Notably, an "inline-block" box is a "block container" but not a "block
box" since it is itself inline-level.
I used "git grep -FIn http://" to find all occurrences, and looked at
each one. If an occurrence was really just a link, and if a https
version exists, and if our Browser can access it at least as well as the
http version, then I changed the occurrence to https.
I'm happy to report that I didn't run into a single site where Browser
can't deal with the https version.
This removes the awkward String::replace API which was the only String
API which mutated the String and replaces it with a new immutable
version that returns a new String with the replacements applied. This
also fixes a couple of UAFs that were caused by the use of this API.
As an optimization an equivalent StringView::replace API was also added
to remove an unnecessary String allocations in the format of:
`String { view }.replace(...);`
With this patch, we now initialize the `WebContentConsoleClient` as soon
as the Page has loaded, instead of waiting for the Console Window to be
shown. This finally lets us see log messages that happened before the
window was opened! :^)
However, it is not perfect. Waiting until the page has loaded means we
lose any messages that happen *during* page load. Ideally we would
initialize the WCCC when the page *starts* loading instead, but it
requires that the page has a document and interpreter assigned and
accessible. As far as I can tell with my limited knowledge, this is not
the case until the page has completed loading.
The console widget now requests messages and receives them in bulk,
using the shiny new IPC calls. This lets it display console messages
that occurred before the widget was created. :^)
Previously, it would keep a pointer to the interpreter of the previous
page, which resulted in Crashy Fun Times.
This also changes the clearing behavior - instead of clearing the
console output every time the window is shown, we clear it when the page
changes. This is more useful, since before you would lose any log
messages that had happened before opening the window.
Having the BrowserWindow assigning Tab's internals felt a bit wrong.
This is also a step towards removing BrowserWindow as a friend class.
While I was at it, changed the Tab to having a pointer to the
ConsoleWidget instead of the Window, since that is usually what we want
to use, and it's awkward having to static_cast the main-widget
repeatedly.
This resets the DOM Inspector to a default state when re-opening it,
instead of it displaying the previous selection and properties, which
may be outdated. This is closer to how Chrome and Firefox behave.
Eventually, it probably makes sense to copy their behavior of selecting
the `<body>` element by default.
The direct-Document-access DOMTreeModel is no longer used, since the DOM
Inspector has to access the Document remotely over IPC. This commit
removes it, and renames DOMTreeJSONModel to take its place, since it no
longer has to differentiate itself from the non-JSON one.
In case that didn't make sense:
- Delete DOMTreeModel
- Rename DOMTreeJSONModel -> DOMTreeModel
Also simplify the logic by removing `Tab::view_dom_tree()`, and making
the Tab keep a pointer to the InspectorWidget instead of its Window,
since that's more often what we want to access.
