The preferences dialog size should be fixed at a smaller size (closer to 4.x), this size should be specified in ems and the dialog should be made non- resizable (Preferences is a dialog, not a window).

Looks ok to me. r/sr=waterson, whichever helps.

I think the patch is ok, but this is going to cause a world of hurt. ;-) r=pchen

Fixed.

indeed --see bug 80304.

I'm not sure we need to constrain the user like this. Maybe a minimum size, but ? why a maximum? Some content doesn't fit in this area, that's been an on-going problem, and resizing the window -> larger is a workaround. reopening for explaination.

Because (on Windows, at least) it shouldn't be resizable. And sure, it's a good workaround -- too good. What better impetus to get people to fix their crappy pref panes than to make it literally impossible to see all the options if they don't fit? Not sure why Ben did it right before Netscape had its UI freeze, but that's really none of my concern...

*** Bug 80304 has been marked as a duplicate of this bug. ***

*** Bug 80333 has been marked as a duplicate of this bug. ***

While it's nice to have a standard sized pref window, we need to figure out w/ UE's help how to move the other prefs that aren't getting seen (primarily LDAP prefs) into the preferences window. The timing is poor considering today is the deadline for non-PDT controlled checkins. This will require reworking of LDAP prefs. =>Jennifer needs time to rework the spec =>Srilatha needs time to reimplement Prefs code =>blocking of testing and usage of LDAP functionality (can't add/edit LDAP directories) =>possibility of regressions in the new LDAP prefs code Was this checkin to resolve a blocker? It's certainly blocking our testing. I'm changing severity accordingly to "blocker".

I'll start working at re-working the affected mail related dialogs. Agree it would be nice to have more time for this since a lot of dialogs are affected.

I know this would be a separate bug, but what do folks think about removing the "Category" text from the top left and removing the Heading area and text from the top of the prefs dialogs? "Category" shouldn't really be necessary and currently the heading label just repeats the text that is already selected in the list on the left. This would give us a little more space. Worth filing a separate bug about?

Ironically, shrinking the category tree in the pref window made the panels wider, and my examination of the panels showed only one or two that didn't fit (and the overflow was small). Yes, we could probably remove the Category header. File another bug on me if you like, triage it into .9.1 or .9.2 and it'll show up on my radar. This bug is being closed again as it has been fixed. The prefwindow is resizable and of a fixed size.

Also, all panels that don't fit should get bugs. I believe there's already one for the outstanding mail panel, and trudelle mentioned filing one on the LDAP panel.

bug # 80304 ( about LDAP panel) was marked as a dup of this one...

ben wrote: > Yes, we could probably remove the Category header. File another bug on me if > you like, triage it into .9.1 or .9.2 and it'll show up on my radar. jglick, i'd actually hold off on filing that bug, since bug 78261 suggests a use for that header as means of navigating btwn the right-hand panel and the category tree: ------- Additional Comments From Aaron Leventhal 2001-05-11 13:31 ------- I would just put an accesskey on "Category", so the user can press Alt+C to get to that [right-hand panel] from the dialog. o'course, that's currently blocked by bug 959... :-/

to keep myself sane, i've created a meta bug to track pref panels whose content needs readjusting in order to fit: bug 80392. feel free to add bugs as blockers to 80392. thx!

sairuh, I already filed the bug as 80394 (sorry). It can be marked invalid if folks agree. But I think it would be nice if the duplicate Header Label can be removed as well as "Category". Is there another way to do the shortcuts? Like maybe Shift+Tab to switch between the list and the contents on the right?

*** Bug 80450 has been marked as a duplicate of this bug. ***

*** Bug 80137 has been marked as a duplicate of this bug. ***

