Open Bug 82122 Opened 20 years ago Updated 6 years ago
Account Manager window size is too large for tiny screens (640*480 etc)
Build: 2001052115, Mac OS 9.1 To reproduce: * Switch to 640*480 resolution, if indeed you had a choice of any resolution higher than that to begin with. * Open the Account Manager. * Try to get anything done. What should happen: * You can. What actually happens: * You can't. The Account Manager needs to be shrunk like the main Preferences window was. Currently, it is practically unusable at low resolution. See also bug 57956 and bug 66001.
*** Bug 82121 has been marked as a duplicate of this bug. ***
Not Macintosh specific. -> All.
OS: Mac System 9.x → All
Hardware: Macintosh → All
Why is this assigned to Ben? This is Bhuvan's area.
Reassinging to myself. Adding Jennifer & Robin to the cc list. bhuvan
Assignee: ben → racham
Reassinging to myself -> Reassigning to myself. We need a spell checker in bugzilla :-) Accepting.
Status: NEW → ASSIGNED
*** Bug 84102 has been marked as a duplicate of this bug. ***
Nominating for nsbeta1. Without fixing this bug the account settings window is unusable at lower resolutions.
putterman: Why do you think this should be left unfixed for the next Netscape beta? I disagree, since this severely impairs accessibility to users with special needs; namely, lower screen resolutions (640x480) and tab navigation. At the default size several fields are unviewable in the account settings window. Netscape needs to be extra careful to make sure users with special needs are not ignored in public releases.
First off, Skewer, can you please argue with putterman over Netscape efforts in private emails or elsewhere? Unless you have a patch for this or otherwise can help fixing this bug faster, do not comment because it will not help anyone. Secondly, I think this bug should be made a meta-bug. We can't just shrink the size of this window, because we'll need to make the panels take up less space first. Nbaca, could we add some dependencies?
If putterman can suggest a reason why this is not important enough to be fixed for the next Netscape beta, that information will be important to this bug. Typically Netscape engineers will explain why a bug doesn't need to be fixed or offer a workaround (in this case there's no good workaround) when they accept or reject a nsbeta1 nomination. Right now users at 640x480 or who use the keyboard to navigate the account settings window have no alternatives. I agree that this should be a meta bug, since the underlying problem that causes this is unacceptable pref panels.
Assignee: racham → sspitzer
Status: ASSIGNED → NEW
On Windows 2000, with small fonts: I created a new GIMP window 600x400 pixels in size (plus titlebar and scrollbars) and turned off the status bar and rulers. This gives an approximate maximum window size for Mozilla dialogs on small displays, so that I can check which panels are the biggest offenders. Then I opened a Mozilla build from mid-August, using the 'Modern' theme. Result: No panel needs the window to be wider than the reference window. Only the news.isp.com > Offline & Disk Space panel needs the window to be taller than the reference window. Reporter: Is this still a problem with a more recent Mozilla app suite build such as the fresh 1.5 Beta? Does the Mac version use bigger fonts or more whitespace or something?
I've some different idea To make this fix... Instate to Forcing People To getting a BIGGER or Higher Resolution. I suggest that make the scroll bar for the configuration Screen. So that even if they are running on a lower resolution, you can still scrool through... Isn't that Nice?
Chan Min Wai, that's bug 54679, which is WONTFIX because it's a very bad idea.
Then Use Tab within It. It organization the Configuration better, If it is not being misuse.
I fixed bug 57956 and made the Account Manager window a bit smaller, too. Is this bug still an issue now?
This screenshot shows the Account Settings' Offline & Disk Space pane for a news-account on a freshly installed Windows XP with 640x480. This is the largest pane of the Account Settings dialog. The dialog is basically useable, but the dialog buttons and the title bar are cut. With 800x600 there is no problem anymore.
(In reply to comment #17) > I fixed bug 57956 and made the Account Manager window a bit smaller, too. Is > this bug still an issue now? yes - namely, the whole fixed-(too-big)-size-prefs-panels is and likely remain an issue, until it's realized that eg old Chan Min Wai's suggestion is wise and correct, while conclusions for WONTFIX in bug 54679 are wrong. Wrong because based on assumtions of too tight control over what end user environment might be. As noted, esp. in *nix/X, combination of screen size and point size/dpi may lead to an unusable prefs panels. Late real example experience: I had to guide a guy on the other side of the ocean to setup Mozy, through VNC; he was on 1600x1400, with due dpi, but due to bandwith I setup a vnc window only 600x400x8 (and I'm on a 800x600 LCD on a small notebook anyway). Prefs panel in my window was largely unreachable, and I had to play a lot with windowmanager's key shortcut to resize it. It took 30' what could be accomplished in 5'. Next I setup plan(1), you know, the motif-styled calendar; option/setup panels there may be quite rough and old styled, and on opening they take smallest size enough to show all widgets - which usually means for me they go beyond screen. But ask the windowmanager to enforce panel windows within screen, and voila' it gets resized and a couple scrollbars appears, which allows for not-so-bad navigation around panel items. Bottom line: Mozy prefs panel may be designed according to sound human-computer interface criteria (www.iarchitect.com, as mentioned in bug 54679), but turns out to be almost unusable in some not-so-exoteric situation, while plan's quickly crafted prefs interface remains usable. Now, which one is the bad idea, then? Please have the panels and widgets to auto-size to always show up in full, and if screen area real estate isn't enough, popup scrollbars to let the user do its job anyway.
QA Contact: nbaca
Target Milestone: Future → ---
Assignee: mail → nobody
Component: MailNews: Account Configuration → Backend
Product: SeaMonkey → MailNews Core
QA Contact: backend
You need to log in before you can comment on or make changes to this bug.