Initial Mail & News window width and Preferences dialog can't accommodate Lightning elements, cut off contents

RESOLVED FIXED in seamonkey2.46

Status

defect
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: rsx11m.pub, Assigned: rsx11m.pub)

Tracking

SeaMonkey 2.44 Branch
seamonkey2.46
Dependency tree / graph

SeaMonkey Tracking Flags

(seamonkey2.44 fixed, seamonkey2.45 fixed, seamonkey2.46 fixed)

Details

Attachments

(9 attachments, 3 obsolete attachments)

Assignee

Description

3 years ago
Historically, SeaMonkey's Mail & Newsgroup window opens with a fixed size in a new installation/profile, which was apparently based on an 800x600 screen resolution. Bug 516026 added Lightning by default for 2.44+, which requires additional horizontal space. As a result, content is cut off and the notification about Lightning being activated is wrapped for each word.

I'm aware of bug 433001 to make the messenger window open with a dynamic size based on the screen resolution, but that may require some thinking given that Mail & News opens on top of the browser window and probably shouldn't cover it completely, unless a minimum size needs to be maintained.
Assignee

Comment 1

3 years ago
Posted patch Adjust default window sizes (obsolete) — Splinter Review
As an immediate fix suitable for current beta, the current width of 60em should be increased to 82em, at which size the tool and status bars are fully extended, and the Lightning components can be reasonably accommodated. The height has been adjusted from 40em to 50em to maintain pleasing proportions of the window.

This size increases the minimum screen resolution from 800x600 to 1024x768.
Assignee: nobody → rsx11m.pub
Status: NEW → ASSIGNED
Attachment #8752499 - Flags: review?(philip.chee)
Assignee

Comment 2

3 years ago
Posted image Screenshot (Linux)
This screenshot shows the problematic current size on top of the proposed size in a GTK3 beta build, taken on Linux with KDE 4 and default oxygen desktop theme.
Assignee

Comment 3

3 years ago
Posted image Screenshot (Windows)
Here the same for Windows 7 with its default Aero theme. The label in the notification bar still has to wrap, but looks with just 2 lines much better than before. This still fits a 1024px-wide screen with 12px to spare on either side beyond the window decoration.
Assignee

Updated

3 years ago
Attachment #8752499 - Attachment description: bug1272888.patch → Adjust default window sizes
Could you check the preferences window. Since lightning is enabled it seems to be initially not wide enough too. The timezone box might be the problem.
Assignee

Comment 5

3 years ago
That opens automatically in the right size for me on trunk. Meaning, opening Edit > Preferences show it in normal size if Lightning is disabled, and about 70px wider if it's enabled, thus taken care of.

I don't think we should increase the default width given that the window resizes automatically as needed (that's different for the Mail & News 3-pane window which is fixed until the user changes it manually). The obvious other option would be to redesign the Calendar prefpane to use up less width, but that's for a different bug.
Assignee

Comment 6

3 years ago
(In reply to Frank-Rainer Grahl from comment #4)
> The timezone box might be the problem.

Yeah, that's not straight-forward. Have a look at http://mxr.mozilla.org/comm-central/source/calendar/base/content/preferences/general.xul#88 which would need to wrap that hbox if insufficient space is provided (which obviously it doesn't). On the other hand, you won't convince the Thunderbird people to split this into a second line, given that their Options window is much wider but less higher. Thus, Lightning would have to figure out if which application it's running on, then make that either an <hbox> for Thunderbird or a <vbox> for SeaMonkey.
Posted image Preferences 2.43 ok
Hmm I wonder why you don't see it. Here are the 2.43 preferences. No Lightning in profile. Looks ok.
Preferences 2.46 cut off to the right with Lightning.
Personally I would make the preferences dialog wider. 1024x768 should have almost died by now. WXGA 1200x1800 and SXGA+ 1400x1050 would be ok with it.

