In order to introduce a third type of context for the WatcherActor, it would be benefitial to introduce a object passed around everywhere around the WatcherActor that would help described what we should debug/expose.

A "context" object store on the Watcher Actor, with a type attribute that could be:

• "all" for the browser toolbox, which should debug everything
• "browser-element" for tab debugging, which should debug only one given browser-element
  And in a near future:
• "web-extension" for add-on debugging, and somehow debugging the right browser-element's related to the add-on.
• "service-worker" for debugging workers from about:debugging
  Alongside this type attribute, we may have as many useful attribute specific to each context type.
  type: "all" would most likely not require anything else,
  but type: "browser-element" would benefit from a browserId attribute to identify the one <browser> element we want to target.

Also, this context object will be transfered to content processes and worker threads, so we should keep in mind to keep it serializable.

This is only the beginning, focusing first on parent process usages.
WatcherActor still expose browserElement shortcut as it is useful in many places.
Context is kept JSON-serializable in order to later pass it through the SessionData.

This is the second and last step, to propagate the context down to the content process.
So that now, whenever we introduce a new context or add something into it,
it should be automatically made available to the whole codebase.

Backed out 3 changesets (Bug 1735825) for causing bc failures on browser_ext_devtools_inspectedWindow.js.
Backout link
Push with failures
Failure Log

https://hg.mozilla.org/mozilla-central/rev/2e494aaf92a8
https://hg.mozilla.org/mozilla-central/rev/e155545942a8
https://hg.mozilla.org/mozilla-central/rev/87a72f8dd901