1297485 - Font size has increased in bookmark sidebar after upgrade (should adapt to OS X sidebar icon size setting)

Status: NEW

(Core :: Widget: Cocoa, defect, P3)

Description

[admin]

Attachment: firefox48.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160526140250

Steps to reproduce:

Upgrade from FF47 to 48




Actual results:

Font and spacing seem to have increase in the bookmark tab , see pics attached . Screenshot where taken from the same computer 


Expected results:

Font/Spacing should have remained the same as in all other previous FF version

Comment 1

[admin]

Attachment: firefox47.png

Comment 2

[admin]

If i load FF47 using same profile , its back to normal 
Load back ff48 and font/spacing explode .... odd

Comment 3

[Ciprian Muresan [:cmuresan], Ecosystem QA]

User Agent 	Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:51.0) Gecko/20100101 Firefox/51.0

Hi admin,

I have managed to reproduce your issue on the Firefox (48, Build ID 20160604131506) and the latest Nightly (51.0a1, Build ID 20160825030226). I tried to find a regression window for this issue and have found the following:

Last good revision: b2dbee5ca727e87bdaeab9ab60fb83df2a9846a2
First bad revision: d4ccb3062261c79044eb88f7f63d3afd80740979
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b2dbee5ca727e87bdaeab9ab60fb83df2a9846a2&tochange=d4ccb3062261c79044eb88f7f63d3afd80740979

From there Bug 680256 stands out, but it seems as though the changes were made to improve legibility.

Comment 4

[admin]

Hi Ciprian ,

thank for the info , shouldn't this be made a toggle flag ? Im on a 27" screen and this is very ugly to be honest , feel like a regression rather then an improvement 

Alex

Comment 5

[admin]

Hi 

I just upgrade to ff48 on a fedora desktop and i dont have the issue, fonts/spacing is ok 
So this is targetted at osx I take

Comment 6

[:Gijs (he/him)]

Stephen, thoughts about what to do here? Does the screenshot on this bug look as-intended or is there more work to be done to make this look good?

Comment 7

[Nathan]

I agree that this change is a bug and a regression, not an improvement; I can only view about half as many sites at a time after the change as I could view previously. Please restore the font size/spacing in the bookmarks and history to what it was in all previous FF versions, or provide an option/preference for choosing the font size/spacing in the bookmarks and history. Thanks.

Comment 8

[Stephen Horlander [:shorlander]]