Height is always a problem due to the HD Ready garbage still sold.
Just found Bug 983689 which shows that the preferences dialog seems not to be recent.
Make that 'preferences dialog problem' grumble... Too fast again.
Assignee

Comment 12

3 years ago
Indeed I'm confused now myself. On Windows 7, the Preferences window has a width of 640px without and 705px with Lightning installed, without me touching anything. On the other hand, without Lightning enabled, going from Browser to Browser > History resizes content without resizing the window, but without contents cut off (just the padding is truncated). I yet have to check on Linux.

Here another report, showing a hybrid of what you vs. myself have observed:

(Quoting Rainer Bielefeld from bug 1215150 comment #0)
> Additional information:
> a) when you drag and drop right dialog border to the right, the border 
>    "jumps" few cm to the right until dialog width is appropriate.
> b) further opening of 'Edit → Preferences' always will show dialog with
>    sufficient width
 
Since there is a Lightning-pref specific bug already regarding the preferences window, let's apply the band-aid for the prefs in bug 983689 and keep this one here for the 3-pane window. The specific issue of the pref window not resizing as needed (it does so for the height, e.g., when entering the Advanced > Mouse Wheel prefpane) should be investigated in bug 1215150. 

(In reply to Frank-Rainer Grahl from comment #9)
> Personally I would make the preferences dialog wider. 1024x768 should have
> almost died by now. WXGA 1200x1800 and SXGA+ 1400x1050 would be ok with it.

Plenty of 1366x768 notebooks out there for sale, so let's consider that the minimum requirement.
The lowest assumption that you can maintain without compromising is probably the best.
Assignee

Comment 13

3 years ago
Actually, bug 983689 was opened for a different reason, i.e., the preferences window being clipped on a 1024x600 notebook. Maybe let's just take care of the size fallout from bug 516026 here for both.

For Windows 7 with default fonts and desktop theme (tested Aero and Classic), the width needs to be increased from 52em to 58em. While there, I'd also increase the height from 41em to 43em, to avoid dynamic resizing of the preference window height in the SSL/TLS and Mouse Wheel panes.
Blocks: 983689, 1215150
Component: MailNews: Message Display → MailNews: General
Summary: Initial Mail & News window width can't accommodate Lightning elements, cuts off contents on first run → Initial Mail & News window width and Preferences dialog can't accommodate Lightning elements, cut off contents
Assignee

Comment 14

3 years ago
Please try this in your 2.46 build.
Attachment #8752499 - Attachment is obsolete: true
Attachment #8752499 - Flags: review?(philip.chee)
Attachment #8752575 - Flags: feedback?(frgrahl)
Assignee

Comment 15

3 years ago
Comment on attachment 8752575 [details] [diff] [review]
Adjust messengerWindow and prefWindow sizes

Stefan, can you please check if any changes are necessary for platformPrefOverlay.dtd on Mac OSX?
Attachment #8752575 - Flags: feedback?(stefanh)
P seems to be a problem but only on netbooks with 600 px. XP support seems to be on the way out anyway due to ICU which dropped it for V 58 so I wouldn't bother much.
Attachment #8752575 - Flags: feedback?(frgrahl) → feedback+
Assignee

Comment 19

3 years ago
(In reply to Frank-Rainer Grahl from comment #18)
> XP seems to be a problem but only on netbooks with 600 px.

Yeah, that's what bug 983689 is about. However, fonts can be squeezed by switching off DirectWrite font rendering as described in bug 983689 comment #9, then it should fit there as well.

Thanks for testing.
Comment on attachment 8752575 [details] [diff] [review]
Adjust messengerWindow and prefWindow sizes

Hmm, I downloaded a nightly (build failures...) and had to enable Lightning in the Add-ons manager for every new round with a new profile. I guess that's how it is (I don't normally use Lightning)?

Anyway, I had to hack the files in omni.ja to test this. You'll need to change the width in suite/locales/en-US/chrome/common/pref/mac/platformPrefOverlay.dtd to 62em to make it look nice. The height is OK.

Regarding the messenger.xul changes, I think the window is still a bit horizontally crammed - the text in the notification bar looks a bit funny with its 3 lines. A width of 86em makes it look better.
Attachment #8752575 - Flags: feedback?(stefanh)
Assignee

Comment 21

3 years ago
(In reply to Stefan [:stefanh] from comment #20)
> Hmm, I downloaded a nightly (build failures...) and had to enable Lightning
> in the Add-ons manager for every new round with a new profile. I guess
> that's how it is (I don't normally use Lightning)?

Yes, something weird is going on with trunk builds and add-ons, it was disabled for me as well, but works as advertised on aurora and beta builds.

> Anyway, I had to hack the files in omni.ja to test this. You'll need to
> change the width in
> suite/locales/en-US/chrome/common/pref/mac/platformPrefOverlay.dtd to 62em
> to make it look nice. The height is OK.

Ok, I'll do that.

> Regarding the messenger.xul changes, I think the window is still a bit
> horizontally crammed - the text in the notification bar looks a bit funny
> with its 3 lines. A width of 86em makes it look better.

Probably because Mac uses bold fonts for UI labels? This would push it by 20px beyond a minimum 1024x768 screen on Windows though, thus maybe we'd need some platform-specific sizing here as well (on the other hand, it's just the first-time startup, the window will retain the size the user has chosen; in contrast, the Preferences window opens in the default dimensions every time).
(In reply to rsx11m from comment #21)
> Regarding the messenger.xul changes, I think the window is still a bit
> > horizontally crammed - the text in the notification bar looks a bit funny
> > with its 3 lines. A width of 86em makes it look better.
> 
> Probably because Mac uses bold fonts for UI labels? This would push it by
> 20px beyond a minimum 1024x768 screen on Windows though, thus maybe we'd
> need some platform-specific sizing here as well (on the other hand, it's
> just the first-time startup, the window will retain the size the user has
> chosen; in contrast, the Preferences window opens in the default dimensions
> every time).

I guess we'll have to live with it for now. But it would probably be much better to have the window sizes in a .dtd file. I'm quite sure that the messenger window will look bad in some locales (I know for instance that the sv-SE prefwindow is wider than the en-US one, at least the mac one).
Assignee

Comment 23

3 years ago
Posted patch Proposed patch (v3) (obsolete) — Splinter Review
Initial width of the Preferences dialog for Mac OSX adjusted to a width of 62em per comment #21. For Linux with GTK3, I actually had to go up to 65em to accommodate the Lightning prefpane; also increased height by 3em to now 44em there, which allows the SSL/TLS pane be displayed with resizing. It still "jumps" when going into the Mouse Wheel pane on Linux, but 46-47em as height seemed to be excessive and that's a pane nobody will use on a regular basis.

(In reply to Stefan [:stefanh] from comment #22)
> I guess we'll have to live with it for now. But it would probably be much
> better to have the window sizes in a .dtd file. I'm quite sure that the
> messenger window will look bad in some locales

Before we go there, let's rather fix bug 433001 and open in a size based on the actual screen size (then we only need to specify a minimum default size, which can be 1024px to cover all elements).

I'll look into bug 983689 next, given that we increase the size for prefDialog here. Today a similar fix for the Account Settings checked in, which makes a nice template for the Preferences pane.

(In reply to Stefan [:stefanh] from comment #20)
> Hmm, I downloaded a nightly (build failures...) and had to enable Lightning
> in the Add-ons manager for every new round with a new profile. I guess
> that's how it is (I don't normally use Lightning)?

Actually, all shipped extensions are disabled in a new profile on trunk. I've filed bug 1273298.
Attachment #8752575 - Attachment is obsolete: true
Attachment #8753097 - Flags: review?(philip.chee)
Assignee

Comment 24

3 years ago
(In reply to rsx11m from comment #23)
> For Linux with GTK3, I actually had to go up to 65em to accommodate
> the Lightning prefpane; also increased height by 3em to now 44em there,
> which allows the SSL/TLS pane be displayed [without] resizing.

Well, I've tried this with a GTK2 build (which is what current release builds use) on a different machine with KDE4 which has a smaller desktop font. While I thought that the purpose of the "em" units is to abstract from actual font sizes, the window size feels a bit excessive on that particular setup.

I'm wondering what the "optimal" settings are here. Given that bug 1215150 doesn't apply on Linux, a compromise might be to meet those half-way with 58em width and 43em height, then let Lightning resize the window as needed on its own when it's enabled (works on KDE4, don't know about Gnome desktop).

Can anybody else test 65/44em and 58/43em on Linux with a few more variants to get a better idea?

Comment 25

3 years ago
Comment on attachment 8753097 [details] [diff] [review]
Proposed patch (v3)

rs+ for osx and gtk2/3 parts. I think we should switch to using "ch" units for widths instead since we're touching this part of the codebase. You'll have to retest of course. Apologies for the extra work.
Attachment #8753097 - Flags: feedback+
Assignee

Comment 26

3 years ago
(In reply to Philip Chee from comment #25)
> rs+ for osx and gtk2/3 parts. I think we should switch to using "ch" units

Please elaborate:
 - leave {mac,unix}/platformPrefOverlay.dtd as "em" but change win/platformPrefOverlay.dtd to "ch"?
 - switch messenger.xul width from "em" to "ch"?
 - that's not just a fixed ratio, I assume?
Flags: needinfo?(philip.chee)
Assignee

Comment 27

3 years ago
(In reply to rsx11m from comment #26)
>  - that's not just a fixed ratio, I assume?

Ok, it is not: with Windows 7 Aero desktop theme, it's about 1em = 1.7ch, with Windows Classic 1.83ch, relative to -moz-dialog fonts.

(In reply to rsx11m from comment #24)
> on a different machine with KDE4 which has a smaller desktop font. While I thought
> that the purpose of the "em" units is to abstract from actual font sizes, the window
> size feels a bit excessive on that particular setup.

This may be the reason for the window being "oversized" with narrower fonts, where I'd expect the em/ch ratio being stronger than with regular system fonts.
Assignee

Comment 28

3 years ago
(In reply to rsx11m from comment #27)
> Ok, it is not: with Windows 7 Aero desktop theme, it's about 1em = 1.7ch,
> with Windows Classic 1.83ch, relative to -moz-dialog fonts.

... and in a XUL context, it's even closer to 2.0ch/em.

For Windows 7, I end up with the Preferences width going from 58em to 115ch, while the 3-pane window goes from 82em to 162ch. I'll check the dimensions on Linux tomorrow.
Flags: needinfo?(philip.chee)

Comment 29

3 years ago
> Please elaborate:
>  - leave {mac,unix}/platformPrefOverlay.dtd as "em" but change
> win/platformPrefOverlay.dtd to "ch"?
>  - switch messenger.xul width from "em" to "ch"?
>  - that's not just a fixed ratio, I assume?
Sorry. I meant I can only test on Windows. If you come up with reasonable and tested values for Linux I'm happy to accept your numbers.

ch units came later than em units. Different fonts have different x-heights complicating the use of em for width; ch was invented to make things easier.
Assignee

Comment 30

3 years ago
Thanks for the explanation. Indeed, actual widths depend quite a bit on the font's shape with "ch" units.

>+++ b/suite/locales/en-US/chrome/common/pref/win/platformPrefOverlay.dtd
>-<!ENTITY  prefWindow.size             "width: 52em; height: 41em;">
>+<!ENTITY  prefWindow.size             "width: 58em; height: 43em;">

I've changed this to 115ch per comment #28 which looks fine on Windows 7 with both Aero and Windows Classic desktop themes.

>+++ b/suite/locales/en-US/chrome/common/pref/unix/platformPrefOverlay.dtd
>-<!ENTITY  prefWindow.size             "width: 52em; height: 41em;">
>+<!ENTITY  prefWindow.size             "width: 65em; height: 44em;">

On Linux, the difference between "em" and "ch" is substantial. I went with 102ch, which provides a minimally larger width than 65em with the wide fonts and GTK3, while showing now pleasing results with the narrower fonts and GTK2 on the other machine. So, that helped a lot and is hopefully generic enough for different font types.

>+++ b/suite/locales/en-US/chrome/common/pref/mac/platformPrefOverlay.dtd
>-<!ENTITY  prefWindow.size             "width: 58em; height: 41em;">
>+<!ENTITY  prefWindow.size             "width: 62em; height: 41em;">

Since I don't have a Mac either, I've left the 62em as provided by Stefanh.

>+++ b/suite/mailnews/messenger.xul
>-        style="width: 60em; height: 40em;"
>+        style="width: 82em; height: 50em;"

That one I've left in "em" rather than "ch" too. On Linux with the wider fonts, it resulted in a Mail & News window >1280px which appears disproportionately wide. The main factor here are toolbar icons and column widths, which don't depend that much on the font dimensions, thus "em" seems more neutral, and the ultimate solution here should come with bug 433001 anyway.

For all test scenarios, the Preferences window fit into an 800x600 frame, and the Mail & News window would fit on a 1024x768 screen.
Attachment #8753097 - Attachment is obsolete: true
Attachment #8753097 - Flags: review?(philip.chee)
Attachment #8755558 - Flags: review?(philip.chee)
Assignee

Updated

3 years ago
Attachment #8755558 - Attachment description: bug1272888v4.patch → Updated patch (v4)

Comment 31

3 years ago
Comment on attachment 8755558 [details] [diff] [review]
Updated patch (v4)

r=me thankz!
Attachment #8755558 - Flags: review?(philip.chee) → review+
Assignee

Comment 32

3 years ago
Comment on attachment 8755558 [details] [diff] [review]
Updated patch (v4)

[Approval Request Comment]
Regression caused by (bug #): bug 516026
User impact if declined: problems with window width after Lightning additions
Testing completed (on m-c, etc.): works on 2.45 and 2.44 builds
Risk to taking this patch (and alternatives if risky): low
String changes made by this patch: none (but localizers may need to adjust widths in their DTDs)
Attachment #8755558 - Flags: approval-comm-beta?
Attachment #8755558 - Flags: approval-comm-aurora?

Comment 33

3 years ago
Comment on attachment 8755558 [details] [diff] [review]
Updated patch (v4)

a=me for comm-aurora and comm-beta
Attachment #8755558 - Flags: approval-comm-beta?
Attachment #8755558 - Flags: approval-comm-beta+
Attachment #8755558 - Flags: approval-comm-aurora?
Attachment #8755558 - Flags: approval-comm-aurora+
Assignee

Comment 34

3 years ago
Thanks, so given bug 983689 comment #16, let's just land this here as is on the branches and revisit as necessary if and when another bug makes the Calendar prepane leaner.
(In reply to rsx11m from comment #32)
> String changes made by this patch: none (but localizers may need to adjust
> widths in their DTDs)
Technically, those are string changes.

I assume you can’t change the string IDs, but could you send a note to dev.l10n explaining to localizers what need to be tested and changed, please? Most won’t notice this change. Also would be great if you could point out to builds, not sure where to find them until bug 1222878 is fixed.

Thanks!
Flags: needinfo?(rsx11m.pub)
Assignee

Comment 37

3 years ago
Théo, thanks for the reminder. That was on my list and I've just sent the message.
It should show up in the newsgroup shortly, I hope (sometimes it takes a while).
Flags: needinfo?(rsx11m.pub)
You need to log in before you can comment on or make changes to this bug.