1346316 - Browser Content Toolbox should expose focused tab in the console

Status: NEW

(DevTools :: General, enhancement, P3)

Description

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

We have a Browser Content Toolbox for accessing chrome JS in the child process.

However, the console there is somewhat limited, because it doesn't point to any content window.  Instead, it's an empty sandbox.

We could make this a better experience by exposing an actual tab somehow, such as the `content` global for the window (seen from a frame script).  We may also want to denote the tab it's pointing at in the window title or something.

[1]: http://searchfox.org/mozilla-central/source/devtools/server/actors/child-process.js#35

Comment 1

[:Gijs (he/him)]

Would this be something that could be prioritized to make browser (chrome) debugging etc. a bit easier? :-)

Comment 2

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

(In reply to :Gijs from comment #1)
> Would this be something that could be prioritized to make browser (chrome)
> debugging etc. a bit easier? :-)

Sure, I'll try to look into this once I've wrapped up Q1 goals.

Comment 3

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Attachment: Bug 1346316 - Expose content frame global in Browser Content Toolbox.

This makes the Browser Content Toolbox much more convenient by exposing the same
environment a frame script for the currently selected browser would have access
to, which simplifies exploring the content process state in many cases, since
you no longer have to go digging around for the right objects.

Review commit: https://reviewboard.mozilla.org/r/131400/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/131400/

Comment 4

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Attachment: Bug 1346316 - Add URL and title to Browser Content Toolbox.

Review commit: https://reviewboard.mozilla.org/r/131402/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/131402/

Comment 5

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=607d84866a99ac5c7189d5ca841b9d0fecc3ed72

Comment 6

[Alexandre Poirot [:ochameau]]

Comment on attachment 8859374 [details]
Bug 1346316 - Expose content frame global in Browser Content Toolbox.

https://reviewboard.mozilla.org/r/131400/#review134820

Thanks for looking into this!

This goes against the definition of ChildProcessActor.
It should be implemented against a process and not just a given document.
(If it was just me, for the Browser Content Toolbox, we would get rid of ChildProcessActor and use a TabActor instead. With the frame switching feature, we can always get back to another tab if we happen to close the currently debugged one)

I think it makes sense to expose helpers, but I would do it more generic and not related to one arbitrary document. With this patch, things get weird if you happen to close the debugged document. `content` becomes null and you can't reach any other tab.
I see two options:
* expose the list of all TabChildGlobals over a new API:
  sandboxPrototype = {
    get tabs() {
      // return the list of all TabChildGlobals/nsIContentFrameMessageManager
    }
  };
* do something similar to what you did but exposing whatever is the currently active document
  sandboxPrototype = {
    get content() {
      // return the window object of the currently opened tab
    },
    get docShell() {
      // Same, but returns the docshell object
    }
  };

In case you don't know, you can iterate over tabs like this, and also identify the currently opened tab via docshell.isActive:
  let e = Services.ww.getWindowEnumerator(null);
  while (e.hasMoreElements()) {
    let window = e.getNext();    
    let docshell = window.QueryInterface(Ci.nsIInterfaceRequestor).
      getInterface(Ci.nsIDocShell).
      sameTypeRootTreeItem.
      QueryInterface(Ci.nsIDocShell);
    if (docshell.isActive) {
      // Is the currently opened tab
    }
    let tabchildglobal = docshell.QueryInterface(Ci.nsIInterfaceRequestor).
      getInterface(Ci.nsIContentFrameMessageManager);
    ...
  }

We can surely mix the two options or do something slightly different with better names/API.
The important point is about supporting more than just one tab and also ease the final implementation of this patch by not having to pass outerWindowID everywhere.

Comment 7

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Okay, I'll look into making this more robust.  I think switching the TabActor / frame switching style is probably the more natural way to go.

Looks like I can use the "visibilitychange" event to watch for changes in the active docShell as well.

Comment 8

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

The change in bug 1401343 is probably "good enough" for now.  I don't plan to work on this further at the moment.