1644188 - Implement Javascript Sources listening via the ResourceWatcher API on the actor side

Status: RESOLVED FIXED

(DevTools :: Debugger, enhancement, P1)

Description

[Alexandre Poirot [:ochameau]]

The goal here is to implement the SOURCE resource from the actor side.
This is about replicating the current behavior, implemented in bug 1620280.
But instead of having a wrapper on the client side to morph the legacy ThreadFront methods (i.e. the legacy listener code),
we would implement an actor API matching ResourceWatcher API (i.e. watch and unwatch).

This would be about implementing a server side equivalent of this legacy listener code:
https://searchfox.org/mozilla-central/source/devtools/shared/resources/legacy-listeners/sources.js
In a new server side module:
https://searchfox.org/mozilla-central/source/devtools/server/actors/resources/sources.js

This module would typicaly look like this:

const { TYPES } = require("devtools/server/actors/resources/index");

class MyResourceWatcher {
  /**
   * Start watching for all ${MY_RESOURCE_TYPE} related to a given Target Actor.
   * This will notify about existing ${MY_RESOURCE_TYPE}, but also the one created in future.
   *
   * @param TargetActor targetActor
   *        The target actor from which we should observe console messages
   * @param Object options
   *        Dictionary object with following attributes:
   *        - onAvailable: mandatory function
   *          This will be called for each resource.
   */
  constructor(targetActor, { onAvailable }) {
    // In most cases, we already have some helper class which helps observing one resource
    // that we can spawn like this:
    // Note that it may often be easier to merge such `MyResourceListener` into this `MyResourceWatcher` class!
    const listener = new MyResourceListener(
      targetActor.browsingContextID,
      targetActor.window,
      ...  /* whatever is useful for your observation */
    );
    
    // Forward all future resources being observed to the upper layer calling this module,
    // via `onAvailable` callback argument.
    // I'm using EventEmitter API here, but the API may different,
    // based on the platform API we have to use to observe the resource.
    listener.on("one-of-my-resource-is-created", resource => {
      // We have to ensure that each resource object has a valid `resourceType` attribute
      resource.resourceType = TYPES.MY_RESOURCE_TYPE;
      onAvailable([resource]);
    });
    
    // Also forward all resources which already exist when we are calling this method
    // (if any exists)
    const cachedResources = listener.getAllAlreadyExistingOrCachedResources();
    for(const resource of cachedResources) {
      resource.resourceType = TYPES.MY_RESOURCE_TYPE;
    }
    onAvailable(cachedResources);
    
    // Save the listener in order to destroy/stop watching later on.
    this.listener = listener;
  }

  /**
   * Stop watching for ${MY_RESOURCE_TYPE}.
   */
  destroy() {
    if (this.listener) {
      this.listener.destroy();
    }
  }
}
module.exports = MyResourceWatcher;

An important goal here is to emit the exact same resource object that the legacy listener is passing to its onAvailable callback.
Same attributes, same values, ...

Bug 1644185 could be used as a template. As it did this work for PLATFORM_MESSAGE resource type.

The main reason to do this is to be able to start listening to the resource before the page starts loading.
Thanks to the framework work done in bug 1620243, this MyResourceWatcher class will be instantiated before the page starts
loading and possibly as early as the content process just started.
This wasn't the case with legacy actor APIs like WebConsoleActor.startListeners, ThreadActor.attachThread, ...
We were calling these methods too late, only after the frontend is notify about the existance of the target, so, late after the page started loading.

You will also have to register this new module in this registry:
https://searchfox.org/mozilla-central/source/devtools/server/actors/resources/index.js

• Add a new entry in TYPES object.
• Register your new resource watcher module into Resources object.

Last but not least, it is probably a good time to review the existing tests for this Resource:
https://searchfox.org/mozilla-central/source/devtools/shared/resources/tests
And ensure that it has a good coverage.
You would especially have to migrate all Client/Front tests, which were testing the backend behavior via targetFront.getFront("myfront").
All these tests will be removed, once we drop the legacy listeners. Because we are going to drop the server API that we no longer use.
Like WebConsoleActor/Front.getCachedMessage(), WebConsoleActor/Front.startListeners(), ThreadActor/Front.sources(), ThreadActor/Front.new-source, ...

Comment 1

[Chris Peterson [:cpeterson]]

Tracking dt-fission-m2 bugs for Fission Nightly (M6c)

Comment 2

[Alexandre Poirot [:ochameau]]

Before being able to enable the trait related to this resource, we probably have to support all types of targets in the server side/Watcher Actor.
So we might have to wait for bug 1608848 full completion before being able to use it.
Otherwise, I think we will miss sources for all target types that the Watcher Actor doesn't support.
As of today, it would only emit sources for the top level and frame targets. This would miss worker and process resources.

Comment 3

[Alexandre Poirot [:ochameau]]

Attachment: Bug 1644188 - [devtools] Implement server side JS sources.

Comment 4

[Alexandre Poirot [:ochameau]]

I confirm last comment 2, worker sources do not work with a SourceWatcher, because we don't have support for workers in WatcherActor.
So I'll at least block on top of bug 1633712, but we might have to block meta bug 1608848

Comment 5

[Neha Kochar [:neha]]

Bulk move of all m2-mvp devtools bugs to Fission M7.

Comment 6

[Alexandre Poirot [:ochameau]]

Attachment: Bug 1644188 - [devtools] Prevents watching for resources we no longer watch on target switching.

This code in ResourceWatcher was forcing to watch resources we stopped listening to
when the target was switching.

Comment 7

[Alexandre Poirot [:ochameau]]

Attachment: Bug 1644188 - [devtools] Test Service Worker JS sources watching.

This helps cover the workaround put in ResourceWatcher in order to trigger
the SOURCE legacy listener for targets that we don't yet support in the Watcher actor.

Comment 8

[Alexandre Poirot [:ochameau]]

https://treeherder.mozilla.org/jobs?repo=try&selectedTaskRun=HgikjiA7RFeP8OHFJKv3Jw.0&revision=fe9485f6de60e08969c87d8265c48ca3633628ff

Comment 9

[Alexandre Poirot [:ochameau]]

Attachment: Bug 1644188 - [devtools] Unregister service worker in all resourceWatcher/targetList tests.

Not doing that, makes the browser_resources_sources.js test to fail because
of pending SW's target which comes with unexpected sources.

Comment 10

[Alexandre Poirot [:ochameau]]

Attachment: Bug 1644188 - Try to wait for shared worker initialization

But that doesn't fix my failure....

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c61679d53217
[devtools] Implement server side JS sources. r=jdescottes,nchevobbe
https://hg.mozilla.org/integration/autoland/rev/58c6e9f03741
[devtools] Prevents watching for resources we no longer watch on target switching. r=jdescottes
https://hg.mozilla.org/integration/autoland/rev/08f2b685d56f
[devtools] Test Service Worker JS sources watching. r=jdescottes
https://hg.mozilla.org/integration/autoland/rev/477fb178aa56
[devtools] Unregister service worker in all resourceWatcher/targetList tests. r=jdescottes

Comment 12

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/c61679d53217
https://hg.mozilla.org/mozilla-central/rev/58c6e9f03741
https://hg.mozilla.org/mozilla-central/rev/08f2b685d56f
https://hg.mozilla.org/mozilla-central/rev/477fb178aa56