Closed Bug 1318869 Opened 8 years ago Closed 7 years ago

Width of bookmarks without labels on bookmarks toolbar has changed

Categories

(Firefox :: Theme, defect)

50 Branch
Unspecified
Windows 10
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: fios, Unassigned)

References

Details

(Keywords: regressionwindow-wanted)

Attachments

(5 files, 1 obsolete file)

Fx has just updated itself to 50 and something weird has happened to my favicons on the bookmarks toolbar. I had as many as I could fit across (53) most of which were only displaying the favicon (by leaving the name field empty). On Windows, they fit without overflowing (on OSX, they overflowed at number 42 and on Linux even earlier).
Since the update, about 5 of them got pushed off my screen and while it's difficult to judge, it seems like the border/space between them has increased, which is very annoying and doesn't really provide any benefit to the end user the way I can see so I'm thinking this is a bug.
I suspect this is a result of the bookmarks toolbar style update which would be consistent with it changing between 49 and 50, though I haven't doublechecked that that's the regressor.
Blocks: 734326
Component: Toolbars and Customization → Theme
Summary: Bookmarks toolbar icon width has changed → Width of bookmarks without labels on bookmarks toolbar has changed
Ok last night Fx updated to 51 and I have lost ANOTHER favicon space on the toolbar. I'm beginning to get really annoyed about this. Who needs that much padding around their favicons and can we please have a debate about that *somewhere*? It is one of the most useful things in Fx...
Flags: needinfo?(gijskruitbosch+bugs)
(In reply to Michael Bauer from comment #2)
> Ok last night Fx updated to 51 and I have lost ANOTHER favicon space on the
> toolbar. I'm beginning to get really annoyed about this. Who needs that much
> padding around their favicons and can we please have a debate about that
> *somewhere*?

I'm not sure what there is to 'debate'.

To the best of my knowledge there were no deliberate changes to favicon padding in 51, and so I honestly have no idea what change would have triggered what you're talking about. Do you actually see different padding on the individual items? Or maybe on the toolbar on which you keep them? Or something else?

> It is one of the most useful things in Fx...

This is your personal opinion. Firefox is a complex product, and lots of things demand the attention of engineers and other people working on the project (in the last few weeks, I've mostly been working on urgent projects for the releases of 51 and 52, and security fixes. It's not like I'm not working on this or other issues you consider important because I'm lazy or something).

In order to address this problem, a number of things need to happen, and so far the severity of the problem does not warrant me investing time to make them happen (in the way that potential security problems or clearly broken behaviour would). One of the ways this could change is if you or someone else takes some of the steps. In order:

1. this bug needs a more precise problem statement. Comment #0 says "something weird" happened. Please be more precise ("left padding on favicons in the toolbar changed from Apx to Bpx" or "on platforms X when you use Firefox/OS theme Y, padding is N instead of M pixels" or "when using add-on P and Q, padding of favicons changes", or "when using a hidpi Windows machine, padding rounding errors cause favicons to not be aligned correctly", etc.). It should be relatively easy to take comparative screenshots between 2 versions and explain precisely what the difference is. Even better if you can check if this reproduces on a clean profile etc.
2. ideally, check with e.g. mozregression ( http://mozilla.github.io/mozregression/ ) when this broke (ie what bug fix caused the change you have a problem with)
3. repeat steps 1 and 2 for the change in 51. 
4. depending on what the problem is, it may be more or less obvious that the behaviour is a bug. No space at all between 2 favicons would obviously be undesirable, as would no space between a favicon and its label. Broken different behaviour on hidpi vs. non-hidpi is also definitely buggy. For anything else, being as explicit and objective as possible about why a change is bad would be helpful.
5. Finally, the obvious: patches. Depending on the previous steps, assuming that others (like, but not necessarily, me) agree there's a problem, we can definitely help with this, but in the end it's all CSS, so you can use the browser toolbox ( https://developer.mozilla.org/en-US/docs/Tools/Browser_Toolbox ), user CSS ( http://kb.mozillazine.org/index.php?title=UserChrome.css&printable=yes ) and artifact builds ( https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Artifact_builds ) to investigate fixing this yourself if you know CSS.

In any case, I'm best suited to writing patches. But right now it's not obvious at all to me what needs patching and when we broke what. Until/unless that changes, there's not much I can do to help here.
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(fios)
1. Some people are devs, some, like me, are localizers/users which means that sometimes "something weird" is the best I can do - but I did explain further that I had the toolbar filled with the maximum number of icons which would fit. Then Fx upgraded from 49 to 50 and suddenly there was less space - about 3 icons worth. Same thing happened again going from 50 to 51. I'm including a screenshot. Look at the far right end where there a » which wasn't there in the previous version up until a few days ago.
2. I'm not a developer and while I'd love to have the skills of one, I'm past apologizing for simply not having a brain that works that way. I could stare at lines of code till Christmas and still make no sense of it. Reporting an issue is the best I can do and I will do my best to provide more information when asked to to the best of my abilities.
3. See 2.
4. I have no idea what that means.
5. See 1 and 2.
Attached image right end of toolbar.png (obsolete) —
Flags: needinfo?(fios)
(In reply to Michael Bauer from comment #4)
> 1. Some people are devs, some, like me, are localizers/users which means
> that sometimes "something weird" is the best I can do - but I did explain
> further that I had the toolbar filled with the maximum number of icons which
> would fit. Then Fx upgraded from 49 to 50 and suddenly there was less space
> - about 3 icons worth. Same thing happened again going from 50 to 51. I'm
> including a screenshot. Look at the far right end where there a » which
> wasn't there in the previous version up until a few days ago.
> 2. I'm not a developer and while I'd love to have the skills of one, I'm
> past apologizing for simply not having a brain that works that way. I could
> stare at lines of code till Christmas and still make no sense of it.
> Reporting an issue is the best I can do and I will do my best to provide
> more information when asked to to the best of my abilities.

OK. Please take a screenshot of how *the entire bar* looks on 49, 50 and 51, not just part of the bar on one build. If you're worried about privacy, white/black out each icon (but please take care not to manipulate its size). You can find old builds here:

49: http://archive.mozilla.org/pub/firefox/releases/49.0.2/win32/en-US/

50: http://archive.mozilla.org/pub/firefox/releases/50.1.0/win32/en-US/

(I'm assuming the existing screenshot is with 51? Can you take one that covers the entire bar?)
Flags: needinfo?(fios)
Attached image entire bar in 51.png
Attachment #8832069 - Attachment is obsolete: true
Flags: needinfo?(fios)
Attached image entire bar in 50.png
Attached image entire bar in 49.png
Screenshots from all 3 versions you requested. As you can see, the drop from 49 » 50 is particularly dramatic.
From what I see, from version 49 to 50 the padding of each icon changed. I think this was part of a larger theme redesign (see comment 1). It was clearly done on purpose and to me it looks more readable. Clearly it doesn't exist a value that is better than others here, since it's a subjective preference. You may want to see more icons, someone else may want them more spaced, or even no space at all!

From version 50 to 51, the only thing that changed was the left padding on the toolbar, in particular the first icon doesn't touch anymore the toolbar margin. IIRC there was indeed a fix for that (but I can't find the bug# atm). I'd not object to this, the padding there wasn't looking great, so let's ignore this one, that at a maximum pushes out one icon in edge cases, not a big deal since it only affects 1 precise number of icons.

I'd honestly suggest to use stylish or a similar add-on to set your own custom padding. Even if something would ever be done here, it would be unsatisfying for you, cause it would unlikely bring back the number of icons to the specific one you wish. Imo this will just end up being a wontfix.
Could this not be done dynamically (within reason) i.e. that the toolbar reduces the padding up to a point where stuff just gets silly-small?
(In reply to Michael Bauer from comment #11)
> Could this not be done dynamically (within reason) i.e. that the toolbar
> reduces the padding up to a point where stuff just gets silly-small?

Doing that would require a bunch of JS, which then is likely to have edgecases that don't work well (what happens if you resize the window? If it's maximized but the resolution of your screen changes?). Dealing with all of that just to shave 1-2px of padding per icon to benefit only people who have a huge number of bookmarks that they all keep on the toolbar without any labels... No, the complexity/reward ratio there is not good.

(In reply to Marco Bonardo [::mak] from comment #10)
> From what I see, from version 49 to 50 the padding of each icon changed.

Yes, it looks like there used to be 6px between each item on the 49 screenshot and there is now 8px. Looking at the patch, this difference is caused by the fact that the hover state of the items now has a 1px CSS border. We used to use native rendering which showed a border.

> I
> think this was part of a larger theme redesign (see comment 1). It was
> clearly done on purpose and to me it looks more readable. Clearly it doesn't
> exist a value that is better than others here, since it's a subjective
> preference. You may want to see more icons, someone else may want them more
> spaced, or even no space at all!

We could potentially reduce the horizontal padding for items with no label (from 3px on each side to 2px). Items that have no label are pretty clearly done by someone who is trying to minimize space usage. That would fix most of the issue here, and it would make the items square (16x16 icon with 2px padding on all sides and a 1px border on all sides), which also seems like it will look slightly nicer than the current hover style for such items. That would be a simple 1-rule CSS change, as far as I can tell. How would you feel about this? I would also be fine with WONTFIX, but I figured I should suggest this, at least.

> From version 50 to 51, the only thing that changed was the left padding on
> the toolbar, in particular the first icon doesn't touch anymore the toolbar
> margin. IIRC there was indeed a fix for that (but I can't find the bug#
> atm). I'd not object to this, the padding there wasn't looking great, so
> let's ignore this one, that at a maximum pushes out one icon in edge cases,
> not a big deal since it only affects 1 precise number of icons.

bug 1294885. I agree we shouldn't fix this - this was an actual bugfix that we should not revert.
Blocks: 1294885
Flags: needinfo?(mak77)
(In reply to :Gijs from comment #12)

> any labels... No, the complexity/reward ratio there is not good.

Ok, I can see that, fair enough.

> > preference. You may want to see more icons, someone else may want them more
> > spaced, or even no space at all!

Did any user ever really ask Mozilla for more spacing around these icons? I'm not sure how much end user testing is actually involved in this kind of thing or if it was just someone who said "*I* want more spacing" <submits patch>

> We could potentially reduce the horizontal padding for items with no label
> (from 3px on each side to 2px). Items that have no label are pretty clearly
> done by someone who is trying to minimize space usage. That would fix most
> of the issue here, and it would make the items square (16x16 icon with 2px
> padding on all sides and a 1px border on all sides), which also seems like
> it will look slightly nicer than the current hover style for such items.
> That would be a simple 1-rule CSS change, as far as I can tell. How would
> you feel about this? I would also be fine with WONTFIX, but I figured I
> should suggest this, at least.

So that's what, saving 2px each, so let's say 53 icons that's freeing 106px or so - which would give us back the 6 or so spaces lost. Yes, that would certainly make me a very happy camper :D
Flags: needinfo?(mak77)
(In reply to :Gijs from comment #12)
> We could potentially reduce the horizontal padding for items with no label
> (from 3px on each side to 2px). Items that have no label are pretty clearly
> done by someone who is trying to minimize space usage.

What about mixed-use cases, where part have a label, part do not? Won't some items have a different padding then?

I feel like I'm not the right person to take a decision here, Dao or Jared are better fit, since they worked on the original bug.
Flags: needinfo?(dao+bmo)
Yes that happens (esp when a site has no favicon) but I think any case where someone goes to the extent of removing labels from some, it means they're trying to save space more than they're interested in beautiful padding.
Attached image Bar in Mac.png
Incidentally, while we're at it - fortunately my main working machines aren't Macs but the padding around these icons on OSX is, well, bonkers. My Macbook's screen IS smaller than my desktop screen but even so, the rounded corners thing (I'm guessing that's the culprit) takes up so much space far fewer fit on the bar even bearing in mind the differences in screen width. Ubuntu is even worse.
(In reply to Michael Bauer from comment #16)
> Created attachment 8836075 [details]
> Bar in Mac.png
> 
> Incidentally, while we're at it - fortunately my main working machines
> aren't Macs but the padding around these icons on OSX is, well, bonkers. My
> Macbook's screen IS smaller than my desktop screen but even so, the rounded
> corners thing (I'm guessing that's the culprit) takes up so much space far
> fewer fit on the bar even bearing in mind the differences in screen width.

bug 1289147.

> Ubuntu is even worse.

I don't know why/how that would be the case. The styling should be almost identical to Windows, barring differences in font sizing. In any case, that sounds like a different bug.
Well, since most of my icons don't have any text associated with them, then they should certainly be similar based on what you said, but they aren't.

Though the issue of padding on zero-text icons (even if just on Windows) would still be good to resolve. Better of course if its consistent across all OS.

I'm afraid I can't really tell what's causing the differences between the OS, I just thought I'd mention it since it was possible these issues are inter-related.
Attached image Folder width on toolbar
I've just realised something else. Since this bug is progressing slowly (I know, we're all busy), I thought I'd try to use folders to somehow stack more icons onto the toolbar. But as it turns out, that's not great either. Because I can't change the icon from the default folder (not without hacking something anyway), they all look the same. So initially I put a single letter for each, like W for Wikipedia. But that seemed to take up a lot of space (felt like 1.5 times the width of a single icon without text) so I decided to drop the letter and to my astonishment, that does not affect the width the folder icon takes on the bar much (see screenshot). Not sure what benefit all the space is supposed to give.
Has there been any movement on this? Reason I'm asking is that overnight, with no changes on my behalf, I have lost yet another icon's worth of space. This is getting beyond absurd I feel, ever more padding for no end user benefit, certainly not people who max out on using icons to save space.
(In reply to Michael Bauer from comment #20)
> Has there been any movement on this? Reason I'm asking is that overnight,
> with no changes on my behalf, I have lost yet another icon's worth of space.

Could you provide a regression range for this loss?
I don't know of any specific change, so it may have happened by accident.
What do you mean with "regression range"? If you mean the date on which I first noticed it, it was the same day I posted the bug. I'm happy to answer your question but I'm not sure what you mean right now, sorry.
yes sorry, a regression range is the range between 2 changesets, that can be found through tools like mozregression http://mozilla.github.io/mozregression/

Even knowing in which Nightly build the regression appeared first may be of help, but a regression range is the best bet to find out which bug caused the change.
I'm not using a nightly build, I'm just on a the release version, so I'm guessing it was the move to 54.0.1 which was 11 days ago but which probably only landed on my machine 3 days ago.
With photon changing the margin / padding around bookmark items again multiple times, this bug seems a bit pointless now. We have implemented this as specified by shorlander.
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?(dao+bmo)
Resolution: --- → WONTFIX
Who or what is shorlander? Did Photon actually fix this or what? Cause if it didn't, I'll just file another bug...
(In reply to Michael Bauer from comment #26)
> Who or what is shorlander?

Stephen Horlander, UX designer. Here's his mockup (click "Bookmarks Bar" on the left side):

http://design.firefox.com/people/shorlander/photon/Mockups/windows-10.html

> Did Photon actually fix this or what?

It may have fixed it but I suspect it didn't. I didn't go back to compare different Firefox versions.

> Cause if it didn't, I'll just file another bug...

Feel free to do that, though it might end up getting wontfixed too.
Thanks for explaining but, bah humbug, still a gap the size of the Orinoco between them, based on the mockup. Mozilla is really beginning to annoy me...
(In reply to Michael Bauer from comment #28)
> Mozilla is really beginning to annoy me...

I understand this bug is important to you, but you also need to understand that UX designers need to take different factors into account and can't necessarily optimize the UI for different (sometimes conflicting) edge cases affecting only a minority.

If it's any help: there's a compact UI density mode that makes bookmark items a bit narrower.
It's not specifically this bug, it's a sadly lengthening list of reasons but you probably don't want to hear about that here. Let's just say that in this cases - and several others - Mozilla designers mainly seem to mean "the devs we spoke to" when they say "users". There cannot possibly be a *rational* reason for a gap that is up to half the size of the favicon between text-less icons, it'll be some "designer" somewhere who thought this is ugly and who made it "beautiful" in his or her eyes.
Right now, I'm contemplating a move to Chrome or Vivaldi guys. Whoever is hogging the controls over the UI is taking the mickey with the width of the bookmarks toolbar. So I upgrade to 57 and even though I had my bookmarks arranged to fit by grouping some of them into folders, the update pushed about 6-7 of them off the bar. Even setting it to narrow, I still have 4 falling off the side of the bar and I'm out of group-able icons.
Who needs that much blank space between icons anyway? Especially name-less folders seem to have a *massive* amount of empty space on their right side. Someone please show me where user testing or feedback has indicated users *want* that much empty space?
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Michael, please do not reopen a bug that was closed as WONTFIX by the developer in charge of this code (and I followed up via email, in case you read this comment first). It might not sound obvious, but that's misusing your edit_bugs privilege, which you have to be able to manage bugs for your localization.

If this is still a problem in 57 or later, and it's not solved by the compact theme, it could be worth filing a bug for that specific case.
Status: REOPENED → RESOLVED
Closed: 7 years ago7 years ago
Resolution: --- → WONTFIX
(In reply to Michael Bauer from comment #31)
> Especially name-less
> folders seem to have a *massive* amount of empty space on their right side.

This sounds like a bug that be filed apart.
(In reply to Marco Bonardo [::mak] from comment #33)
> (In reply to Michael Bauer from comment #31)
> > Especially name-less
> > folders seem to have a *massive* amount of empty space on their right side.
> 
> This sounds like a bug that be filed apart.

I filed bug 1417386.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: