Open
Bug 671611
Opened 11 years ago
Updated 2 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)
Tracking
(thunderbird7-, thunderbird8-, thunderbird9-)
NEW
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.
Reporter | ||
Comment 2•11 years ago
|
||
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
Reporter | ||
Comment 3•11 years ago
|
||
FTR, I use 125% (medium) text DPI scaling on windows, at 1680x1050
Comment 4•11 years ago
|
||
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.
Reporter | ||
Comment 5•11 years ago
|
||
(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?
Reporter | ||
Updated•11 years ago
|
Whiteboard: [gs]
Comment 6•11 years ago
|
||
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•11 years ago
|
||
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•11 years ago
|
||
And if possible also with letters like g or y in the lines?
Comment 9•11 years ago
|
||
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. :)
Reporter | ||
Comment 10•11 years ago
|
||
please, anyone feel free to try these great suggestions. it may be some time til I could try this.
Comment 11•11 years ago
|
||
Wonder if it shouldn't block bug 533875 because it certainly has a huge impact for netbook user?
Reporter | ||
Comment 12•11 years ago
|
||
(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•11 years ago
|
||
I was thinking that netbook's users will see fewer messages if the space between them is bigger. This could be the issue.
Reporter | ||
Updated•11 years ago
|
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
Reporter | ||
Comment 14•11 years ago
|
||
-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.
Reporter | ||
Comment 15•11 years ago
|
||
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; }
Reporter | ||
Comment 16•11 years ago
|
||
(seen also in filters. and somewhere else that I now forget) number of reporters in getsatisfaction is about double from a few days ago
tracking-thunderbird7:
--- → ?
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
Reporter | ||
Comment 17•11 years ago
|
||
(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
Updated•11 years ago
|
Component: Folder and Message Lists → Toolbars and Tabs
Comment 18•11 years ago
|
||
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.)
Reporter | ||
Comment 19•11 years ago
|
||
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•11 years ago
|
||
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.
Updated•11 years ago
|
tracking-thunderbird8:
--- → +
Reporter | ||
Comment 21•11 years ago
|
||
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•11 years ago
|
||
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•11 years ago
|
||
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•11 years ago
|
||
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).
Updated•11 years ago
|
QA Contact: folders-message-lists → toolbars-tabs
Comment 25•11 years ago
|
||
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•11 years ago
|
||
nsTreeBodyFrame::GetRowHeight explicitly considers only coord heights. It could be changed to handle calc() that consist only of coord heights as well.
Comment 27•11 years ago
|
||
(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•11 years ago
|
||
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•11 years ago
|
||
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.
tracking-thunderbird9:
--- → +
Updated•11 years ago
|
tracking-thunderbird10:
--- → ?
Reporter | ||
Comment 30•11 years ago
|
||
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.
Reporter | ||
Comment 31•10 years ago
|
||
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
tracking-thunderbird10:
? → ---
Reporter | ||
Comment 32•10 years ago
|
||
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•10 years ago
|
||
This is Core code and I also don't have Aero to test.
Reporter | ||
Updated•2 years ago
|
Severity: normal → S4
You need to log in
before you can comment on or make changes to this bug.
Description
•