Open Bug 1346316 Opened 6 years ago Updated 2 years ago

Browser Content Toolbox should expose focused tab in the console


(DevTools :: General, enhancement, P3)



(Not tracked)


(Reporter: jryans, Unassigned)


(Blocks 2 open bugs)



(2 files)

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.

Would this be something that could be prioritized to make browser (chrome) debugging etc. a bit easier? :-)
Flags: needinfo?(jryans)
(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.
Assignee: nobody → jryans
Flags: needinfo?(jryans)
Comment on attachment 8859374 [details]
Bug 1346316 - Expose content frame global in Browser Content Toolbox.

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).
    if (docshell.isActive) {
      // Is the currently opened tab
    let tabchildglobal = docshell.QueryInterface(Ci.nsIInterfaceRequestor).

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.
Attachment #8859374 - Flags: review?(poirot.alex)
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.
No longer blocks: 1401343
See Also: → 1401343
The change in bug 1401343 is probably "good enough" for now.  I don't plan to work on this further at the moment.
Assignee: jryans → nobody
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.