Open Bug 1121414 Opened 5 years ago Updated 8 months ago
Ability to show several tools at once in the toolbox
Browser devtools (in general, not just Firefox's) are getting more and more complex and cluttered in terms of UI. The simple reason being that we create more and more panels and sidebars and menus to accommodate for very different tools, often tools that have nothing to do with one another. In fact, some people might only ever be interested in 2 panels, while others may be interested in 2 different panels. I'm seeing more and more people (mostly on twitter) asking for abilities to re-arrange the UI of the devtools in various ways. And it makes sense, when you start to think of applications like photoshop, or eclipse, so many options and windows and toolbars can only make sense if you offer some ways for users to re-arrange them the way they want. The thing is the web platform is getting more and more new APIs for which we need new tools, so this phenomena isn't going to stop. I really like the fact that users can choose which panels they want to see in the options tab, and which toolbar buttons too, but I think at some stage we will need more UI customization capabilities. One concrete use case is: being able to see more than 1 panel at once. For now, this is only possible with the split console, but what if I want to see the inspector and style-editor, or the performance tab and network panel? We could: - either generalize the split panel mechanism so any panel can be put there - or offer a way to detach any tab from the toolbox so it's in its own window. Thoughts?
Making the splitconsole functionality in toolbox.js a more generic splitpanel where the name of the panel that goes into the split area defaults to console but can be changed (saved in a pref) seems completely feasible. We'd have to rename the splitconsole gcli command and make it separate from the webconsole commands, but so far I don't anything in the code that should prevent making the overall mechanism generic. If we can do this, then we could expose this splitpanelname pref as a drop-down in the settings panel, and make it default to webconsole, so the behavior doesn't change from what we have today, but users can change it if they like. There are plenty of use cases for being able to choose which panel goes into the splitarea but one that came to mind recently was being able to see the inspector while stepping through DOM construction/modification js code in the debugger. Brian, you worked on the split-console, do you think there's something horribly complicated that would prevent this?
Speaking only of the UI for this feature, it'd be neat if you pressed and held on the split console button in the tab bar and a popup showed up that let you pick which tool was visible (kind of like pressing and holding on the back button).
(In reply to Patrick Brosset [:pbrosset] [:patrick] from comment #1) > Making the splitconsole functionality in toolbox.js a more generic > splitpanel where the name of the panel that goes into the split area > defaults to console but can be changed (saved in a pref) seems completely > feasible. > Brian, you worked on the split-console, do you think there's something > horribly complicated that would prevent this? The trick to the split console is that in the markup we load the 'toolbox-panel-webconsole' separate from all the others: https://dxr.mozilla.org/mozilla-central/source/browser/devtools/framework/toolbox.xul#97. Then when the panel is created we can append it into that existing element instead of making a new one and inserting it into the deck: https://dxr.mozilla.org/mozilla-central/source/browser/devtools/framework/toolbox.js#902. Then we do some magic to set collapsed / hidden attributes properly in JS depending on which tool is selected: https://dxr.mozilla.org/mozilla-central/source/browser/devtools/framework/toolbox.js#465. It's done that way instead of being done on the fly when a tool is selected / split since you can't appendChild() with one of the tool panels (it messes up the iframe IIRC). I could see abstracting some of this into a something that could work for other tools by getting rid of the deck entirely, and have markup something like this to show the debugger split below the inspector. <box minheight="75" flex="1000" id="toolbox-panel-inspector" /> <splitter id="toolbox-console-splitter" class="devtools-horizontal-splitter" /> <box minheight="75" id="toolbox-panel-webconsole" collapsed="true" /> <box minheight="75" flex="1" id="toolbox-panel-debugger" /> But the tricky part is how do we split it such that the inspector ends up below the debugger? Maybe we could do it with the 'ordinal' attribute: https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Attribute/ordinal. It would take some experimenting though to see how that integrates with splitter and flex.
I should also add that there seems to be a way to append the frame to a different place without causing it to reload, since we do that when switching toolbox hosts. I believe this is done with a 'swapFrameLoaders' call: https://dxr.mozilla.org/mozilla-central/source/browser/devtools/framework/toolbox.js#1444. If that were possible in our case, there may be a solution where we can keep two decks one on top of the other and append the relevant panel iframes back and forth if when needed.
The bug summary and comment 0 are sort of vague, but I'm pretty sure there's a need for more toolbox flexibility, so maybe we should keep it as a meta bug, and I'd love to have UX discussions happen here (so flagging the bug with devtools-ux). I think one of the more actionable thing we can do here is generalize the split-console mechanism to any panel.
Regarding the more general toolbox flexibility: I think that the idea of having split views for tools that just make sense together (like inspector + rules view) sounds like it could have a lot of merit, but I'd love to know more about the use cases/developer workflows and approach them on a case-by-case basis + design them on a case-by-case basis. I _will_ say that allowing people to drag panels anywhere they want sounds like it would create a lot of non-elegant UX.
Adding some priority to a first set of bugs. :)
Priority: -- → P1
(In reply to Helen V. Holmes (:helenvholmes) (:✨) from comment #7) > Regarding the more general toolbox flexibility: > > I think that the idea of having split views for tools that just make sense > together (like inspector + rules view) sounds like it could have a lot of > merit, but I'd love to know more about the use cases/developer workflows and > approach them on a case-by-case basis + design them on a case-by-case basis. That makes a lot of sense. Here are the use cases I had in mind: - Inspector + network monitor split view: a lot of sites do lazy loading of content as you scroll, this means creating DOM dynamically and loading data from the network. You could argue that because the console can already show network requests, you could already do this with the split console. - Inspector + debugger: while stepping through DOM construction code, I'd like to see the markup-view react in real-time, as I step over lines of code. Also, we have a bug on file about adding DOM mutation breakpoints (break js execution when something in the DOM changes), it'd be nice in this case if I didn't have to leave the inspector panel to switch over to the debugger when the breakpoint is hit. I might want to see both at the same time. Also see: https://ffdevtools.uservoice.com/forums/246087-firefox-developer-tools-ideas/suggestions/5897304-bring-back-developer-tools-split-pane-mode https://ffdevtools.uservoice.com/forums/246087-firefox-developer-tools-ideas/suggestions/6693765-don-t-limit-me-to-only-one-development-tool-at-a-t https://ffdevtools.uservoice.com/forums/246087-firefox-developer-tools-ideas/suggestions/8862094-ability-to-show-more-than-one-inspector-panels-at > I _will_ say that allowing people to drag panels anywhere they want sounds > like it would create a lot of non-elegant UX. Yeah you're probably right. Let's keep this bug only for the split views thing.
Summary: Ability to dock or detach toolbox tabs in separate windows, or show several tabs at once in the toolbox → Ability to show several tools at once in the toolbox
(In reply to Patrick Brosset [:pbrosset] [:pbro] from comment #9) > That makes a lot of sense. Here are the use cases I had in mind: > - Inspector + network monitor split view: a lot of sites do lazy loading of > content as you scroll, this means creating DOM dynamically and loading data > from the network. You could argue that because the console can already show > network requests, you could already do this with the split console. > - Inspector + debugger: while stepping through DOM construction code, I'd > like to see the markup-view react in real-time, as I step over lines of > code. Also, we have a bug on file about adding DOM mutation breakpoints > (break js execution when something in the DOM changes), it'd be nice in this > case if I didn't have to leave the inspector panel to switch over to the > debugger when the breakpoint is hit. I might want to see both at the same > time. Since it's relevant, have you seen either of these split panels done well in your opinion?
(In reply to Helen V. Holmes (:helenvholmes) (:✨) from comment #10) > Since it's relevant, have you seen either of these split panels done well in > your opinion? Unfortunately no, I have no seen any other browser do this. It just seems like a good idea to me (and to the several people who added and voted on the uservoice ideas). Maybe I should just go ahead and prototype it so we can actually try and see if the use cases are actually compelling.
(In reply to Patrick Brosset [:pbrosset] [:pbro] from comment #11) > Unfortunately no, I have no seen any other browser do this. It just seems > like a good idea to me (and to the several people who added and voted on the > uservoice ideas). Maybe I should just go ahead and prototype it so we can > actually try and see if the use cases are actually compelling. I was thinking about this more yesterday—this might be an interesting use case for a predictive UI at some point, say, if we see that a user is only ever bouncing between two tools we eventually start serving up a version of the UI that's a combination of those two via opt-in, or something like that. Food for thought.
Triaging. Not a P1 anymore according to our new triage process (filter on CLIMBING SHOES).
Priority: P1 → P3
This bug came to my attention once again yesterday when someone on twitter asked whether they could see several panels at once in devtools: https://twitter.com/patrickbrosset/status/784372562310684672 So, there I was, thinking once again that it would be really useful to see the debugger and netmonitor side by side, or the inspector and the debugger, etc... Sometimes seeing what happens on the network or in the DOM while stepping through your program is really powerful. I got an idea for a UI for it: shift-clicking on any tab in the toolbox would stack the tool next to the current tool rather than switch to it. It's nice because it doesn't require any new buttons/settings in the UI and can be used with any panels. So I experimented a bit and made it work really quickly: https://twitter.com/patrickbrosset/status/784446548998512640 Turns out our tools are just loaded inside a collection of <vbox> elements in the toolbox, and right now we just show one <vbox> at a time. But if you change the code so that 2 (or more) of these <vbox> elements are displayed at the same time, then it just works. They all reside inside a XUL flex layout that distributes the space evenly between the tools. I'd really like us to consider this toolbox enhancement. This has been requested several times in the past, and the idea here doesn't require any sort of complex UI. It wouldn't be very discoverable, but it's one of those power user hidden keyboard combos that you can tell people about. I don't think this needs to be a prominent UI feature anyway. So here's a patch I've used for this. If someone with more time than me wants to continue this, feel free. I just don't have enough time at the moment to commit to landing this.
You need to log in before you can comment on or make changes to this bug.