Open Bug 1163646 Opened 9 years ago Updated 4 years ago

Bring browser tab/window to the foreground from a detached toolbox

Categories

(DevTools :: General, defect, P3)

Product:
DevTools
Component:
General
Type:
defect

Tracking

(Not tracked)

People

(Reporter: pbro, Unassigned)

References

Details

Imagine the following scenario:

- the user chooses to use the detached toolbox (not docked inside the tab),
- the user works on several things at the same time, i.e. has several tabs/windows open at the same time, each with their own detached toolbox.

This means more than 1 browser+toolbox pairs, which means it's easy to get lost about which toolbox window corresponds to which tab or window.

Finding a way back from the browser tab/window to the toolbox is simple enough: make sure the expected tab/window is in the foreground, and press F12: this will bring the corresponding toolbox to the foreground (thanks to bug 999568).

Finding a way back from the toolbox to the browser tab/window isn't possible though. Not unless you cycle through your windows and, for example, hover over nodes in the toolbox to see if they become highlighted in the window.

This was suggested by juliandescottes, whom I'm going to cc here.

One idea would be to add a new (optional) toolbar button that would do just that: focus the tabActor window, so that it comes back to the foreground.
It would also be nice to make this remotable, e.g. when debugging Thunderbird. You'd have to instruct the remote application to bring itself in front of all other windows once.
You're right, this needs to go through the remote devtools protocol.

If the window is in a browser tab, we first need to make sure that tab is selected.
Once done, I believe chromeWindow.focus() should be enough to bring the window to the front.
On Internet Explorer's devtools, this is bound to F12.

