Closed Bug 971129 Opened 6 years ago Closed 5 years ago

When the DevTools bottom host toolbox gets expanded to full height, it is hard to shrink it

Categories

(DevTools :: Framework, defect)

defect
Not set

Tracking

(firefox39 fixed)

RESOLVED FIXED
Firefox 39
Tracking Status
firefox39 --- fixed

People

(Reporter: bgrins, Assigned: bgrins)

References

(Blocks 1 open bug)

Details

Attachments

(6 files, 2 obsolete files)

Attached image full-height-toolbox.png
See attached image.  In this case, the only way to shrink devtools (and show web content) is to either:

* Reset devtools.toolbox.footer.height in about:config
* Make the browser window taller, which should free up some space in order to grab the handle.  This can require a lot of window maneuvering depending on the OS, and is not immediately obvious.

We could try to make sure that the splitter is always grabbable, or be careful not to allow the toolbox to ever be bigger than the browser height - 100px or so.  There should be some options on the splitter to accomplish this.
I think the core problem here is that the otherwise visible splitter gets hidden here. On my windows 7, I am able to resize the toolbox down, but since the splitter is not visible, and it has only 1 px hit area, its really really hard to accurately aim at the 1px point where the cursor changes.

(In reply to Brian Grinstead [:bgrins] from comment #0)
> Created attachment 8374294 [details]
> full-height-toolbox.png
> 
> See attached image.  In this case, the only way to shrink devtools (and show
> web content) is to either:
> 
> * Reset devtools.toolbox.footer.height in about:config
> * Make the browser window taller, which should free up some space in order
This is not work in case of Windows 7 when the browser is in maximized state. There is no more space for the browser to become taller.

> to grab the handle.  This can require a lot of window maneuvering depending
> on the OS, and is not immediately obvious.
> 
> We could try to make sure that the splitter is always grabbable, or be
> careful not to allow the toolbox to ever be bigger than the browser height -
> 100px or so.  There should be some options on the splitter to accomplish
> this.


The immediate and simplest solution I can think of is to increase the hit area of the splitter. Maybe we can make the splitter 2px taller, but not above the toolbox, below it, overlapping the glow on the selected tab.
(In reply to Girish Sharma [:Optimizer] from comment #1)
> I think the core problem here is that the otherwise visible splitter gets
> hidden here. On my windows 7, I am able to resize the toolbox down, but
> since the splitter is not visible, and it has only 1 px hit area, its really
> really hard to accurately aim at the 1px point where the cursor changes.
> 
> (In reply to Brian Grinstead [:bgrins] from comment #0)
> > Created attachment 8374294 [details]
> > full-height-toolbox.png
> > 
> > See attached image.  In this case, the only way to shrink devtools (and show
> > web content) is to either:
> > 
> > * Reset devtools.toolbox.footer.height in about:config
> > * Make the browser window taller, which should free up some space in order
> This is not work in case of Windows 7 when the browser is in maximized
> state. There is no more space for the browser to become taller.
> 
> > to grab the handle.  This can require a lot of window maneuvering depending
> > on the OS, and is not immediately obvious.
> > 
> > We could try to make sure that the splitter is always grabbable, or be
> > careful not to allow the toolbox to ever be bigger than the browser height -
> > 100px or so.  There should be some options on the splitter to accomplish
> > this.
> 
> 
> The immediate and simplest solution I can think of is to increase the hit
> area of the splitter. Maybe we can make the splitter 2px taller, but not
> above the toolbox, below it, overlapping the glow on the selected tab.

I actually think the issue is the margin-top: -3px on the .devtools-horizontal-splitter class here: https://mxr.mozilla.org/mozilla-central/source/browser/themes/shared/devtools/common.css#25.  If this is set to 0, it can still be grabbed from the top.  I'm not sure if there is a specific reason why it is set to -3px (matching the height of 3px)

I just also noticed that devtools can be shrunken down to 10px, which seems excessively small (we should at least be able to see the whole tab bar), so this limit should be changed as well.
(In reply to Brian Grinstead [:bgrins] from comment #2)
> (In reply to Girish Sharma [:Optimizer] from comment #1)
> [...]
> this limit should be changed as well.

Agreed.
Also, I noticed that even though the mentioned and actual height is 3px, the grab-able area is only 2 px and 1 px is border which is not grab-able for some reason :?

I think to extend the splitter both above and over the toolbox, the border bottom that the splitter has will have to go.
Attached image splitter-top.png
Actually, at least on OSX the grabbable area is 3px (I've confirmed with digital color meter).  This is what it looks like without the negative margin, and with a red background color.  You can see that the bottom border is part of the 3px height (I believe this is because background-clip is set to border-box in UA styles, at least on OSX).
Attached patch splitter-handle-WIP.patch (obsolete) — Splinter Review
the patch I was using to take screenshots
Duplicate of this bug: 1015189
I ran into this again the other day, it's a big wtf if you trigger it and can only be resolved by editing about:config or switching to a larger monitor. It's easy enough to trigger, just plug an 11" air into a 1080p monitor, bring the console up to a height over ~750px, then detach the monitor. 

I wonder if the quick fix isn't to always ensure that there are a few spare pixels at the top?
See Also: → 1056543
Duplicate of this bug: 1145771
See Also: → 1064596
Attached patch browsercontainer-size.patch (obsolete) — Splinter Review
Matt, here is a patch that fixes our problem about the devtools toolbox being resized to full height and then not being able to grab the splitter.  Rather than trying to mess with the splitter CSS to make sure there is a 1px space to still grab, this just prevents the browserContainer element from getting shrunk down to 0px in the first place.

Here are a couple of questions though:
1) Right now that you can resize the browser down to just the #navigator-toolbox.  It looks pretty weird to not have a page visible, but I'm not sure if that is intentional.  With this patch, you would never be able to shrink the page content down to 0px.
2) If you think this is an OK idea, then where is the best place to add it? Just copy/paste into each of the browser.css files?
Attachment #8583462 - Flags: feedback?(MattN+bmo)
Attached image no-page.png
A screenshot of the browser resized down to #navigator-toolbox as mentioned in Comment 9
Attached image with-min-height.png
This is the smallest the page content gets with the patch applied
Comment on attachment 8583462 [details] [diff] [review]
browsercontainer-size.patch

Review of attachment 8583462 [details] [diff] [review]:
-----------------------------------------------------------------

I think this makes sense and 40px seems small enough that it won't cause problems (especially since it's only for tabbrowser, not all <browser>).

::: browser/themes/shared/devtools/common.css
@@ +9,5 @@
>  }
>  
> +/* Prevent shrinking the page content to 0 height/width */
> +.browserContainer {
> +  min-height: 40px;

You can probably put this above `.browserStack > browser` in browser/base/content/browser.css
Attachment #8583462 - Flags: feedback?(MattN+bmo) → review+
We discussed this further and decided that `.browserStack > browser` was a better selector to use, since the browserContainer contained other non-page things that would subtract against the min-height (like the find bar).
Assignee: nobody → bgrinstead
Attachment #8427756 - Attachment is obsolete: true
Attachment #8583462 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #8584097 - Flags: review+
This updates the min size we allow in toolbox hosts to match the upcoming new min height / width on the <browser> element
Attachment #8584547 - Flags: review?(jryans)
Attachment #8584547 - Flags: review?(jryans) → review+
https://hg.mozilla.org/mozilla-central/rev/2a5d75686605
https://hg.mozilla.org/mozilla-central/rev/ea27094291fe
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → Firefox 39
Duplicate of this bug: 1057930
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.