User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0 Build ID: 20151014143721 Steps to reproduce: 1. Press F12 to open developer tools in a separate window. 2. Switch tab 3. Press F12 again. 4. Switch back to first tab. Actual results: A separate developer tools window is opened for each tab. When I switch back to the first tab I have to find the first developer tools window that goes with that tab. This can get confusing and frustrating at times. Expected results: There should just be one window that displays the developer tools for the currently selected tab. This is how Firebug 2 works. If this behavior is not always wanted, this could be controlled by an option in the developer tools settings.
I cast a vote for this bug since the current behavior of one developer tools window per tab is the most significant pet peeve I have with the built-in developer tools. Although I use a very large monitor, I find it unpleasant and irrational to squander in-browser real-estate on the developer tools. So I always undock the developer tools and move them to a secondary monitor. But in routine multi-tab work, that results in a stack of developer tools windows that must be managed by the operating system's window manager. The net effect is analogous to how web browsers functioned before the addition of tabs: a bunch of needless alt-tabbing through a huge stack of browser windows. (Note, I know that pressing F12 in a tab will focus the associated developer tools, but the clutter of developer tool windows still frustrates all other alt-tab operations.) Firebug had it right: just reuse the developer tools window across tabs. In the rare case where you need to compare information from two developer tool windows, you can disable the reuse feature.
Interesting feature idea. I don't usually work that way but I see how it would speed you up. I think the UX could be tricky. Like how do you flip between the modes? And what happens if you have some state in the toolbox when you switch tabs (i.e. breakpoints set in debugger). Does that get restored when you switch away and come back to the original tab?
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
I think that switching between the modes would be something that would happen in Toolbox Options, but I know nothing about the code involved. From my point of view just making it work like Firebug 2, which always reuses the window, would be great. If you are debugging in one tab, switch to another tab, and then switch back again, you pick up right where you left off. That is, the state doesn't seem to be restored so much as just hidden and then displayed again.
As a first step wonder if we could raise the devtools toolbox associated with a tab above other detached toolboxes when the corresponding tab becomes focused. In this case you'd still need to open toolboxes individually but the sort of window management issue would be better. Also, if that's possible it would be a lot easier than what's described here. Saving and refreshing the toolbox state sounds like it'd require each tool to add this ability.
Focusing the toolbox for the current tab would be very helpful, though it wouldn't address the window clutter that Brian Hauer referred to.
I would really love just making it work like Firebug 2, as Dave suggests in Comment 3. It's basically just one window frame that is populated with DevTools content for whatever tab is selected in the browser window.
There's a good description at https://news.ycombinator.com/item?id=13223042 from Brian which makes a good point why Firebug users are missing this feature. I'm pasting here as I find it much more conceivable than all the above: > I miss Firebug for a very specific, perhaps even idiosyncratic, reason. As > someone with a huge amount of screen real-estate but nevertheless a strong > desire for applications to be tidy in their use of that space, there was a > behavior of Firebug that is lacking in DevTools: the ability to use a single > separate window across all Firefox tabs. > > With Firebug, the user could detach the Firebug window from the browser and > position it separately on screen. Firebug could be enabled for any tab and the > contents of the Firebug window would dynamically change to reflect the browser > tab with focus. In DevTools (and also in Chrome), this mode is not an option. > Instead, the user has two options, both of which are less desirable: > > 1. Open a separate DevTools window for each tab. This bloats the window stack in > the same way browsers did generally before the advent of tabs, making it a > poor option. > > 2. Leave the DevTools docked inside the browser window. This is poor because > large screen real-estate cannot be properly utilized by positioning the > DevTools separate from the browser window. Despite an abundance of screen > real-estate, either a chunk of the browser frame needs to be consumed with > the DevTools or the browser is made awkwardly wide/tall which adversely > affects all tabs that do not have the DevTools open. > > Because window management and usable screen real-estate is so critical to my > productivity, this very specific behavior of Firebug is what I miss more than > anything.
I wonder why this is not moving forward. Yes, it takes a bit of code but already when there is a button when clicking the developer tools window whereby the domain it is associated with is shown. What can't this just be a dropdown select option of open tabs to switch to? Or just use Tabs in the Developer Tools window when in standalone mode? Whether Chrome, IE or Firefox, it is a pain when I have three 25" ultra wide screens giving me real estate to open windows and get a good viewable area of my debugger and then have to have a separate debugging window for every tab I'm debugging in...
+1 I have been using Firebug before and now I am using built-in web developer tools. This issue is the most annoying thing about the web developer tools. I am debugging the same website in multiple tabs. I have the main browser window on the big screen and the developer tool window on the small screen. I always end up with multiple developer tools windows on the small screen and I am always using the wrong one first. Even worse, using the element-picking in a dev tools window that does not belong to the current tab does do nothing useful at all. You cannot select anything because you are clicking in the wrong tab. It does not even show you somehow that this does not work. It just seems to be broken until you figure out that its the wrong dev tools window. You cannot say "Firebug is gone, now use the developer tools, it is even better". Everybody loved firebug for very good reasons. Sadly, developer tools have become another good reason why to use Chrome :'( Some years ago, Firebug was a really good reason for web developers why to use Firefox.
+1 This feature is the reason I'm still using Firefox v49 and avoiding updates, so I can use Firebug with this functionality. But I know using an increasingly out of date browser isn't a long term solution. The post from https://news.ycombinator.com/item?id=13223042 in comment 7 explains the issue well. My job frequently requires debugging multiple pages in different tabs. Keeping the dev tools in a single window as I switch between tabs is important to my productivity. Also, keeping the console visible at all times for any page I'm on helps me spot bugs even when I wasn't specifically looking for them, which otherwise might have gone unnoticed. This works much better when the dev tool window fits neatly into my screen real estate, so I don't have any need to close or minimize it. At the very least, the option suggested in comment 4, to automatically change the active dev tool window when switching tabs would be very helpful. The start bar would still be cluttered with multiple dev tool windows, but at least the windows could be stacked on top of each other in the same screen location, with the one that's needed automatically rising to the top.
Mozilla likes to say they are listening... Hmm... 3 years ago this was requested as a feature and to date it is NOT assigned to anyone and no information from them has been forthcoming...
The way the toolbox is architected, this is non-trivial; so we need to make a strong case. One possible solution to the problem described here would be a middle ground that doesn't reuse the same window. This could be solved by having having the toolboxes follow focus with the selected tab. For each tab, the user can open an undocked toolbox. When switching tabs, the default behavior should put the right toolbox for a tab in foreground (assuming it has one attached). Alex, does this solution sound crazy complex or wrong?
Thank you for helping move this forward, Harald! I've already made the best cases I can above. I would very much prefer a singular reused developer tools window. The developer tools windows congesting the operating system's window stack (and not occupying the same screen space by default) is very much part of the problem. But with respect to your proposed middle-ground solution: is adjusting the stack order of the windows technically possible without affecting focus on the browser window? As an alternative middle-ground, is it feasible to add tabs to the developer tools window and have those be synchronized to the browser's tabs (i.e., a 1:1 tab-for-tab relationship augmented with automatic tab switching that would mimic the window reuse behavior described elsewhere in this thread)?
(In reply to tom from comment #16) > +1 > This would be the biggest improvement to DevTools for frontend developers > who miss firebug. Note that this was not part of the feedback the Firebug Working Group got when asking about what features people are missing most in the Firefox DevTools (see bug 1267303 comment 11). And, for what it's worth, there was even a request for Firebug to *not* share the window for different tabs/windows. Nonetheless, the multi-monitor use case and the issue about getting confused about which toolbox is coupled with which tab are valid. (In reply to Brian Hauer from comment #19) > As an alternative middle-ground, is it feasible to add tabs to the developer > tools window and have those be synchronized to the browser's tabs (i.e., a > 1:1 tab-for-tab relationship augmented with automatic tab switching that > would mimic the window reuse behavior described elsewhere in this thread)? UX-wise that's very good, in my opinion. Though - without knowing the code responsible for the window handling - it sounds to me that this would also mean some bigger changes to the codebase. But I'd be happy to be proven wrong on this. Sebastian  https://github.com/firebug/firebug/issues/2447
Having one toolbox instance connected to multiple tabs is impossible per current architecture. Connecting one toolbox to multiple tabs, means having a toolbox connected to multiple targets. That's exactly what we are currently working on for Fission's project (i.e. multi processes per tabs), but that's at least a one year project for multiple developers. Once fission is finished, it will be much easier to implement this feature. In the meantime, there is many hacks we could use to have multiple toolboxes, hosted in a single window. Or as Harald suggested, focus windows as we change the selected tab. (that should be easier to implement) But still, we would need to find someone having spare cycles to work on this. That won't be trivial as you have to understand how a toolbox is bootstrapped in these external windows.
> Note that this was not part of the feedback the Firebug Working Group got when > asking about what features people are missing most in the Firefox DevTools > (see bug 1267303 comment 11). And, for what it's worth, there was even a > request for Firebug to *not* share the window for different tabs/windows. > Nonetheless, the multi-monitor use case and the issue about getting confused > about which toolbox is coupled with which tab are valid. I was not previously aware of the Working Group nor a prior survey. I have no doubt that there are a diversity of opinions on this behavior, which is why I would suggest single versus multi-window Developer Tools should be a user preference in the manner I remember in Firebug. My memory is that the Firebug default was single window, but a checkbox toggle allowed for multiple windows when that was useful. And it is useful in many cases (e.g., when doing comparisons between multiple URLs), just as there are cases where multiple browser windows are useful even though we have tabbed browsing. The key is to have both options available for when they are best suited. > That's exactly what we are currently working on for Fission's project (i.e. > multi processes per tabs), but that's at least a one year project for > multiple developers. Once fission is finished, it will be much easier to > implement this feature. I appreciate you assessing the plausibility of something in the short term. I can only speak for myself, but for my part I would prefer this to be done "right," even if that means waiting for the Fission project to be finished. I worry any near-term partial solution has the risk of being seen as good enough in the longer-term, persisting beyond when Fission is done. I'm not sure if that sort of input is useful, but figured I'd put it out there for whatever it's worth. Thanks!
You need to log in before you can comment on or make changes to this bug.