If you press F12 from a detached devtool toolbox, it will focus the matching window/tab.
Currently, we close the devtools window when pressing F12, but I find IE's approach quite intuitive.
What about clicking 'pick an element' button?  Seems at that time you definitely will want the tab to be in focus so maybe we could at least start there.
(In reply to Brian Grinstead [:bgrins] from comment #5)
> What about clicking 'pick an element' button?  Seems at that time you
> definitely will want the tab to be in focus so maybe we could at least start
> there.

(I'm the one who asked about this on SO.)

I apologize, I don't understand exactly what you mean.  Would I need to click on the 'pick an element' button for the browser's focus to change, or do you mean, perhaps, if I mouse over the 'pick' button the browser would focus tab corresponding to the toolbox?

At the moment, clicking the 'pick' button causes a few annoyances: 1) it brings the browser window to the front, obscuring the toolbox, and 2) it changes the tab of the toolbox itself (for example if I was editing CSS in the "Style Editor" tab, and clicked the 'pick' button, the toolbox will change to the "Inspector" tab; I would not want that to happen).
(In reply to Richard Michael from comment #6)
> (In reply to Brian Grinstead [:bgrins] from comment #5)
> > What about clicking 'pick an element' button?  Seems at that time you
> > definitely will want the tab to be in focus so maybe we could at least start
> > there.
> 
> (I'm the one who asked about this on SO.)
> 
> I apologize, I don't understand exactly what you mean.  Would I need to
> click on the 'pick an element' button for the browser's focus to change, or
> do you mean, perhaps, if I mouse over the 'pick' button the browser would
> focus tab corresponding to the toolbox?

I meant the first (click on the 'pick' button).  It wouldn't have to be the only way to bring the tab forward, also a keyboard shortcut was mentioned in Comment 3.

> At the moment, clicking the 'pick' button causes a few annoyances: 1) it
> brings the browser window to the front, obscuring the toolbox, and 2) it
> changes the tab of the toolbox itself (for example if I was editing CSS in
> the "Style Editor" tab, and clicked the 'pick' button, the toolbox will
> change to the "Inspector" tab; I would not want that to happen).

If it brought the correct tab into focus then maybe (1) wouldn't as annoying since at least you'd be seeing the right tab?  Although that's a good point - if we are going to focus the browser window during picking then maybe we should re-focus the toolbox after picking is over.
(In reply to Brian Grinstead [:bgrins] from comment #7)
> (In reply to Richard Michael from comment #6)
> > (In reply to Brian Grinstead [:bgrins] from comment #5)
> > > What about clicking 'pick an element' button?  Seems at that time you
> > > definitely will want the tab to be in focus so maybe we could at least start
> > > there.
> > 
> > (I'm the one who asked about this on SO.)
> > 
> > I apologize, I don't understand exactly what you mean.  Would I need to
> > click on the 'pick an element' button for the browser's focus to change, or
> > do you mean, perhaps, if I mouse over the 'pick' button the browser would
> > focus tab corresponding to the toolbox?
> 
> I meant the first (click on the 'pick' button).  It wouldn't have to be the
> only way to bring the tab forward, also a keyboard shortcut was mentioned in
> Comment 3.

I see, I agree.  The fact this doesn't happen now is *almost* a bug, in my opinion.  As you say below, yes, it would be less annoying. :-)  The 'pick an element' button ought to cause the browser to focus the corresponding tab or window -- how else could I see what I'm about to pick?  (I do understand the current behavior is probably due to most people simply inspecting the currently displayed browser content, and not changing the content (tab or window) while working in the toolbox, so this doesn't come up often as a UX problem.)

> > At the moment, clicking the 'pick' button causes a few annoyances: 1) it
> > brings the browser window to the front, obscuring the toolbox, and 2) it
> > changes the tab of the toolbox itself (for example if I was editing CSS in
> > the "Style Editor" tab, and clicked the 'pick' button, the toolbox will
> > change to the "Inspector" tab; I would not want that to happen).
> 
> If it brought the correct tab into focus then maybe (1) wouldn't as annoying
> since at least you'd be seeing the right tab?  Although that's a good point
> - if we are going to focus the browser window during picking then maybe we
> should re-focus the toolbox after picking is over.

The refocusing is important, yes.

Is the following general description helpful?  My hoped for usage is:

While working with multiple toolboxes, I would like to see the changes reflected in the browser.  I'd prefer not to change any aspect of the toolbox when this happens: don't change system/window focus, don't change the toolbox tab, etc.  I have the browser (perhaps multiple windows, but certainly multiple tabs) on one monitor, and two (or more) detached toolboxes adjacent to one another (i.e. "window tiled") on a second monitor -- as I window-cycle between the toolboxes, perhaps using the "Style Editor" to edit CSS in one toolbox, but displaying an element's box model via the "Inspector" tab in another toolbox, I would like the browser on the first monitor to change tabs or window following the window-cycling of the toolboxes, but not take system/window focus away from me over in the toolbox (I could be typing CSS at that moment, for example).

(I can use separate browser windows, with only one tab each, window-tiled on the first monitor. This works OK for 2 windows. After that, I run out of meaningful screen space trying to tile > 2 browser windows.)

Mine is perhaps quite a corner case.  I'm debugging CSS positioning between many versions of the same site. :-)


Regards,
Richard
I completely agree with annoyances in comment 6: I'm in the middle of debugging, it's expected that I want toolbox to be in foreground after finding the tab.
In comment 7 I still see a small chance that toolbox would stay focused after finding the tab :)

However: I don't know if there's a way to avoid flickering "toolbox -> firefox -> toolbox" during focusing different windows, but this possible effect should be taken into account (just warning).

Also note that all toolbarbuttons (not only element picker) may require one common approach:
bug 1260043, bug 1260044, bug 1259391
Can't detached toolboxes be opened in the same window for different tabs instead of separate window for each tab? So when the user switches tabs the contents of this window will be switched too. Just like it was in Firebug. I think this approach will resolve the mess between tabs and toolbox windows.
Product: Firefox → DevTools
Hey.

I'm really interested by this feature too.

I'd like to debug several websites with a detached devtool window.

However, it's rather annoying that firefox doesn't synchronise the active tab/site and the devtool window.

I'd like to have my main firefox window on one screen, the devtools window on the other, and there's a synchronisation between the active tab and the right devtool window. :)
In a way, it could/should be "dock in the second screen". :D

I bring it here after reading :
https://discourse.mozilla.org/t/bring-inspector-window-to-front-when-firefox-gets-focus/54393
It's a very important thing to solve:
The devToolbar should work like the defunct (and beloved) Firebug.
With Waterfox and Firebug, if i want inspect a tab, Firebug (in detach mode) stay usable for other table i want inspect too (not need to open an other instance of Firebug).
With Quantum, i need to open new devtool instance for each tabs i want inspect, it's confusing and clearly no useful...

Severity: normal → S3
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.