671611 - increased spacing of lines in folder and thread pane, filters, compose and address book on ms-windows for TB6

Status: NEW

(Thunderbird :: Toolbars and Tabs, defect)

Description

[Wayne Mery (:wsmwk)]

Attachment: v8 2011-07-14 build, vs v7 2011-06-13

regression between 2011-07-11 and 2011-07-13 (there is no 2011-07-12 .exe nightly build)

per screen shot, increased spacing of lines in folder and thread pane on windows.
reproduces in safe mode.

I didn't find any new bugs in FF, TB or core, with keyword regression created since 2011-07-11

Comment 1

[rsx11m]

If you change listitem, treechildren::-moz-tree-row { min-height: 20px; } does it fix the issue for you? If yes, it's an effect from bug 668494 which landed on comm-central Jul 12 21:50:20 2011 -0700. Units were changed from px to em on purpose to allow scaling with the font size.

Comment 2

[Wayne Mery (:wsmwk)]

Thanks. I'm satisfied bug 668494 is the regressor.  I appreciate the effort there, but I'm not happy with the results - approx 25% less rows in the same space

Comment 3

[Wayne Mery (:wsmwk)]

FTR, I use 125% (medium) text DPI scaling on windows, at 1680x1050

Comment 4

[Rain [:rain1] (inactive)]

If you're using 125% DPI, scaling with the text and having ((125 - 100)/125) = 20% fewer rows seems like the right thing to do.

Comment 5

[Wayne Mery (:wsmwk)]

Attachment: before and after

(In reply to comment #4)
> If you're using 125% DPI, scaling with the text and having ((125 - 100)/125)
> = 20% fewer rows seems like the right thing to do.

Perhaps it is "the right thing". And yet, functionally this change seems to be a poor tradeoff.  More specifically, for the sake of correctness in not having highlight intersect with character descenders per attachment 543117 [details] (not a major bug by any measure) we see way fewer folders in the folder pane, and way fewer messages in the message list, and no improvement in readability. In the attached screen shot, thread pane is 13 messages instead of 16.  (in fairness - a user with smaller screen and a bigger, default sized config toolbar probably loses 1 line instead of the 3 lines that I lose on my bigger screen and reduced size toolbar.)

Put another way, it adds _lots_ of white space to the available screen real estate (one of our constant battles and something we get beat up about).  Note also, the change in line density clashes with the message pane.

I'd prefer not to lose any lines. But if that is not possible, there should at least be some middle ground solution. 10% loss?

Comment 6

[wintogreen]

Whether or not it's "right" from a purely technical point of view, many existing TB users are experiencing this change along the lines of "Why did the message list and folder list in my Thunderbird suddenly change from single spacing to double spacing? And how can I undo this?"

So far, at least 26 people have reported this problem in the gs forums, and more than a few are struggling to manually undo the change via userChrome.css.

Given that this spacing change is immediately noticeable and directly affects how users view (and thus interact with) their message list and folders, was the subtle aesthetic improvement brought with bug 668494 really worth it?

Comment 7

[Blake Winton (:bwinton) (:☕️)]

Wayne,

could you edit mail/themes/qute/mail/messenger-aero.css
and change line 38-ish (The one after "treechildren::-moz-tree-row") from:
     min-height: 1.7em;
to
     min-height: 1.6em;
or
     min-height: 1.5em;

and post screenshots with each of them at 100% and 125% DPI?

Thanks,
Blake.

Comment 8

[Richard Marti (:Paenglab)]

And if possible also with letters like g or y in the lines?

Comment 9

[Jim Porter (:squib)]

Probably the best way to fix this is with -moz-calc. Something like "min-height: -moz-calc(1.5em + 4px);" (note that I am completely, 100% guessing on the actual numbers there).

It should be easy enough to figure out the height by playing with DPI settings and using DOMi to figure out the "ideal" height for a few DPIs and then do some simple curve fitting. I'd do it myself if I weren't on a Linux box at the moment. :)

Comment 10

[Wayne Mery (:wsmwk)]

please, anyone feel free to try these great suggestions.
it may be some time til I could try this.

Comment 11

[Vincent (caméléon)]

Wonder if it shouldn't block bug 533875 because it certainly has a huge impact for netbook user?

Comment 12

[Wayne Mery (:wsmwk)]

