1900706 - Expose equivalent of nsContentUtils::ReportToConsole on nsIGlobalObject

Status: ASSIGNED

(Core :: DOM: Core & HTML, enhancement)

Description

[Andrew Sutherland [:asuth] (he/him)]

nsContentUtils::ReportToConsole is a commonly used helper to report informative messages to the devtools console that are not appropriate to surface via ErrorResult / Error objects. But it has been Document*/WindowID-specific and until bug 1806390 landed in 2022-12 main-thread-specific (however it's still a bad idea to use off main-thread as implemented[1]) and this has led to a disparate number of hacks and things that simply aren't reliably reported to devtools when Service Workers, Shared Workers, or to a lesser extent, Dedicated Workers are involved. Exposing a variant of this method on nsIGlobalObject will let us initially consolidate the hacks and simplify the longer term cleanup / evolution of this functionality.

The implementation plan here is a minimal implementation in support of bug 1131324 to simply bounce to the main thread and report things to the console service based on a minor enhancment of the existing async WorkerPrivate::ReportErrorToConsole flow. This will provide support for dedicated workers registering ServiceWorkers. Follow-ups will handle the larger, more systemic problems referenced in the bug survey section below.

1: nsContentUtils::FormatLocalizedString gets called by ReportToConsole and if you're OMT it will create and dispatch FormatLocalizedStringRunnable which is a WorkerMainThreadRunnable which will block the worker thread with a nested syncloop until the runnable gets to run on the main thread. The rationale for that suggests this can be improved. Note that the motivating use-case was for the worker scriptloader which then/now/but-not-soon does a ton of main-thread dependent logic, so it wasn't really a problem for that caller, but in the general case the async ReportErrorToConsoleRunnable used by mozilla::dom::WorkerPrivate::ReportErrorToConsole is better for steady-state worker code if we can't confidently fix the string bundle issue.

Context

There's a common use-case where we want to report informative messages to the devtools console UI for the benefit of web developers or users reporting problems to web developers, but where we don't want the messages reported to content because they leak information that has privacy and/or security implications so the information can't be reported as part of the normal ErrorResult. For example, a number of things related to ServiceWorkers, fetch, and "no-cors" opaque responses intentionally throw homogeneous NetworkErrors, but it's okay to expose potentially useful debugging information to the user.

Traditionally we've used the nsIConsoleService for this, but it's main-thread only, which means it has only been suitable for window/document-reported errors and workers have had to bounce their reports to the main thread. However, with e10s and fission and the implementation of the RemoteWorker subsystem, it became the case that ServiceWorkers and SharedWorkers potentially are spawned in different processes than the process the tab that devtools is open for is in. Additionally there are also complications related to determining when a ServiceWorker is related to things happening in a tab. For these RemoteWorker cases, it makes sense for the messages to either be plumbed up to the parent process where they can be reported, or for them to be reported directly into the dom::Console that devtools can attach to.

Because devtools has frequently had to pragmatically make do with how the system operates, devtools frequently already finds itself listening for everything going on in every process with potentially complex filters.

Brief bug survey in this space

(This is for my benefit for follow-ups in this space.)

• Bug 1876530 covers devtools automatically attaching to workers to extract message directly from dom::Console. That is coupled to bug 1674342 which is a meta-bug about removing the dom.worker.console.dispatch_events_to_main_thread pref which determines if dom::Console::MethodInternal will structured clone logged messages and send them to the main thread where they will be reported to nsIConsoleAPIStorage which is an interface implemented by ConsoleAPIStorage.sys.mjs. (Which is distinct from nsIConsoleService.idl which is implemented by nsConsoleService and is what ReportToConsole uses.)
• Bug 1836707 is about introducing nsIServiceWorkerManager::CreateBrowsingContextFilter to help address the situations where we want to be logging console messages related to ServiceWorkers but where things have regressed since sw-e10s (or never were particularly great). (This is also of increased importance since our efforts for RemoteWorkers and particularly ServiceWorkers to not involve the main thread of the process they are on for performance and correctness reasons makes it harder to safely/sanely expose things to devtools on the main thread.) Notable bugs related to this which have had notable discussion:
  • Bug 1429805 - "display service worker console messages on related windows in different child processes"
  • Bug 1604543 - "ServiceWorkerManager::ReportToAllClients needs to be updated for sw-e10s [syntax errors in script evaluation receive the reported-to-content MSG_SW_INSTALL_ERROR but not the syntax errors]"
  • Impl Note: ReportToAllClients uses ConsoleUtils introduced in bug 1429174 which is also used by (nsI)ConsoleReportCollector which (diagram) is hooked up to fetch and HttpBaseChannel with (diagram) messages added by a few places. The mechanism used by SWM reports to nsIConsoleAPIStorage and is itself inherently main-thread-only. FetchChild (which can run on workers) obtains a ThreadSafeWorkerRef and then dispatches a runnable to the main thread to add the reports and then flushes them, but in a weird asymmetry, it calls into ConsoleReportCollector::FlushReportsToConsole which calls into nsContentUtils::ReportToConsoleByWindowID which uses the console service.
• Bug 1271441 - "Need to fix console reporting and whatnot in the worker error reporter" is about the actual error reporting to content for workers in terms of error bubbling and the devtools global/compartment, which is a slightly different situation, but worth noting here.
  • Bug 1872483 - "Web Worker ES Module Import Error is not displayed" is related and is about how we're bubbling a useless Error object onto the Worker binding.

Bugs related to directly emitting information to dom::Console:

• Bug 1826681 is the initial source of mozilla::webgpu::reportCompilationMessagesToConsole which I think may be the only code in the tree that directly logs informational messages of this type via dom::Console.

Comment 1

[Andrew Sutherland [:asuth] (he/him)]

Attachment: Bug 1900706 - Expose equivalent of nsContentUtils::ReportToConsole on nsIGlobalObject. r=smaug!