(In reply to :Gijs Kruitbosch from comment #6)
> Stephen, thoughts about what to do here? Does the screenshot on this bug
> look as-intended or is there more work to be done to make this look good?

This is as intended; see: https://bugzilla.mozilla.org/show_bug.cgi?id=680256#c33

Someone suggested respecting the System pref for sidebar item size "System Preferences > General > Sidebar icon size". That seems reasonable to me but would need implementation.

Comment 9

[Nathan]

(In reply to Stephen Horlander [:shorlander] from comment #8)
> (In reply to :Gijs Kruitbosch from comment #6)
> > Stephen, thoughts about what to do here? Does the screenshot on this bug
> > look as-intended or is there more work to be done to make this look good?
> 
> This is as intended; see:
> https://bugzilla.mozilla.org/show_bug.cgi?id=680256#c33

This may be "as intended" but more work needs to be done to make this look good. It looks especially bad on Mavericks (which I am using) and is very inefficient use of screen space when scrolling through hundreds of bookmarks or history. I couldn't agree more with Alex's statement above that "this is very ugly to be honest".

Comment 10

[:Gijs (he/him)]

(In reply to Nathan from comment #9)
> (In reply to Stephen Horlander [:shorlander] from comment #8)
> > (In reply to :Gijs Kruitbosch from comment #6)
> > > Stephen, thoughts about what to do here? Does the screenshot on this bug
> > > look as-intended or is there more work to be done to make this look good?
> > 
> > This is as intended; see:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=680256#c33
> 
> This may be "as intended" but more work needs to be done to make this look
> good. It looks especially bad on Mavericks (which I am using)

Why? What's particularly bad compared to other versions of OS X, and why is it "bad"? Is there any other problem besides the font and spacing being bigger than it previously was? How does this compare with other apps on Mavericks that use native-looking sidebars?

> and is very
> inefficient use of screen space when scrolling through hundreds of bookmarks
> or history.

It sounds like using the search functionality would be useful here.

Just calling things "ugly" or "bad" isn't constructive feedback, and isn't likely to help move this issue forward.

Comment 11

[Nathan]

(In reply to :Gijs Kruitbosch from comment #10)
> (In reply to Nathan from comment #9)
> > (In reply to Stephen Horlander [:shorlander] from comment #8)
> > > (In reply to :Gijs Kruitbosch from comment #6)
> > > > Stephen, thoughts about what to do here? Does the screenshot on this bug
> > > > look as-intended or is there more work to be done to make this look good?
> > > 
> > > This is as intended; see:
> > > https://bugzilla.mozilla.org/show_bug.cgi?id=680256#c33
> > 
> > This may be "as intended" but more work needs to be done to make this look
> > good. It looks especially bad on Mavericks (which I am using)
> 
> Why? What's particularly bad compared to other versions of OS X, and why is
> it "bad"? Is there any other problem besides the font and spacing being
> bigger than it previously was? How does this compare with other apps on
> Mavericks that use native-looking sidebars?

The Mavericks system font is Lucida Grande; the screenshots above show San Francisco, the system font in El Capitan, if I'm not mistaken. The new FF sidebar font spacing in Mavericks does not look like any other app that I have used. It is difficult to compare to other apps, because some other apps (I'm thinking of Scrivener, for example) allow easy customization of the font and size, or at least (as in iTunes) limited control over the size.

Since this change was intentional, perhaps it's not a bug, but if anyone could give instructions on how to revert the sidebar appearance by editing some internal CSS or XML file, please let me know. Thanks.

Comment 12

[Nathan]

I discovered that this issue has already been addressed in the Support Forum and a tip has been provided that uses the Stylish add-on and a custom style rule to change the sidebar font size and spacing. I am still trying to tweak the style rule, but I am hopeful that with a little more work I will find a style rule that works. For the tip, see: https://support.mozilla.org/en-US/questions/1133496

Comment 13

[:Gijs (he/him)]

(In reply to Nathan from comment #11)
> (In reply to :Gijs Kruitbosch from comment #10)
> > Why? What's particularly bad compared to other versions of OS X, and why is
> > it "bad"? Is there any other problem besides the font and spacing being
> > bigger than it previously was? How does this compare with other apps on
> > Mavericks that use native-looking sidebars?
> 
> The Mavericks system font is Lucida Grande; the screenshots above show San
> Francisco, the system font in El Capitan, if I'm not mistaken.

The screenshots were taken by the reporter of the bug, who per comment #0 is actually running El Capitan, so this seems correct. Are you saying that the font is also San Francisco on your 10.9 machine? That would be surprising.

> The new FF
> sidebar font spacing in Mavericks does not look like any other app that I
> have used.

What kind of font spacing? Between characters, or is this still about vertical spacing between lines? The inter-character spacing might have changed (everywhere, not just in the sidebar) for 48 as a result of the switch to the Skia rendering engine. Screenshots of your own of the pre/post behaviour would really help.

> It is difficult to compare to other apps, because some other apps
> (I'm thinking of Scrivener, for example) allow easy customization of the
> font and size, or at least (as in iTunes) limited control over the size.

Calendar/iCal has a main window sidebar, as does addressbook/contacts. Neither of those sizes is configurable, as far as I can see. Are they very different to what we're doing?


(In reply to Stephen Horlander [:shorlander] from comment #8)
> Someone suggested respecting the System pref for sidebar item size "System
> Preferences > General > Sidebar icon size". That seems reasonable to me but
> would need implementation.

Seems this is in NSGlobalDomain NSTableViewDefaultSizeMode, which would need widget/cocoa/ work to expose as an OS-specific constant of some kind that we could then use from CSS - or it would need to be implemented directly. Maybe Stefan knows how to do this? CC'ing him but not needinfo'ing because I'm not convinced how important that is in the grand scheme of things...

Comment 14

[Nathan]

(In reply to :Gijs Kruitbosch from comment #13)
> (In reply to Nathan from comment #11)
> > (In reply to :Gijs Kruitbosch from comment #10)
> > > Why? What's particularly bad compared to other versions of OS X, and why is
> > > it "bad"? Is there any other problem besides the font and spacing being
> > > bigger than it previously was? How does this compare with other apps on
> > > Mavericks that use native-looking sidebars?
> > 
> > The Mavericks system font is Lucida Grande; the screenshots above show San
> > Francisco, the system font in El Capitan, if I'm not mistaken.
> 
> The screenshots were taken by the reporter of the bug, who per comment #0 is
> actually running El Capitan, so this seems correct. Are you saying that the
> font is also San Francisco on your 10.9 machine? That would be surprising.

Yes, I can see that the reporter of the bug is running El Capitan; that's why the font in the reporter's screenshots is San Francisco. I am running Mavericks, so of course my system font is Lucida Grande and the sidebar looks very different for me. The primary problem is interline spacing, although the font size also increased from FF 47 to 48. I don't see the point of comparing FF to Apple's Calendar/Contacts. In any case, I am satisfied with the add-on solution provided at: https://support.mozilla.org/en-US/questions/1133496 and if I had found that solution first, I would not have posted here. (When I first googled the problem, this bug report was the only page I found about the issue.) Thanks.

Comment 15

[Nathan]

(In reply to :Gijs Kruitbosch from comment #13)
> Calendar/iCal has a main window sidebar, as does addressbook/contacts.
> Neither of those sizes is configurable, as far as I can see. Are they very
> different to what we're doing?

It would be more appropriate to compare the latest FF sidebar to the latest Safari sidebar. I think the Safari sidebar is horrible (at least in Mavericks), because the font size and line spacing are too large. This is one of the many reasons why I do not use Safari regularly. If the sidebar change in FF 48 was intended to imitate the latest Safari, then I think the mission was accomplished. Thankfully I have found the solution provided at: https://support.mozilla.org/en-US/questions/1133496 to restore the classic FF sidebar appearance.

Comment 16

[Stefan [:stefanh]]

I guess it's possible (without really digging deeper into this) to implement 3 mac-system-metric's and then have 3 different sets of style rules for each mac-system-metric. Or something like that. In order to match the Apple behavior, we would need 3 different sets of icons, though.

Comment 17

[Stefan [:stefanh]]

(In reply to Stefan [:stefanh] from comment #16)
> I guess it's possible (without really digging deeper into this) to implement
> 3 mac-system-metric's

What I ment was something like this: -moz-system-metric(mac-sidebar-size-small) (one for each size).

Comment 18

[admin]

If its of any value , I did a fresh install of Sierra with FF49 and its the same behavior ( huge spacing in bookmark bar)

Comment 19

[Perry Wagle]

I find it much less readable than before.  Less information on the screen, and double spacing has always been painful to my eyes (some people seem to like it though).  My vote is to allow the user to select what spacing they want.  Many net apps provide this configuration option, such as Feedly.

Comment 20

[Perry Wagle]

This bug has returned in ESR 52 (compared to ESR 45).

What happened?

You really cannot see much of your list of tags again.

Comment 21

[Perry Wagle]

Oh, I see now, this was never actually fixed.

Well, the double spacing is the main issue making the list less than useful.  It'd be like double spacing your programs.

Comment 22

[Perry Wagle]

I could "fix" it, but we have all these people who can't see the problem.

With great trepidation, I note that the font and line spacing of the list of bookmarks uses both a smaller font and less line spacing, so now the two subwindows are inconsistent.  I have bad eyes, and I can easily read the smaller font and line spacing easily, but the larger font and double spacing is hard on my eyes, and I cannot read double spacing quickly.

So I *have* to fix it, at least for myself.  My impression is that webextensions can't hack the CSS any more.  How should I make progress from here, such that everyone is happy?

Comment 23

[Perry Wagle]

The font is now so large that my tag names will no longer fit, and the side window for this list is already pretty wide.

Comment 24

[Perry Wagle]

Hmm..  I finally connected the dots and realized that this probably won't change in the ESR52 series.

I guess I'm still relevant for the current version of firefox?

Comment 25

[:Gijs (he/him)]

(In reply to Perry Wagle from comment #22)
> So I *have* to fix it, at least for myself.  My impression is that
> webextensions can't hack the CSS any more.  How should I make progress from
> here, such that everyone is happy?

My understanding is that we would take a patch that implemented support for the OS X sidebar size pref, see comment #8 / comment #16 .

Comment 26

[Perry Wagle]

(In reply to :Gijs from comment #25)
> (In reply to Perry Wagle from comment #22)
> > So I *have* to fix it, at least for myself.  My impression is that
> > webextensions can't hack the CSS any more.  How should I make progress from
> > here, such that everyone is happy?
> 
> My understanding is that we would take a patch that implemented support for
> the OS X sidebar size pref, see comment #8 / comment #16 .

Ok.  I'm confused by the observation tat only that one place does this odd (to me) behavior.  Shouldn't all the list texts use the same font and spacing, especially in other other subwindows in the same window?

Comment 27

[Perry Wagle]

"Traditionally" (in my mind anyway), Firefox does GUI pretty much its own way (to be somewhat consistent across platforms).  So, having this one thing pay attention to macOS cues seems odd.  How should I think about this?  Is there a change of thinking about GUI?

Comment 28

[:Gijs (he/him)]

(In reply to Perry Wagle from comment #26)
> (In reply to :Gijs from comment #25)
> > (In reply to Perry Wagle from comment #22)
> > > So I *have* to fix it, at least for myself.  My impression is that
> > > webextensions can't hack the CSS any more.  How should I make progress from
> > > here, such that everyone is happy?
> > 
> > My understanding is that we would take a patch that implemented support for
> > the OS X sidebar size pref, see comment #8 / comment #16 .
> 
> Ok.  I'm confused by the observation tat only that one place does this odd
> (to me) behavior.  Shouldn't all the list texts use the same font and
> spacing, especially in other other subwindows in the same window?

I'm not sure what you're referring to. I read comment #22 but I don't understand what other 'list of bookmarks' you're referring to if not the bookmarks sidebar itself. More generally, having toolbars, sidebars and tree/list contents not use the same font size is expected, I think.

(In reply to Perry Wagle from comment #27)
> "Traditionally" (in my mind anyway), Firefox does GUI pretty much its own
> way (to be somewhat consistent across platforms).  So, having this one thing
> pay attention to macOS cues seems odd.  How should I think about this?  Is
> there a change of thinking about GUI?

Some style elements are consistent among platforms, and others aren't (e.g. default fonts, font sizes for many things, button placements (Windows and Linux and OS X use different [OK][Cancel] orderings), etc.).

In this particular case, only OS X has a sidebar-specific size configuration.

Comment 29

[Perry Wagle]

(In reply to :Gijs from comment #28)
> (In reply to Perry Wagle from comment #26)
> > (In reply to :Gijs from comment #25)
> > > (In reply to Perry Wagle from comment #22)
> > > > So I *have* to fix it, at least for myself.  My impression is that
> > > > webextensions can't hack the CSS any more.  How should I make progress from
> > > > here, such that everyone is happy?
> > > 
> > > My understanding is that we would take a patch that implemented support for
> > > the OS X sidebar size pref, see comment #8 / comment #16 .
> > 
> > Ok.  I'm confused by the observation tat only that one place does this odd
> > (to me) behavior.  Shouldn't all the list texts use the same font and
> > spacing, especially in other other subwindows in the same window?
> 
> I'm not sure what you're referring to. I read comment #22 but I don't
> understand what other 'list of bookmarks' you're referring to if not the
> bookmarks sidebar itself. More generally, having toolbars, sidebars and
> tree/list contents not use the same font size is expected, I think.

I mean the editor window you get when you select "Bookmarks -> Show All Bookmarks".  Two different font sizes, two different line spacings.  My eyes are bad now, and they never could easily read double spacing.  Having a large font next to a regular size font really makes it harder to quickly read/scan back and forth (I spend a lot of time in this editor), and likewise with the double spacing or lack of it.  Finally, the large font combined with the double spacing really squanders a lot of vertical space, significantly reducing the amount of information presented, making for my miserable user experience.

I'm having a hard time imagining how a larger font and double spacing improves anyone's user experience.  To me, it just seems to make using bookmarks even more annoying than before, as has been the trend for almost a decade now.  But I'm happy to try to get along with opposing opinions.

My work, which will take me about 1-2 more years, is to make something even better than tags (which would be surprisingly useful if people would stop making tags more and more miserable to use) work.

Unfortunately, I need what I currently can do with tags in order to organize both replace what I have in the new webextension regime, and to then produce this next version.

Finally, just as a metric: the huge font and spacing makes it take about 2x longer for me to use that editor.  That's one hour per day to two hours per day.

I am trying to fix it myself, but to do that, I need understand what the use cases are and be able to model those who like this new way more than the previous way.

PS. I avoided complaining about all the other things.
PPS.  Sorry not to prune this comment down, gotta rush off.

Comment 30

[:Gijs (he/him)]

(In reply to Perry Wagle from comment #29)
snipping liberally:

> My eyes are bad now, and they never could easily read double spacing.


> I'm having a hard time imagining how a larger font and double spacing
> improves anyone's user experience. 

How about: small fonts are harder to read for some other people with bad eyes?

> I am trying to fix it myself, but to do that, I need understand what the use
> cases are and be able to model those who like this new way more than the
> previous way.

I think in this bug the main aim is to make the font size and spacing in the sidebar obey platform conventions / preferences. No more, no less. If you want to make other and/or more sweeping changes (not your 2-year project, I mean, but in terms of the styling here) I would suggest emailing firefox-dev with more details to get feedback, and then work on it in a separate bug.

Comment 31

[Perry Wagle]

(In reply to :Gijs from comment #30)
> (In reply to Perry Wagle from comment #29)
> snipping liberally:
> 
> > My eyes are bad now, and they never could easily read double spacing.
> 
> 
> > I'm having a hard time imagining how a larger font and double spacing
> > improves anyone's user experience. 
> 
> How about: small fonts are harder to read for some other people with bad
> eyes?

I meant in *combination* with normal font and normal spacing.  Having to refocus when bouncing back and forth a window of text is really slow and painful.  Not that I had special needs, the old standard setup worked just fine.  It's this "let's frob one of many pieces and declare victory" attitude that hurts me (every 3 months for 8 years).

Being a real person, I'm wondering why my accessibility needs are superseded by those of imaginary people who aren't even taken care of by this half measure (large fonts everywhere!).  I'd prefer coding to real people, and I don't have that data.

> > I am trying to fix it myself, but to do that, I need understand what the use
> > cases are and be able to model those who like this new way more than the
> > previous way.
> 
> I think in this bug the main aim is to make the font size and spacing in the
> sidebar obey platform conventions / preferences. No more, no less. If you
> want to make other and/or more sweeping changes (not your 2-year project, I
> mean, but in terms of the styling here) I would suggest emailing firefox-dev
> with more details to get feedback, and then work on it in a separate bug.

I'm thinking that choosing that one (obscure?) knob to control one little piece is a bit odd, especially for just one platform.  How does something find it?

I'm thinking ALL text should be resizable with a keyboard control, like command + and -.  Is there a problem with that method, which regretfully isn't supported everywhere?

Recall that you changed normal font and spacing.  Not the other way around, and make it the only way.  I'm trying to do things in life (mathematics!), and having to make fixes to firefox full-time for the rest of my life really is distressing to me.

But yeah, I think going to firefox-dev makes sense.  I just wanted to refine my thinking first, and was hoping for input from several people instead of just beating you up (sorry!).

Comment 32

[Perry Wagle]

I just now made a big uncompileable mess by trying to hg backout of changeset 196a2b799ea0 .

Its rather large, mods to the added stuff have been made since then, and backing the whole thing out is probably overkill anyway.

Any suggestions for a quick fix?  Going to firefox-dev sound more like a log term fix.

Just thought I'd try here one last time before heading to firefox-dev.

Comment 33

[Perry Wagle]

[I will now try to take this to firefox-dev.]

My quick "fix" (that makes me, at least, happy until ESR52 goes away) was the following patch to ESR 52.2.1:

diff --git a/browser/themes/osx/places/organizer.css b/browser/themes/osx/places/organizer.css
--- a/browser/themes/osx/places/organizer.css
+++ b/browser/themes/osx/places/organizer.css
@@ -8,11 +8,9 @@
   background-color: transparent;
   border-color: transparent;
   padding-bottom: 1px;
-  height: 24px;
 }
 
 #placesList > treechildren::-moz-tree-cell-text {
-  font-size: 12px;
   margin-inline-end: 6px;
 }
 
@@ -126,7 +124,6 @@
   list-style-image: url("chrome://browser/skin/places/toolbar.png");
   margin: 4px 4px 5px;
   padding: 0;
-  height: 22px;
   -moz-appearance: toolbarbutton;
 }

Comment 34

[Perry Wagle]

Well, I posted to firefox-dev, and got no response.

Given that the new spacing is hard coded, and doesn't "do it right" by actually paying attention to the cited os-flag and thus giving the user control over it, I propose the fix in comment 33, or else one which gives the user control, which would be more work.

There's a lot more to the original patch that I have no complaint about that I know of.

Do it right, or not at all?

Comment 35

[Perry Wagle]

Is there any way to get this fixed?  Double spacing 13,000 items really wastes vertical space.

Comment 36

[Jonathan Watt [:jwatt]]

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)