Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-12-08 06:09:58 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Services/WebContent/WebContentConsoleClient.h

64 lines
1.6 KiB
C
Raw Normal View History

WebContent: Added IPC calls for initializing JS console and sending input
2021-02-27 21:44:49 -06:00
/*
* Copyright (c) 2021, Brandon Scott <xeon.productions@gmail.com>
* Copyright (c) 2020, Hunter Salyer <thefalsehonesty@gmail.com>
WebContent: Create a separate realm for JS console input This allows us to expose extra functions and properties to the console, such as `$0`, without them being available to website scripts. `ConsoleEnvironmentSettingsObject` is basically a stub, since we require an `EnvironmentSettingsObject` but it has abstract methods.
2022-11-19 16:12:19 +00:00
* Copyright (c) 2021-2022, Sam Atkins <atkinssj@serenityos.org>
WebContent: Added IPC calls for initializing JS console and sending input
2021-02-27 21:44:49 -06:00
*
Everything: Move to SPDX license identifiers in all files. 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 *
2021-04-22 01:24:48 -07:00
* SPDX-License-Identifier: BSD-2-Clause
WebContent: Added IPC calls for initializing JS console and sending input
2021-02-27 21:44:49 -06:00
*/
#pragma once
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 18:00:48 -07:00
#include <AK/Vector.h>
WebContent: Added IPC calls for initializing JS console and sending input
2021-02-27 21:44:49 -06:00
#include <LibJS/Console.h>
#include <LibJS/Forward.h>
LibWebView+WebContent: Create a different console client for DevTools Our existing WebContentConsoleClient is very specific to our home-grown Inspector. It renders console output to an HTML string. For DevTools, we will not want this behavior; we will want to send representations of raw JS values. This patch makes WebContentConsoleClient a base class to handle console input from the user, either from the Inspector or from DevTools. It then moves the HTML rendering needed for the Inspector to a new class, InspectorConsoleClient. And we add a DevToolsConsoleClient (currently just stubbed) to handle needs specific to DevTools. We choose at runtime which console client to install, based on the --devtools command line flag.
2025-02-24 09:48:13 -05:00
#include <LibJS/Runtime/Value.h>
WebContent: Added IPC calls for initializing JS console and sending input
2021-02-27 21:44:49 -06:00
#include <LibWeb/Forward.h>
#include <WebContent/Forward.h>
namespace WebContent {
LibWebView+WebContent: Create a different console client for DevTools Our existing WebContentConsoleClient is very specific to our home-grown Inspector. It renders console output to an HTML string. For DevTools, we will not want this behavior; we will want to send representations of raw JS values. This patch makes WebContentConsoleClient a base class to handle console input from the user, either from the Inspector or from DevTools. It then moves the HTML rendering needed for the Inspector to a new class, InspectorConsoleClient. And we add a DevToolsConsoleClient (currently just stubbed) to handle needs specific to DevTools. We choose at runtime which console client to install, based on the --devtools command line flag.
2025-02-24 09:48:13 -05:00
class WebContentConsoleClient : public JS::ConsoleClient {
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC_CELL(WebContentConsoleClient, JS::ConsoleClient);
GC_DECLARE_ALLOCATOR(WebContentConsoleClient);
LibJS+LibWeb: Make Console, ConsoleClient & subclasses GC-allocated These objects had confusing ownership semantics. Let's just throw them all on the GC heap and stop worrying about it.
2024-04-20 21:19:51 +02:00
WebContent: Added IPC calls for initializing JS console and sending input
2021-02-27 21:44:49 -06:00
public:
LibJS+LibWeb: Make Console, ConsoleClient & subclasses GC-allocated These objects had confusing ownership semantics. Let's just throw them all on the GC heap and stop worrying about it.
2024-04-20 21:19:51 +02:00
virtual ~WebContentConsoleClient() override;
WebContent: Added IPC calls for initializing JS console and sending input
2021-02-27 21:44:49 -06:00
LibWebView+WebContent: Port JS console handling to String
2025-02-23 08:57:40 -05:00
void handle_input(StringView js_source);
WebContent: Added IPC calls for initializing JS console and sending input
2021-02-27 21:44:49 -06:00
LibWebView+WebContent: Create a different console client for DevTools Our existing WebContentConsoleClient is very specific to our home-grown Inspector. It renders console output to an HTML string. For DevTools, we will not want this behavior; we will want to send representations of raw JS values. This patch makes WebContentConsoleClient a base class to handle console input from the user, either from the Inspector or from DevTools. It then moves the HTML rendering needed for the Inspector to a new class, InspectorConsoleClient. And we add a DevToolsConsoleClient (currently just stubbed) to handle needs specific to DevTools. We choose at runtime which console client to install, based on the --devtools command line flag.
2025-02-24 09:48:13 -05:00
virtual void handle_result(JS::Value) = 0;
virtual void send_messages(i32 start_index) = 0;
LibJS+LibWeb: Make Console, ConsoleClient & subclasses GC-allocated These objects had confusing ownership semantics. Let's just throw them all on the GC heap and stop worrying about it.
2024-04-20 21:19:51 +02:00
LibWebView+WebContent: Create a different console client for DevTools Our existing WebContentConsoleClient is very specific to our home-grown Inspector. It renders console output to an HTML string. For DevTools, we will not want this behavior; we will want to send representations of raw JS values. This patch makes WebContentConsoleClient a base class to handle console input from the user, either from the Inspector or from DevTools. It then moves the HTML rendering needed for the Inspector to a new class, InspectorConsoleClient. And we add a DevToolsConsoleClient (currently just stubbed) to handle needs specific to DevTools. We choose at runtime which console client to install, based on the --devtools command line flag.
2025-02-24 09:48:13 -05:00
protected:
WebContentConsoleClient(JS::Realm&, JS::Console&, PageClient&, ConsoleGlobalEnvironmentExtensions&);
WebContent: Added IPC calls for initializing JS console and sending input
2021-02-27 21:44:49 -06:00
LibWebView+WebContent: Create a different console client for DevTools Our existing WebContentConsoleClient is very specific to our home-grown Inspector. It renders console output to an HTML string. For DevTools, we will not want this behavior; we will want to send representations of raw JS values. This patch makes WebContentConsoleClient a base class to handle console input from the user, either from the Inspector or from DevTools. It then moves the HTML rendering needed for the Inspector to a new class, InspectorConsoleClient. And we add a DevToolsConsoleClient (currently just stubbed) to handle needs specific to DevTools. We choose at runtime which console client to install, based on the --devtools command line flag.
2025-02-24 09:48:13 -05:00
virtual void visit_edges(JS::Cell::Visitor&) override;
Browser+WebContent+LibJS: Support `%c` specifiers in Console.log() ...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.
2022-09-20 18:23:04 +01:00
LibWebView+WebContent: Create a different console client for DevTools Our existing WebContentConsoleClient is very specific to our home-grown Inspector. It renders console output to an HTML string. For DevTools, we will not want this behavior; we will want to send representations of raw JS values. This patch makes WebContentConsoleClient a base class to handle console input from the user, either from the Inspector or from DevTools. It then moves the HTML rendering needed for the Inspector to a new class, InspectorConsoleClient. And we add a DevToolsConsoleClient (currently just stubbed) to handle needs specific to DevTools. We choose at runtime which console client to install, based on the --devtools command line flag.
2025-02-24 09:48:13 -05:00
void print_html(String const& line);
WebContent: Implement ConsoleGlobalObject which proxies to WindowObject ConsoleGlobalObject is used as the global object when running javascript from the Browser console. This lets us implement console-only functions and variables (like `$0`) without exposing them to webpage content. It passes other calls over to the usual WindowObject so any code that would have worked in the webpage will still work in the console. :^)
2021-09-03 10:16:36 +01:00
LibWebView+WebContent: Create a different console client for DevTools Our existing WebContentConsoleClient is very specific to our home-grown Inspector. It renders console output to an HTML string. For DevTools, we will not want this behavior; we will want to send representations of raw JS values. This patch makes WebContentConsoleClient a base class to handle console input from the user, either from the Inspector or from DevTools. It then moves the HTML rendering needed for the Inspector to a new class, InspectorConsoleClient. And we add a DevToolsConsoleClient (currently just stubbed) to handle needs specific to DevTools. We choose at runtime which console client to install, based on the --devtools command line flag.
2025-02-24 09:48:13 -05:00
virtual void clear() override;
WebContent: Added IPC calls for initializing JS console and sending input
2021-02-27 21:44:49 -06:00
void clear_output();
LibWebView+WebContent: Create a different console client for DevTools Our existing WebContentConsoleClient is very specific to our home-grown Inspector. It renders console output to an HTML string. For DevTools, we will not want this behavior; we will want to send representations of raw JS values. This patch makes WebContentConsoleClient a base class to handle console input from the user, either from the Inspector or from DevTools. It then moves the HTML rendering needed for the Inspector to a new class, InspectorConsoleClient. And we add a DevToolsConsoleClient (currently just stubbed) to handle needs specific to DevTools. We choose at runtime which console client to install, based on the --devtools command line flag.
2025-02-24 09:48:13 -05:00
LibWebView+WebContent: Port JS console handling to String
2025-02-23 08:57:40 -05:00
void begin_group(String const& label, bool start_expanded);
LibJS+WebContent+Browser+js: Implement console.group() methods 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.
2021-12-22 12:32:15 +00:00
virtual void end_group() override;
WebContent: Store messages in WebContentConsoleClient The `WebContentConsoleClient` now keeps a list of console messages it has received, so these are not lost if the ConsoleWidget has not been initialized yet. This change does break JS console output, but only until the next commit. :^)
2021-09-04 11:45:36 +01:00
LibWebView+WebContent: Create a different console client for DevTools Our existing WebContentConsoleClient is very specific to our home-grown Inspector. It renders console output to an HTML string. For DevTools, we will not want this behavior; we will want to send representations of raw JS values. This patch makes WebContentConsoleClient a base class to handle console input from the user, either from the Inspector or from DevTools. It then moves the HTML rendering needed for the Inspector to a new class, InspectorConsoleClient. And we add a DevToolsConsoleClient (currently just stubbed) to handle needs specific to DevTools. We choose at runtime which console client to install, based on the --devtools command line flag.
2025-02-24 09:48:13 -05:00
GC::Ref<JS::Realm> m_realm;
GC::Ref<PageClient> m_client;
GC::Ref<ConsoleGlobalEnvironmentExtensions> m_console_global_environment_extensions;
WebContent: Store messages in WebContentConsoleClient The `WebContentConsoleClient` now keeps a list of console messages it has received, so these are not lost if the ConsoleWidget has not been initialized yet. This change does break JS console output, but only until the next commit. :^)
2021-09-04 11:45:36 +01:00
struct ConsoleOutput {
enum class Type {
HTML,
LibJS+WebContent+Browser+js: Implement console.group() methods 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.
2021-12-22 12:32:15 +00:00
Clear,
BeginGroup,
BeginGroupCollapsed,
EndGroup,
WebContent: Store messages in WebContentConsoleClient The `WebContentConsoleClient` now keeps a list of console messages it has received, so these are not lost if the ConsoleWidget has not been initialized yet. This change does break JS console output, but only until the next commit. :^)
2021-09-04 11:45:36 +01:00
};
Type type;
LibWebView+WebContent: Port JS console handling to String
2025-02-23 08:57:40 -05:00
String data;
WebContent: Store messages in WebContentConsoleClient The `WebContentConsoleClient` now keeps a list of console messages it has received, so these are not lost if the ConsoleWidget has not been initialized yet. This change does break JS console output, but only until the next commit. :^)
2021-09-04 11:45:36 +01:00
};
Vector<ConsoleOutput> m_message_log;
WebContent: Added IPC calls for initializing JS console and sending input
2021-02-27 21:44:49 -06:00
};
}
Reference in a new issue Copy permalink