30659 - No scrollbars when information not visible

Status: VERIFIED WORKSFORME

(SeaMonkey :: Preferences, enhancement, P3)

Description

[u12624]

M14 does not have any scrollbars, horizontal or vertical, when the preferences 
window is too small to show all the information on the right panel.

Comment 1

[Eliot Landrum]

Confirmed in 2000050208, Linux i686. Poor low-resolution users.

Comment 2

[don]

Move to M21 target milestone.

Comment 3

[chowes]

Poor low-resolution users?!?

I've got a big screen, and the preferences window looks great, but it turns out
there's more data on the preference window than is shown, and not a single
clue that the data is there.

Comment 4

[sairuh (rarely reading bugmail)]

this would be a useful feature to have.

right now, the user needs to resize the prefs dialog to see all the info in it.
(at least it's resizable on mac, win32 and linux.)

Comment 5

[Matthew T (active 1999-2002)]

Scrollbars for dialog chrome? Noooooooo! We'd get laughed out of town. Making the 
user resize, or scroll, anything in order to see controls is not acceptable. 
Dialogs should only be resizable in extremely rare cases -- and the prefs dialog 
is not one of these cases.

The only respectable way to fix this problem is to ensure that the prefs window 
is large enough to show all the controls in any panel.

Given that UI fonts may, on Windows and Linux at least, be of any size, there are 
two ways to do this. The first is to do a trial layout of every panel when the 
dialog is first opened, in order to calculate the overall minimum size needed. 
Given the number of panels in the prefs dialog currently (and the time each of 
them take to lay out by themselves), that would probably take a very long time 
indeed.

The second possibility is to allow the prefs dialog as a whole to resize itself 
as the user switches panels (like some of Apple's tabbed dialogs do). This would 
be much faster, but would make the interface look rather unstable.

relnoteRTM this: `In some panels of the Preferences dialog, there may be more 
options available than are visible in the dialog. To see all the options, resize 
the dialog.'

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I think that it would be useful to allow the Preferences dialog to be resized, 
but I absolutely agree with mpt that the dialog box should be designed so that 
resizing is NOT required. (And scrollbars attached to dialog boxes are 
definitely WRONG.)

Comment 7

[Keyser Sose]

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

Comment 8

[Joe Drew (not getting mail)]

The behaviour of this bug has changed somewhat; now to get scrollbars in the
preferences dialog, you must expand the tree, close it, and expand it again - at
which time the scrollbars appear. Annoying at best.

Comment 9

[Ruud]

Attachment: Truncated buttons in preference window

Comment 10

[Ruud]

Comments to previously uploaded GIF: I'm using build 2001030715 under Mac OS
9.1. Resizeable window is a nice idea but not implemented like this - buttons
are truncated even when prefs window is very large already (Navigator >
History). They are even off screen when reducing its size!

Also, when I try to change the default search engine (Navigator > Internet
search) by accessing the popupmenu (also truncated BTW), scrolling goes beserk
if you move the mouse above the top of the popupmenu. It keeps on scrolling!
Using standard mouse on stardard Apple extended keyboard.

Comment 11

[sairuh (rarely reading bugmail)]

am thinking of resolving this as wfm or even invalid at this point because: the
prefs dialog is now resizeable for all platforms [not ideal, but...], and there
are already bugs for cases when (1) the content doesn't fit or wrap properly
[eg, bug 70296], and (2) when resizing doesn't work to display the content [eg,
bug 67120].

Comment 12

[sairuh (rarely reading bugmail)]

mass verification of WorksForMe bugs: to find all bugspam pertaining to this,
set your search string to "IfItWorksForSlappyTheSquirrelThenItWFM".

if you think this particular bug is *still* an open issue, please make sure of
the following before reopening:

a. that it's still a problem with ***recent trunk builds*** on the all
appropriate platform[s]

b. provide clear steps to reproduce (unless a good test case is already in the
bug report), making sure it pertains to the original problem (avoid morphing as
much as possible :)