bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

Flexible spacers should be hidden on small windows

VERIFIED FIXED in Firefox 57

Status

()

Firefox
Toolbars and Customization
P1
normal
VERIFIED FIXED
11 months ago
11 months ago

People

(Reporter: florian, Assigned: Gijs)

Tracking

Trunk
Firefox 57
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox57 verified)

Details

(Whiteboard: [photon-structure])

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(1 attachment)

(Reporter)

Description

11 months ago
The flexible spacers in today's nightly look good on my macbook when I have a fullsize window, but when I start resizing the window to a smaller size, it's frustrating that the the spacers are still taking space while some of the toolbar icons start moving to the overflow menu.

Also, when opening Nightly fullscreen on a netbook with a small screen (10", 1024 x 600 pixels), the spacers cause the urlbar to shrink and they look like a waste of space that would be better used to show me the url of the page I'm looking at.
(Assignee)

Comment 1

11 months ago
I think the current behaviour is what was specced. If we don't think the spacers are a waste of space in a large window, it's not clear why they become a waste of space in a smaller window, and where the cut-off is. The overflow menu works using, well, overflow events. Somehow prioritizing hiding the spacers is likely to cause bugs where we end up continuously swapping between the overflow/non-overflow state and hide/show the spacers, so I don't think that's really a viable solution unless we come up with some kind of absolute cut-off point (e.g. hide any/all flexible spacers once the window is less than 600px wide or whatever). I suspect the problem will be that different people will think the cut-off point is somewhere else (because it's subjective and based on user perception, it likely also depends on dpi / physical screen size rather than just resolution), and will then just be annoyed that the spacers show/hide at the "wrong" time. So I'm not convinced there are any reasonable solutions to this problem.

Stephen/Bryan, what if anything do you think needs changing here?
Blocks: 1383009
Flags: needinfo?(shorlander)
Flags: needinfo?(bbell)
(Reporter)

Comment 2

11 months ago
(In reply to :Gijs from comment #1)
> I think the current behaviour is what was specced. If we don't think the
> spacers are a waste of space in a large window, it's not clear why they
> become a waste of space in a smaller window

Because in a large window I still have empty space in the urlbar at the end of a typical url. On a small window/screen, I see only half of a typical url before it gets cropped, but I do see these flexible spacers eating space in the toolbar. And if the site has an EV cert, it's even worse. Eg. on a bugzilla bug url, I see "https://bug" before the url is cropped.

> (because it's subjective and based on user perception, it likely also
> depends on dpi / physical screen size rather than just resolution),

I suspect it also depends on font size. The netbook with a small screen where I tested is running linux, and I think we have a larger default font size for UI text there.

Updated

11 months ago
See Also: → bug 1389484

Comment 3

11 months ago
Ideally, the width of the Flexible Spacer would be determined by the window.  As a window shrinks past a minimum width, the Flexible Spacers would begin to reduce in size as the window width reduces. Ultimately the spacer would shrink down to only a couple pixels.
Flags: needinfo?(shorlander)
Flags: needinfo?(bbell)

Comment 4

11 months ago
This is what it looks like with a min-width of zero set on the flexible spacers. This seems like the right solution to me. https://cl.ly/1R3T3a2e0B2U

Comment 5

11 months ago
(In reply to Aaron Benson from comment #4)
> This is what it looks like with a min-width of zero set on the flexible
> spacers. This seems like the right solution to me. https://cl.ly/1R3T3a2e0B2U

++
(Assignee)

Comment 6

11 months ago
(In reply to bbell from comment #3)
> Ideally, the width of the Flexible Spacer would be determined by the window.
> As a window shrinks past a minimum width, the Flexible Spacers would begin
> to reduce in size as the window width reduces. Ultimately the spacer would
> shrink down to only a couple pixels.

The width of a flexible spacer is determined by the available space in its container. If it weren't, it wouldn't really be a flexible spacer... The minimum width is 40px, which is what Aaron said here:

https://bugzilla.mozilla.org/show_bug.cgi?id=1366813#c2

(In reply to Aaron Benson from comment #4)
> This is what it looks like with a min-width of zero set on the flexible
> spacers. This seems like the right solution to me. https://cl.ly/1R3T3a2e0B2U

This doesn't play for me, even if I allow flash on the page.

More generally, I don't really understand why changing the min-width fixes anything here. The spacers each take up 1/5th of the space of the url bar because of flex. With the spacers, the urlbar is 70% (5/7) of the size it would otherwise be. In other words, the URL bar would be 40% bigger if there were no spacers (a bit less if the search bar is still present, which I guess it is for most people). Put still differently, while shrinking the window, the spacers will (until they get removed) always be taking up space that could be taken up by the url bar instead. I don't see how changing their minimum width alone changes that - it might help a little bit for *really* small windows, but not for the ones where there *is* some space - it's just that 30% of the otherwise usable space is being taken up by these spacers instead of the URL (& search) bar.

Comment 7

11 months ago
> This doesn't play for me, even if I allow flash on the page.

try https://cl.ly/1R3T3a2e0B2U/Screen%20Recording%202017-08-11%20at%2002.11%20PM.mov
Comment hidden (mozreview-request)
(Assignee)

Updated

11 months ago
Attachment #8896430 - Flags: review?(abenson)
(Assignee)

Comment 9

11 months ago
Because flex is weird, this changes the size of the flex items even where they were previously larger than their minimum width (ie they now also take up less space when you're on a wide mbp).
(Assignee)

Updated

11 months ago
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Iteration: --- → 57.1 - Aug 15
Flags: qe-verify+
Priority: -- → P1
Whiteboard: [photon-structure]
(Assignee)

Comment 10

11 months ago
(In reply to :Gijs from comment #9)
> Because flex is weird, this changes the size of the flex items even where
> they were previously larger than their minimum width (ie they now also take
> up less space when you're on a wide mbp).

TBH, in part because of this, I'm not really convinced this behaviour is what we want, but if y'all think this works, we can do it, it's a 1-line change...
(Reporter)

Comment 11

11 months ago
mozreview-review
Comment on attachment 8896430 [details]
Bug 1389505 - set min-width for the flexible spacers to 0,

https://reviewboard.mozilla.org/r/167668/#review172904

Looks good to me, thanks! :-)
Attachment #8896430 - Flags: review?(florian) → review+

Comment 12

11 months ago
mozreview-review
Comment on attachment 8896430 [details]
Bug 1389505 - set min-width for the flexible spacers to 0,

https://reviewboard.mozilla.org/r/167668/#review172916

Comment 13

11 months ago
mozreview-review
Comment on attachment 8896430 [details]
Bug 1389505 - set min-width for the flexible spacers to 0,

https://reviewboard.mozilla.org/r/167668/#review172920

Looks good to me!
Attachment #8896430 - Flags: review?(abenson) → review+

Comment 14

11 months ago
Pushed by gijskruitbosch@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/e53d98b61629
set min-width for the flexible spacers to 0, r=florian,ui-r=abenson

Updated

11 months ago
QA Contact: gwimberly
https://hg.mozilla.org/mozilla-central/rev/e53d98b61629
Status: ASSIGNED → RESOLVED
Last Resolved: 11 months ago
status-firefox57: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 57
(Assignee)

Updated

11 months ago
Depends on: 1390327
Verified on Windows, Mac, and Ubuntu.
Status: RESOLVED → VERIFIED
status-firefox57: fixed → verified
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.