Display console API messages from shared or service workers to the web console

RESOLVED FIXED in Firefox 40

Status

defect
P1
normal
RESOLVED FIXED
4 years ago
22 days ago

People

(Reporter: past, Assigned: baku)

Tracking

(Depends on 1 bug)

Trunk
Firefox 40
Dependency tree / graph

Firefox Tracking Flags

(firefox40 fixed, relnote-firefox 40+)

Details

(Whiteboard: [polish-backlog])

Attachments

(1 attachment, 2 obsolete attachments)

Bug 1058644 enabled console API calls from shared and service workers. As these messages come from workers, they don't have any window ID associated with them. Web developers however, would expect to see them in the web console, as that is where they see all messages from their app.

These worker messages come with the "SharedWorker" or "ServiceWorker" inner ID (like the "jsm" ID used by Console.jsm) and the filename of the worker as the outer ID. The idea is that the web console would show these messages iff the worker filename matches one of the scripts loaded in the page.

That would require the web console to have some code that asks the debugger for the list of scripts, or obtain it directly from the thread actor. I think the first option is preferable. The console currently directly adds the content window as a debuggee in order to perform its own limited actions that require the Debugger API. This could be another instance of that pattern. The only caveat is that dbg.findScripts() is often slow and perhaps we wouldn't be able to do it for each worker message that arrives. Maybe findSources() (still unimplemented) would help here, or maybe we need to add a new query term to findScripts() to filter out non-worker scripts.
(Assignee)

Comment 1

4 years ago
The worker messages has 'SharedWorker', 'ServiceWorker' or 'Worker' in the innerID.
It can happen that the type is 'Worker' when a SharedWorker or a ServiceWorker (or a ChromeWorker) create a sub-Worker.

Btw would be nice to rename innerID to something more descriptive.
(Assignee)

Comment 2

4 years ago
Posted patch c.patch (obsolete) — Splinter Review
It doesn't seem super-clean and I'm open to a better approach.
Attachment #8596129 - Flags: review?(past)
(Assignee)

Comment 3

4 years ago
Posted patch c.patch (obsolete) — Splinter Review
Attachment #8596129 - Attachment is obsolete: true
Attachment #8596129 - Flags: review?(past)
Attachment #8596440 - Flags: review?(past)
Comment on attachment 8596440 [details] [diff] [review]
c.patch

Review of attachment 8596440 [details] [diff] [review]:
-----------------------------------------------------------------

This looks good, but I have a few comments. Do you have a demo page that I could use to play with this? Nothing useful came up in my (very) brief search.

Using a new dropdown menu doesn't seem right. The checkboxes control the console logging API, which has its own Logging menu. You could just add the new options there, using a separator to distinguish them from the log level options above.

We also need a test for this, perhaps something like browser_webconsole_console_logging_api.js?

::: browser/app/profile/firefox.js
@@ +1562,5 @@
>  pref("devtools.browserconsole.filter.secerror", true);
>  pref("devtools.browserconsole.filter.secwarn", true);
> +pref("devtools.browserconsole.filter.serviceworkers", false);
> +pref("devtools.browserconsole.filter.sharedworkers", false);
> +pref("devtools.browserconsole.filter.windowlessworkers", false);

I think we want the worker logging enabled in the browser console by default, just like everything else. It's the place where people expect to see everything that went wrong with the browser.

::: browser/devtools/webconsole/webconsole.js
@@ +138,5 @@
>    count: SEVERITY_LOG
>  };
>  
> +// List of the ConsoleEvent.innerID for workers.
> +const WORKERTYPES_NAMES = [ 'SharedWorker', 'ServiceWorker', 'Worker' ];

This should be imported from utils.js.

@@ +141,5 @@
> +// List of the ConsoleEvent.innerID for workers.
> +const WORKERTYPES_NAMES = [ 'SharedWorker', 'ServiceWorker', 'Worker' ];
> +
> +// This array contains the prefKey for the workers and it must be in sync with
> +// the previous one.

How about we clarify that it's the order that is important, with perhaps something like "...and it must keep them in the same order as the previous one"?

::: browser/locales/en-US/chrome/browser/devtools/webConsole.dtd
@@ +91,5 @@
> +  -  should not be translated. -->
> +<!ENTITY btnConsoleServiceWorkers "Service Workers">
> +<!-- LOCALIZATION NODE (btnConsoleWindowlessWorkers) the term "Workers"
> +  -  should not be translated. -->
> +<!ENTITY btnConsoleWindowlessWorkers "Workers from addons or from JSM scripts">

This seems a bit wordy. How about "Add-on or Chrome Workers"?

::: toolkit/devtools/server/actors/webconsole.js
@@ +45,5 @@
>      enumerable: true
>    });
>  }
>  
> +const WORKERS_IDS = [ 'SharedWorker', 'ServiceWorker', 'Worker' ];

These should be referenced from utils.js, provided you export them and import them in the block right above.

