821345 - [toolbox] Detached remotable tools should update their target when the current browser tab changes

Status: RESOLVED DUPLICATE of bug 820524

(DevTools :: Framework, defect, P4)

Description

[Girish Sharma [:Optimizer]]

STR:
1. Open Web Console in an attached Toolbox. (Ctrl Shift K)
2. Detach the toolbox
3. Switch to another tab
4. Open the debugger by switching to its tab in the toolbox
5. The debugger shows scripts from the current selected tab, and not the tab from which the toolbox was detached.

Comment 1

[Paul Rouget [:paul]]

No need to go through the "detach" process to see this bug. Just ensure the toolbox is detached by default.

Comment 2

[Girish Sharma [:Optimizer]]

FWIW, this issue is only with Web Console and Debugger.

Comment 3

[Paul Rouget [:paul]]

I think the problem is all the references to gBrowser.selected(Tab|Browser) in DebuggerUI.jsm and HUDService.jsm:

> grep "selected\(Tab\|Browser\)" browser/devtools/{debugger,webconsole,inspector,styleeditor}/*

Comment 4

[Girish Sharma [:Optimizer]]

Yes, because the client (the toolbox ui) does not specifically tell the server about the exact tab to select. Previously, this was always the selected tab (unless done by JS) when done through the corresponding tool. But noq, as the tool can be detached from the tab, so hen any new tool is opened, the server still takes the selected tab as the target.

I overcame this issue in Timeline by adding the linkedPanel id for the tab in the hello message to the server. The server then traverse through all tabs and finds the correct tab to attach as target for the Timeline.

Inspector and Style Editor directly take the toolbox.target.tab as they are not meant for RDP yet.

Comment 5

[Panos Astithas (he/him) [:past] (please ni?)]

The problem is twofold. The first part stems from the fact that we haven't unified the debugger and console to use a single debugger client in the local/tab debugging case. There are still some TODOs left in the code to that effect. When each tool is selected it makes a new connection to the server, getting the selected tab at the time of the connection. This explains the fact that the tools get a different tab to work with.

The second part is that the console and the debugger cache the selected tab for the lifetime of the tool, since there was no need to retrieve it again in the pre-toolbox world. You can observe this by switching back and forth between the console's and the debugger's target tabs. This can be resolved by refetching the list of tabs when the toolbox receives focus again, after the user has switched tabs and goes back to the tools window.

I could work on this if Joe or someone else could take care of bug 820343.

Comment 6

[Paul Rouget [:paul]]

Joe, are you working on this?

Comment 7

[Joe Walker [:jwalker]]

I'm happy for Past to take this, I expect he knows the code better.

Comment 8

[Panos Astithas (he/him) [:past] (please ni?)]

(In reply to Panos Astithas [:past] from comment #5)
> The problem is twofold. The first part stems from the fact that we haven't
> unified the debugger and console to use a single debugger client in the
> local/tab debugging case. There are still some TODOs left in the code to
> that effect. When each tool is selected it makes a new connection to the
> server, getting the selected tab at the time of the connection. This
> explains the fact that the tools get a different tab to work with.

This part is bug 820524.

> The second part is that the console and the debugger cache the selected tab
> for the lifetime of the tool, since there was no need to retrieve it again
> in the pre-toolbox world. You can observe this by switching back and forth
> between the console's and the debugger's target tabs. This can be resolved
> by refetching the list of tabs when the toolbox receives focus again, after
> the user has switched tabs and goes back to the tools window.

I'll use this bug to fix this part.

Comment 9

[Panos Astithas (he/him) [:past] (please ni?)]

Going through my backlog, I looked again at this bug. The main problem identified here was fixed a long time ago in bug 820524, so I'm resetting priority to match reality.

Wondering what other developer tools do, I tried Chrome and Firebug. Chrome does exactly what we do, a detached toolbox doesn't change its target, while Firebug does something potentially more useful, but confusing as implemented: the detached toolbox follows the selected tab, but it's not enabled automatically, presenting an empty gray box with a button to enable it.

Doing what Firebug does is a lot of work for us, because we'll have to move tool state from the individual tool panels to a shared location, attached to the target. That is not necessarily a bad design decision, but I find the UX that it provides to be lacking. It's a very rare case in my experience to have multiple tabs open for debugging and wanting to switch among them. I've never heard from anyone else that they do that either. It's much more common for me to have a toolbox open for a tab I'm working on, and then decide to switch to the GMail tab or the IRCCloud tab for a bit, before resuming debugging in the first tab. If that interruption is long enough that I lose context of what I was doing, seeing the empty Firebug window only gives me the impulse to close it (I wouldn't go through my ~100 open tabs to see where it was opened), whereas our (or Chrome's) toolbox shows the URL on the title bar with the last open tool state intact. Re-attaching the toolbox to the tab again will also bring it to front, which is a fast way to get back to where I was.

For the reasons above I'm inclined to mark this bug as WONTFIX, but I'll leave it at P4 for now (patches accepted) in case others feel differently, or until we get a chance to discuss it.

Comment 10

[Joe Walker [:jwalker]]

I think this is so unlikely to get done that we should WONTFIX to save the repeated triage time.

Comment 11

[Girish Sharma [:Optimizer]]

I also agree that this should be WONTFIX.
Firebug's behavior is very confusing indeed. Firstly, it makes tab switching so heavy as loading/unloading of devtools will be involved.
Also, in some cases, we might want both the undocked toolbox targeting tab 1 along with the tab 2 itself open side by side for some cases, which is (to my knowledge) impossible with firebug's way of doing things.

The base problem, as mentioned by Panos, is already fixed in another bug.

I am instead marking this bug as duplicate of bug 820524