(In reply to caméléon from comment #11)
> Wonder if it shouldn't block bug 533875 because it certainly has a huge
> impact for netbook user?

on a netbook, would windows users be playing with DPI?  (I wouldn't think so, but I've never had a netbook)

Comment 13

[Vincent (caméléon)]

I was thinking that netbook's users will see fewer messages if the space between them is bigger. This could be the issue.

Comment 14

[Wayne Mery (:wsmwk)]

Attachment: 125% at some default

-moz-calc(1.5em + 4px)
didn't work for me, it results in the attached screen shot.  Did anyone else get it to work?

The screen shot screams this question ... are characters on these rows top aligned??  It look to me like they are, and would we not have this problem if the characters were centered on the line, just as the icons are centered, like star?


FWIW I tested min-height: 1.4em;  looks great, barely intersecting the bottom of descenders.

Comment 15

[Wayne Mery (:wsmwk)]

Attachment: compose window with 1.5em + 32px

interestingly, per screen shot the compose window picks up the css below, even though 3pane is not

listitem, treechildren::-moz-tree-row {
    min-height: -moz-calc(1.5em + 32px) !important;
}

Comment 16

[Wayne Mery (:wsmwk)]

(seen also in filters. and somewhere else that I now forget)

number of reporters in getsatisfaction is about double from a few days ago

Comment 17

[Wayne Mery (:wsmwk)]

(In reply to Wayne Mery (:wsmwk) from comment #16)
> (seen also in filters. and somewhere else that I now forget)

address list in compose  (perhaps sidebar also, but UI is broke so I can't get there)

Comment 18

[Kuno Meyer]

Sorry for not being constructive; but this here is another bug where I have the strong feeling that Thunderbird's recent UI style modifications are not properly tested before release. (At least not on Windows ... another one is this Glass/Aero/Black-on-Black thing for toolbars.)

Comment 19

[Wayne Mery (:wsmwk)]

dbaron, can you speculate why
  "min-height: -moz-calc(1.5em + 4px);"
is not working in the context of this bug?

ref comment 9, comment 14

Comment 20

[Kuno Meyer]

Please note that the increased line spacing also has an effect on drag-n-drop: the area where messages can be dropped into a folder (in the folder view) hasn't changed, there is now a several pixel wide gap where dropping is not possible.

Comment 21

[Wayne Mery (:wsmwk)]

Does tracking-thunderbird8+ mean we expect to have a working compromise fix in 4 weeks, i.e. near the time v8 closes down beta?  

If not, can we please back out patch of bug 668494

Comment 22

[Richard Marti (:Paenglab)]

I played a little bit with this problem.

The -moz-calc() is working with listitems but not with treechildrens :-(

I tried also this:

@media all and (-moz-windows-default-theme) and (min-resolution: 100dpi) {
  listitem,
  treechildren::-moz-tree-row {
    min-height: 1.4em;
  }
}

This would work with Vista, but unfortunately MS has, concerning <http://minhdanh2002.blogspot.com/2010/03/net-forms-on-windows-7-at-125-zoom.html>, decided to not change the DPI but the font size.

I don't know a media query where I can check the font size or the zoom percentage.

Comment 23

[Jim Porter (:squib)]

I looked at this, and I think the current way is the correct way. At both 100% and 125%, our tree rows are exactly one pixel shorter than the tree rows in Windows Explorer (the selection boxes are actually 2px shorter in Thunderbird, but we don't collapse borders between rows, so we lose 1px from that).

Given that we're being consistent with the rest of Windows, I think it's reasonable for people who want this to be more condensed to add a userChrome customization to tweak the row height.

Comment 24

[Jim Porter (:squib)]

Attachment: Coparison with Windows Explorer

Here's what it looks like next to Windows Explorer. At 100% and 125%, our selection boxes are 2px shorter (so our rows are 1px shorter). At 150%, our selection boxes are 1px shorter (so our rows are the same height).

Comment 25

[David :Bienvenu]

dbaron, ping re comment https://bugzilla.mozilla.org/show_bug.cgi?id=671611#c19 - we'd like to use a mixture of em and pixels when calculating row height, e.g.,

  "min-height: -moz-calc(1.5em + 4px);"

and apparently it doesn't work.

Comment 26

[David Baron :dbaron: 🏴󠁵󠁳󠁣󠁡󠁿 ⌚UTC-8]

nsTreeBodyFrame::GetRowHeight explicitly considers only coord heights.  It could be changed to handle calc() that consist only of coord heights as well.

Comment 27

[David :Bienvenu]

(In reply to David Baron [:dbaron] from comment #26)
> nsTreeBodyFrame::GetRowHeight explicitly considers only coord heights.  It
> could be changed to handle calc() that consist only of coord heights as well.

Great, who could do that? I'd be happy to give it a try, but I'd need a bit more info.

Comment 28

[David Baron :dbaron: 🏴󠁵󠁳󠁣󠁡󠁿 ⌚UTC-8]

Modeling the code off the handling of calc() in nsIBox::AddCSSPrefSize should work (including needing the <0 check).  The logic for what happens if there's a (non-percent) width is different between the two functions, but the APIs needed are the same.

Comment 29

[Mark Banner (:standard8) (afk until 26 Oct)]

Due to the gecko changes we don't think we're going to get this into 8. So we'll look to pushing it for 9.

Comment 30

[Wayne Mery (:wsmwk)]

Attachment: TB full compose window

If one is a user who is in compose a lot, I could see this being a major pain - the compose window address area uses about 1/3 of the available screen height.

Comment 31

[Wayne Mery (:wsmwk)]

https://addons.mozilla.org/en-US/thunderbird/addon/address-widget-lines/ (mentioned in bug 425451) does a nice job of mitigating the impact in compose window

Comment 32

[Wayne Mery (:wsmwk)]

With David's leaving we seem to have totally stalled in trying comment 27. 

To sum up the user situation, some workarounds don't always work:
- ignore aero broken in TB17 https://getsatisfaction.com/mozilla_messaging/topics/way_to_get_rid_of_new_white_space_in_t_b_6s_window_panes#reply_10703944
- css is beyond some users ... several in the vicinity of - https://getsatisfaction.com/mozilla_messaging/topics/way_to_get_rid_of_new_white_space_in_t_b_6s_window_panes#reply_6486305

Comment 33

[:aceman]

This is Core code and I also don't have Aero to test.