Closed Bug 1453294 Opened 2 years ago Closed 2 years ago

Reduce devtools min-width when docked to side


(DevTools :: General, enhancement, P3)



(firefox61 verified)

Firefox 61
Tracking Status
firefox61 --- verified


(Reporter: jdescottes, Assigned: daisuke)


(Blocks 1 open bug)



(4 files)

The current min-width for devtools when docked to the side is 465px:

We could reduce it considering that when docked to bottom, devtools can shrink down to 335px [1]. Chrome devtools seem to have 255px as min-width for reference. 

Having small min sizes can be useful, not only to adjust your UI but sometimes you just temporarily want to increase your viewport but without fully closing devtools (imagine you are debugging etc...). I would be in favor of decreasing this even further than 335px :)

[1] comes from a browser style:
Blocks: 1444299
Daisuke, Mantaroh, are either of you able to look at this? It looks straightforward but it would be good to fix this before we test all the other changes to the toolbar so that we can test them at the same time.
Yep, I'll take a look at this.
Assignee: nobody → dakatsuka
Duplicate of this bug: 1454616
Summary: Reduce devtools docked to side min-width → Reduce devtools min-width when docked to side
Attached image min-width-335.gif
I attach a video for this.

Network tool couldn't be touched all components inside the tool. However, even if 465px, we can't touch all.
Performance tool, half of the setting button will be hidden.
Also, as far as I try it, the reordering and overflowed tabs features worked well.
That looks good to me! I think that since we already support 335px when we are docked to the bottom, we don't need to check how each tool behaves in 335px when docked to the side. 

As discussed on Slack, 335px is the value used by the browser on OSX only, other OSes use 300px. Maybe we should use this smaller value here?

Victoria: are you fine with reducing the min-width when DevTools are docked to the Side? We propose 300/335px because this is the current limit that comes from the browser when DevTools are docked to the bottom and you resize the window.

As I said in the summary, I would even be in favor of allowing user to resize DevTools to much smaller dimensions (eg 50px ?) so that they can get DevTools out of the way, test something (such as a media query, or something that is easier to do with a bigger viewport) and then increase DevTools again without having to close and reopen. Would also like to know what you think about that, but that's probably a separate topic.
Flags: needinfo?(victoria)
Yes, this looks good. 

For some panels like Network, there is work underway to make it look better at the 465px ( In the future, we can do more work to keep things usable at smaller sizes like 300, and we need to polish vertical mode in general (things like the Debugger sidebars looking wonky by default, and the need for drag handles). 

For now, it seems fine to allow small dimensions and just have the panel start to hide the overflow at sub-465 widths. Even something like 50px seems fine as long as there isn't any unique breakage that occurs at that width.
Flags: needinfo?(victoria)
Attached image min-width-250.gif
I discussed with Brian, we are trying 250px as min-width. (I attach the video.)
This 250px is the width that we can see / touch the chevron menu. (This means we can select any tool.)

Victoria, Julian, how do you think about?
Flags: needinfo?(victoria)
Flags: needinfo?(jdescottes)
Attached image 250px-win.png
Also, I attach a screenshot of windows as well.
Also, this is only a short-term measure. While 250px works well for English on Mac but will probably not work for other languages / non-standard fonts etc.

Long-term what we need to do is make the chevron show even when all tabs are hidden (this is what Chrome does). Currently if you squash the menu too far the chevron is hidden while the last tab is showing. By doing this we can use a smaller min-width and it won't depend on the locale / font etc.
Thanks Daisuke! 

250px is fine by me, because I believe there is value in allowing to resize Devtools below "usable" widths (for the scenarios I mentioned in previous comments).
Note that you can have more buttons in the toolbar: go to F1/options and turn on all checkboxes under Available Toolbox Buttons. They might hide the current tab and chevron at 250px (but again I think this is acceptable)
Flags: needinfo?(jdescottes)
Looks good! Like Julian, I'd also be fine with some unusability at these small widths in which the user is probably enlarging their website rather than using DevTools. I do agree with Brian that the Chrome-style chevron-always-showing behavior will be a nice future improvement.
Flags: needinfo?(victoria)
Thank you very much, Brian, Julian, Victoria!
Let us 250px in this time.
Then, let us consider about reducing the width more and chevron menu in another bug.
Comment on attachment 8970076 [details]
Bug 1453294: Reduce devtools min-width when docked to side.

Looks good, thanks Daisuke! While you are changing this could you remove the comment at

This comment mentions the current min-width of 465px. You can simply remove it.
Attachment #8970076 - Flags: review?(jdescottes) → review+
Blocks: 1456056
(In reply to Julian Descottes [:jdescottes][:julian] from comment #15)
> Comment on attachment 8970076 [details]
> Bug 1453294: Reduce devtools min-width when docked to side.
> Looks good, thanks Daisuke! While you are changing this could you remove the
> comment at 
> fcd5cb3515d0e06592bba42e378f1b9518497e3d/devtools/client/shared/test/
> browser_html_tooltip_rtl.js#23
> This comment mentions the current min-width of 465px. You can simply remove
> it.

Oh, thanks!
Pushed by
Reduce devtools min-width when docked to side. r=jdescottes
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 61
I have reproduced this issue using Firefox 61.0a1 (2018.04.11) on Ubuntu 14.04 x64.
I can confirm this issue is fixed, I verified using Firefox 61.0b1 on Win 10 x64, Mac OS X 10.13 and Ubuntu 14.04 x64.
Sorry, verified using Firefox 61.0b10.
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.