The intent of the spec is that the output of console.dir is interactable
within the console. Our Printer implementation currently just prints the
provided object as a string, and doesn't check the provided `options`
argument. But having console.dir defined prevents exceptions from being
thrown on real websites.
Instead of just calling JS::Value::to_string_without_side_effects() when
printing values to the console, have all the console clients use
the same JS::Print that the REPL does to print values.
This method leaves some things to be desired as far as OOM hardening
goes, however. We should be able to create a String in a way that
doesn't OOM on failure so hard.
This will make it easier to support both string types at the same time
while we convert code, and tracking down remaining uses.
One big exception is Value::to_string() in LibJS, where the name is
dictated by the ToString AO.
We have a new, improved string type coming up in AK (OOM aware, no null
state), and while it's going to use UTF-8, the name UTF8String is a
mouthful - so let's free up the String name by renaming the existing
class.
Making the old one have an annoying name will hopefully also help with
quick adoption :^)
Previously we would disable console debug messages on all non Serenity
platforms as it caused double printing on lagom `js`. This patch limits
this to the `js` utility, allowing LibWeb to print debug messages
regardless of the operating system :^)
Print exceptions passed to `HTML::report_exception` in the JS console
Refactored `ExceptionReporter`: in order to report exception now
you need to pass the relevant realm in it. For passed `JS::Value`
we now create `JS::Error` object to print value as the error message.
...and the other Console methods.
This lets you apply styling to a log message or any other text that
passes through the Console `Formatter` operation.
We store the CSS on the ConsoleClient instead of passing it along with
the rest of the message, since I couldn't figure out a nice way of
doing that, as Formatter has to return JS::Values. This way isn't nice,
and has a risk of forgetting to clear the style and having it apply to
subsequent messages, but it works.
This is only supported in the Browser for now. REPL support would
require parsing the CSS and figuring out the relevant ANSI codes. We
also don't filter this styling at all, so you can `position: absolute`
and `transform: translate(...)` all you want, which is less than
ideal.
Using a Vector<Value> is unsafe as GC cannot see the stored values.
This is then vended to outside users of ConsoleClient, e.g. LibWeb and
WebContent, which is then outside of LibJS's control.
An example issue is if the client stores it for later use and forgets
to visit the stored values, meaning they can be destroyed at any time.
We can save the client from this by vending a MarkedVector<Value> to
them.
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.
The spec very kindly defines `Printer` as accepting
"Implementation-specific representations of printable things such as a
stack trace or group." for the `args`. We make use of that here by
passing the `Trace` itself to `Printer`, instead of having to produce a
representation of the stack trace in advance and then pass that to
`Printer`. That both avoids the hassle of tracking whether the data has
been html-encoded or not, and means clients don't have to implement the
whole `trace()` algorithm, but only the code needed to output the trace.
The `CountReset` log level is displayed as a warning, since the message
is always to warn that the counter doesn't exist. This is also in line
with the table at https://console.spec.whatwg.org/#loglevel-severity
This implements the Logger and Printer abstract operations defined in
the console spec, and stubs out the Formatter AO. These are then used
for the "output a categorized log message" functions.
SPDX License Identifiers are a more compact / standardized
way of representing file license information.
See: https://spdx.dev/resources/use/#identifiers
This was done with the `ambr` search and replace tool.
ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
This flag warns on classes which have `virtual` functions but do not
have a `virtual` destructor.
This patch adds both the flag and missing destructors. The access level
of the destructors was determined by a two rules of thumb:
1. A destructor should have a similar or lower access level to that of a
constructor.
2. Having a `private` destructor implicitly deletes the default
constructor, which is probably undesirable for "interface" types
(classes with only virtual functions and no data).
In short, most of the added destructors are `protected`, unless the
compiler complained about access.
