Open Bug 671611 Opened 9 years ago Updated 6 years ago

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

Categories

(Thunderbird :: Toolbars and Tabs, defect)

6 Branch
x86
Windows 7
defect
Not set
normal

Tracking

(thunderbird7-, thunderbird8-, thunderbird9-)

Tracking Status
thunderbird7 - ---
thunderbird8 - ---
thunderbird9 - ---

People

(Reporter: wsmwk, Unassigned)

References

()

Details

(Keywords: regression, Whiteboard: [gs])

Attachments

(6 files)

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
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.
Version: 5.0 → Trunk
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
Blocks: 668494
FTR, I use 125% (medium) text DPI scaling on windows, at 1680x1050
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.
Attached image 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?
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?
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.
And if possible also with letters like g or y in the lines?
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. :)
please, anyone feel free to try these great suggestions.
it may be some time til I could try this.
Wonder if it shouldn't block bug 533875 because it certainly has a huge impact for netbook user?
(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)
I was thinking that netbook's users will see fewer messages if the space between them is bigger. This could be the issue.
Summary: increased spacing of lines in folder and thread pane on windows → increased spacing of lines in folder and thread pane, and address book on ms-windows
Attached image 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.
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;
}
(seen also in filters. and somewhere else that I now forget)

number of reporters in getsatisfaction is about double from a few days ago
Summary: increased spacing of lines in folder and thread pane, and address book on ms-windows → increased spacing of lines in folder and thread pane, filters, and address book on ms-windows for TB6
Version: Trunk → 6
(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)
Summary: increased spacing of lines in folder and thread pane, filters, and address book on ms-windows for TB6 → increased spacing of lines in folder and thread pane, filters, compose and address book on ms-windows for TB6
Component: Folder and Message Lists → Toolbars and Tabs
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.)
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
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.
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
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.
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.
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).
QA Contact: folders-message-lists → toolbars-tabs
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.
nsTreeBodyFrame::GetRowHeight explicitly considers only coord heights.  It could be changed to handle calc() that consist only of coord heights as well.
(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.
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.
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.
Attached image 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.
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
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
This is Core code and I also don't have Aero to test.
You need to log in before you can comment on or make changes to this bug.