> Because (on Windows, at least) it shouldn't be resizable. Rubbish. There are plenty of resizable dialog boxes in Windows and its applications. > And sure, it's a > good workaround -- too good. What better impetus to get people to fix their > crappy pref panes than to make it literally impossible to see all the options > if they don't fit? Translation: "We need to make life harder for our users in order to get our developers to do the right thing." That is a poor argument. The prefs dialog should be resizable, with a reasonable preset minimum size. Anyway, we've argued over this before. I solved the problem for myself by switching to Linux, where my window manager makes everything resizable whether Mozilla's developers approve or not.

> Rubbish. There are plenty of resizable dialog boxes in Windows and its > applications. When the resizability was needed because the dialog's designers couldn't manage to make its contents fit? Which ones are you referring to, specifically? > Translation: "We need to make life harder for our users in order to get our > developers to do the right thing." Months away from Mozilla 1.0, there's really no danger in doing this, now is there? Everything up until then is a beta version, with quirks far worse than this. But the answer to your question is largely yes. If developers won't abide by the rules, then maybe they will when they have no other choice. In the time that people (developers of these panels included) spent whining about this tonight, they could have fixed every single problematic panel. To prove this, Ben set out last night to do it -- and succeeded, even at upwards of 200% font size and Large Fonts on Windows. What was the translation for the developers' apathy to take a couple extra minutes and make their panels fit in the first place? "We don't care enough about our users to spend 3 more minutes, so let's throw in this cheap hack and call it a day"? > I solved the problem for myself by switching to Linux, where my window > manager makes everything resizable whether Mozilla's developers approve or > not. Cool. On Windows, resizability is generally a characteristic of windows only, not dialogs. An exception *may* be when being able to enlarge the window is extremely useful -- but not necessary -- for the user (e.g. the native filepicker), but this isn't even one of those cases.

> Which ones are you referring to, specifically? Find in Files, File Open/Save. These dialog boxes are not resizable because the designers were incompetent. They are resizable because sometimes their fields contain arbitrarily large user data. This is also true for the Mozilla prefs dialog (see, e.g., the Domains fields of the Mail and Newsgroups | Send Format pane). > Months away from Mozilla 1.0, there's really no danger in doing this, now is > there? Everything up until then is a beta version, with quirks far worse than > this. If this is your real argument, then you must file a bug to get this corrected before Mozilla 1.0. But I guess it is just a feint. > But the answer to your question is largely yes. If developers won't abide by > the rules, then maybe they will when they have no other choice. So put in some checks at some stage other than the ultimate user experience. Say, the prefs module owner. Note that developers using Linux and who happen to use certain window manager settings will be entirely untouched by your attempt to enforce "the rules". I'm not going to apologise for the developers. Maybe they really are lazy and inconsiderate. I just don't want users to carry the can. > On Windows, resizability is generally a characteristic of windows only, > not dialogs. I suggest that that is not because of any well-thought-out usability concerns, but because with standard Windows tools (i.e., Win32 DIALOG resources) it is extraordinarily difficult to implement sensibly resizing dialogs. In other widget sets that support resizing dialogs fairly naturally, such as Qt and Motif, most or all dialogs are resizable. I have not seen a rational argument for how resizable dialogs detract from usability (providing a few basic requirements are met: sensible minimum/default sizes, and unobtrusive resize widgetry). > An exception *may* be when being able to enlarge the window is > extremely useful -- but not necessary -- for the user (e.g. the native > filepicker), but this isn't even one of those cases. Whenever I type more text into a text widget than can be displayed in it, it would be very useful to be able to resize the dialog box so I can see all the data. This happens to me pretty often. It happens in the Mozilla prefs pane. Since there's no real cost in usability for making the dialogs resizable, I get a net usability gain by making these dialogs resizable.

As of 20010514 Windows build, the Preferences window is still not resizable!

Right -- it's not resizable -- that's why this bug is fixed (see original report).

"I get a net usability gain by making these dialogs resizable." That may be true, but unfortunately there is cost associated with this. I'm sure the developers of the overflowing panels didn't check in panels that they saw overrunning in their own builds. They'd likely enlarged the dialog from previous usages and were seeing an exaggerated dialog size, and as a result designed their panels to fit that size.

verify fixed