@@ +1435,5 @@
>    {
>      let result = WebConsoleUtils.cloneObject(aMessage);
> +
> +    result.workerType = WORKERS_IDS.indexOf(result.innerID) == -1
> +                          ? 'none' : result.innerID;

In general the Remote Debugging Protocol strives to be easy to inspect by humans, so we tend to use self-explanatory strings instead of number IDs where possible. Do you think that you could just use the workerID name here and then look it up in the client?

::: toolkit/devtools/webconsole/utils.js
@@ +1422,5 @@
>  
>    /**
> +   * List of the worker IDs for the ConsoleEvent
> +   */
> +  workersIDs: [ 'SharedWorker', 'ServiceWorker', 'Worker' ],

Nit: I think workerIDs is better.

@@ +1499,5 @@
>        messages = messages.filter((m) => m.consoleID == this.consoleID);
>      }
>  
> +    messages = messages.sort(function(a, b) {
> +      return a.timeStamp - b.timeStamp;

I assume we need to sort the messages because we are multiplexing events from different threads? It would be good to add a comment in any case.
Attachment #8596440 - Flags: review?(past)
Assignee: nobody → amarchesini
Status: NEW → ASSIGNED
Priority: -- → P1
Whiteboard: [devedition-40]
(Assignee)

Comment 5

4 years ago
Posted patch c.patchSplinter Review
Attachment #8596440 - Attachment is obsolete: true
Attachment #8596612 - Flags: review?(past)
(Assignee)

Comment 6

4 years ago
> > +    result.workerType = WORKERS_IDS.indexOf(result.innerID) == -1
> > +                          ? 'none' : result.innerID;
> 
> In general the Remote Debugging Protocol strives to be easy to inspect by
> humans, so we tend to use self-explanatory strings instead of number IDs
> where possible. Do you think that you could just use the workerID name here
> and then look it up in the client?

Oh yes, it is. We use the IDs of workers but they are strings.

> > +    messages = messages.sort(function(a, b) {
> > +      return a.timeStamp - b.timeStamp;
> 
> I assume we need to sort the messages because we are multiplexing events
> from different threads? It would be good to add a comment in any case.

No, the reason why I'm sorting them is that we get, first all the events for the window, then the events for the SharedWorkers, ServiceWorkers and ChromeWorkers. But they are not sorted by timeStamp. They are just concatenated. Better to put them in the correct order before showing them.
Comment on attachment 8596612 [details] [diff] [review]
c.patch

Review of attachment 8596612 [details] [diff] [review]:
-----------------------------------------------------------------

Minor nits only, this looks good, thanks!

::: browser/devtools/webconsole/test/browser_webconsole_console_logging_workers_api.js
@@ +1,4 @@
> +/* vim:set ts=2 sw=2 sts=2 et: */
> +/* This Source Code Form is subject to the terms of the Mozilla Public
> + * License, v. 2.0. If a copy of the MPL was not distributed with this
> + * file, You can obtain one at http://mozilla.org/MPL/2.0/. */

Nit: we generally use the Public Domain (CC0) license for test files.

::: browser/devtools/webconsole/test/test-console-workers.html
@@ +1,5 @@
> +<!DOCTYPE HTML>
> +<html dir="ltr" xml:lang="en-US" lang="en-US"><head>
> +    <meta charset="utf-8">
> +    <title>Console test</title>
> +  </head>

Nit: forgot to include the CC0 license comment in this file.

::: browser/devtools/webconsole/webconsole.js
@@ +138,5 @@
>    count: SEVERITY_LOG
>  };
>  
> +// List of the ConsoleEvent.innerID for workers.
> +const WORKERTYPES_NAMES = require("devtools/toolkit/webconsole/utils").CONSOLE_WORKER_IDS;

There is another require(".../utils") in the beginning of the file and you could combine them using destructuring assignment like this:

const { WebConsoleUtils, CONSOLE_WORKER_IDS } = require(".../utils");

::: toolkit/devtools/webconsole/utils.js
@@ +1495,5 @@
>      if (this.consoleID) {
>        messages = messages.filter((m) => m.consoleID == this.consoleID);
>      }
>  
> +    messages = messages.sort(function(a, b) {

You didn't add a brief comment about the reason for sorting.
Attachment #8596612 - Flags: review?(past) → review+
(Assignee)

Updated

4 years ago
Blocks: 1158264
(Assignee)

Comment 10

4 years ago
Talking with :past, he suggested to mark this bug for relnote, but maybe this is part of a bigger picture about ServiceWorkers. Ehsan?
Flags: needinfo?(ehsan)

Comment 11

4 years ago
(In reply to Andrea Marchesini (:baku) from comment #10)
> Talking with :past, he suggested to mark this bug for relnote, but maybe
> this is part of a bigger picture about ServiceWorkers. Ehsan?

We'll most likely look at shipping service workers in 41, and also I think this would be a nice thing to relnote on its own since it affects also shared workers.
Flags: needinfo?(ehsan)
(Assignee)

Comment 12

4 years ago
Release Note Request (optional, but appreciated)
[Why is this notable]: With this patch we display any use of the console API from ServiceWorkers, SharedWorkers and Add-on/JSM Workers.
relnote-firefox: --- → ?
https://hg.mozilla.org/mozilla-central/rev/c8f9adecb1bc
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 40
Release Note Request (optional, but appreciated)
[Why is this notable]:  See comment 12
[Suggested wording]: Console API messages from SharedWorker and ServiceWorker are now displayed in web console
[Links (documentation, blog post, etc)]:
Whiteboard: [devedition-40] → [polish-backlog]
Depends on: 1213932
Depends on: 1221772

Updated

10 months ago
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.