No scrollbars when information not visible

VERIFIED WORKSFORME

Status

SeaMonkey
Preferences
P3
enhancement
VERIFIED WORKSFORME
19 years ago
14 years ago

People

(Reporter: Jeandré, Assigned: matt)

Tracking

({helpwanted})

Trunk
helpwanted

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: relnote-user)

Attachments

(1 attachment)

(Reporter)

Description

19 years ago
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

18 years ago
Confirmed in 2000050208, Linux i686. Poor low-resolution users.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

18 years ago
Target Milestone: --- → M20

Comment 2

18 years ago
Move to M21 target milestone.
Target Milestone: M20 → M21

Comment 3

18 years ago
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.
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.)
Severity: minor → enhancement
Keywords: helpwanted, ui
OS: Windows 98 → All
Hardware: PC → All

Comment 5

18 years ago
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.'
Keywords: relnoteRTM
Whiteboard: relnote-user
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

18 years ago
*** Bug 63424 has been marked as a duplicate of this bug. ***
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

18 years ago
Created attachment 27114 [details]
Truncated buttons in preference window

Comment 10

18 years ago
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.
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].
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME
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 :)
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.