Firefox Options (Preferences) panels are cropped (cut off)

RESOLVED FIXED in Firefox 3 alpha8

Status

()

Firefox
Preferences
RESOLVED FIXED
12 years ago
6 years ago

People

(Reporter: Michael, Assigned: rstrong)

Tracking

(Blocks: 2 bugs)

Trunk
Firefox 3 alpha8
x86
All
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.8b5 -
blocking-aviary1.5 -
blocking-firefox3 +
blocking-firefox2 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(17 attachments, 6 obsolete attachments)

37.87 KB, image/jpeg
Details
116.62 KB, image/png
Details
7.22 KB, image/png
Details
12.36 KB, patch
Details | Diff | Splinter Review
93.05 KB, image/jpeg
Details
13.67 KB, image/gif
Details
44.84 KB, image/jpeg
Details
1.16 KB, patch
Details | Diff | Splinter Review
36.34 KB, image/jpeg
Details
2.38 KB, patch
mconnor
: review-
Details | Diff | Splinter Review
67.69 KB, image/jpeg
Details
2.55 KB, patch
mconnor
: review-
Details | Diff | Splinter Review
351 bytes, text/css
Details
803 bytes, text/css
Details
9.41 KB, image/gif
Details
238.47 KB, image/gif
Details
6.90 KB, patch
rstrong
: review+
Details | Diff | Splinter Review
(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050225 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050225 Firefox/1.0+

The new options panel cannot be resized. This is a problem since under the
default theme and possibly third party themes that are released in the future
some of the options gets cut off because the window is too small. It would also
be good if the browser remembers the size the user leaves it at.


Reproducible: Always

Steps to Reproduce:
1. Hover the mouse near the edge of the options panel


Actual Results:  
Nothing happens.

Expected Results:  
Changed the mouse cursor to the resizing cursor and allow the user to resize the
the options panel.
(Reporter)

Comment 1

12 years ago
Created attachment 175593 [details]
Example of problem

Attached an image as an example where options are getting cut off. Being able
to resize the options panel will solve this.
A quick though. The options doesn't get cut off for me, so I am assuming there
are some system differences (DPI or font setting probably) so it would be
sensible for the options dialog to automatically make itself big enough in the
first place anyway.
(Reporter)

Updated

12 years ago
Version: unspecified → Trunk
Actually, I'm wrong. I can get the options dialog to cut the bottom off if the
fading is enabled. This only seems to occur on XP apparently and is dependant on
which tab was open when you last closed the options dialog.

Close options with the general tab (a small one) and when you next open it, any
tab you view has a big gap at the bottom. Close options with the privacy tab
(the largest) and when you next open the options seems to small, even cutting
off a lot of the tabs.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050226
Firefox/1.0+

->New

this is NOT a problem on win2k(native classic layout), only on XP

Status: UNCONFIRMED → NEW
Ever confirmed: true
Created attachment 175640 [details]
screenshot XP/W2k

Notice the difference between XP/W2k
Attachment #175640 - Attachment description: screenshop XP/W2k → screenshot XP/W2k
This is likely caused by the options dialog being forced to start at a fixed
height regardless of which pane is visible. This is set in the style attribute
on the prefwindow, but only on windows machines.

The problem I guess is that when fadein is enabled the dialog should start sized
to fit the current pane. Otherwise it should start big enough to fit the largest
pane in.

Comment 7

12 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050228
Firefox/1.0+ "Beast" build.

The "Sanitize" button is partly covered at the bottom.

Comment 8

12 years ago
(In reply to comment #7)
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050228
> Firefox/1.0+ "Beast" build.
> 
> The "Sanitize" button is partly covered at the bottom.
I no longer see this in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.8b2) Gecko/20050301 Firefox/1.0+

Comment 9

12 years ago
I see the sanitize button being cut on my college computer. Also the bottom of
the 'y' in 'Keyboard' is also cut off next to the sanitize button. 
set browser.preferences.animateFadeIn False
and the troubles are over

Comment 11

12 years ago
OS should = ALL
Flags: blocking-aviary1.1?

Comment 12

12 years ago
(In reply to comment #9)
> I see the sanitize button being cut on my college computer. Also the bottom of
> the 'y' in 'Keyboard' is also cut off next to the sanitize button.
Same here, unless I install/enable the Javascript Options extension.
Can you tell me about your Windows display settings? I tried this using Luna
Blue and Energy Blue with a number of different font sizes, and could not get
the dialog to clip its contents. The window sizes using ems, so it should always
scale. The one glitch I did notice is that if you had the Options window open
while you changed your settings, it did not adjust its size automatically.
That's likely a bug with the XULWindow code - it should listen for system
settings changes and if the window is sized in ems, resize itself. That's sort
of an edge case though and maybe a little tricky so I'm not sure how quickly
that bug is going to be fixed. 
(Reporter)

Comment 14

12 years ago
I am using the Longhorn Transformation Pack found here:
http://fileforum.betanews.com/detail/Longhorn_Transformation_Pack/1104164392/1

The screenshot I took was under the SlateXP theme with the Mistic colour scheme.
Others weren't able to reproduce using the standard WinXP themes unless they
enabled animateFadeIn preference which has been filed as a seperate bug (bug
284414). I think it could be due to changing from the Windows standard font MS
Sans to the default Longhorn font called Segoe UI.

I don't think anyone picked up what you noticed about changing windows settings
while the options panel is open. But I think it is reasonable for people to
expect to re-open a program or dialogue box before it takes on the new settings.
The one question I have is, what if an extension were to add a button to the
options panel like a few of them currently do. Does the options panel
automatically become bigger to accommodate?
So far as I can tell, currently on the windows platform extensions have to do
something extra to ensure the options dialog is large enough to accomodate them.
Unless the extensions are written cleverly (and the javascript options extension
isn't written cleverly enough), two extensions doing this would likely conflict.
I can confirm that this occurs after installing the longhorn transformation
pack, not sure whether it is the changes to system files that cause this or just
the themes included in it, but without uninstalling the pack and just applying
my old theme makes everything ok again.

Comment 17

12 years ago
I can confirm this bug on Windows XP Pro SP2, no transformation pack. Theme
"advance4/pro by sz1".
Why won't you make that options window resizeable, like it used to be and other
windows (like the cookie manager) are?
It still makes sense to have it in a default size, but making it also resizeable
is IMHO the way to go.
I would prefer to see the options dialog detect what size it needs to be, though
I know that that is going to be tough with how its written.

Perhaps a workaround is to display it at a default size. When a pane is
selected, if the options dialog is too small then expand it as necessary. The
average user would not see this resize ever, only those of us using odd themes
and extensions would see it every now and then.

Comment 19

12 years ago
(In reply to comment #10)
> set browser.preferences.animateFadeIn False
> and the troubles are over

Just checked, and mine IS set to false. Still cut off as of 03/04 build.

Comment 20

12 years ago
Created attachment 176720 [details]
connection settings screenshot

this is a screenshot of the he-IL locale of the trunk on WinXP.  if it's
impossible to make the window resize according to the contents, so there's
suppose to be some pref in the locale that enables to change the window size.
i'm not sure if i should open a new bug for this.

Comment 21

12 years ago
Created attachment 176721 [details]
connection settings screenshot

sorry for the last one. this one is with the access keys removed.
Attachment #176720 - Attachment is obsolete: true

Updated

12 years ago
Blocks: 274712
Reuven: Please open a separate bug for the intl issue, this bug is about making
pref-dialogs resizeable (on run time), not about the ability to set the initial
size per locale. Thanks.

Comment 23

12 years ago
(In reply to comment #22)
> Reuven: Please open a separate bug for the intl issue, this bug is about making
> pref-dialogs resizeable (on run time), not about the ability to set the initial
> size per locale. Thanks.
> 

actually i think that making the windows resizable according to the content is a
better idea, since other "non-resizable" windows (like fonts or colors) can
break in other locales. adding a pref may be a workaround, but it seems a bit
awkward since we will need to add a pref for every "non-resizable" window.
(In reply to comment #23)
> (In reply to comment #22)
> > Reuven: Please open a separate bug for the intl issue, this bug is about making
> > pref-dialogs resizeable (on run time), not about the ability to set the initial
> > size per locale. Thanks.
> > 
> 
> actually i think that making the windows resizable according to the content is a
> better idea, since other "non-resizable" windows (like fonts or colors) can
> break in other locales. adding a pref may be a workaround, but it seems a bit
> awkward since we will need to add a pref for every "non-resizable" window.

as i said, this is *not* what this bug about. This one is about adding a window
resizer to pref windows, nothing else (i.e. the intial size would still be worng
for say, he-IL)
Flags: blocking-aviary1.1? → blocking-aviary1.1-

Comment 25

12 years ago
Created attachment 177240 [details] [diff] [review]
fix for "Sanitize" button is partly covered at the bottom

just add flex="1" to the separator befor the button in privacy panel

Comment 26

12 years ago
*** Bug 285995 has been marked as a duplicate of this bug. ***

Comment 27

12 years ago
Created attachment 178438 [details]
I cant see ports for my proxies

Comment 28

12 years ago
*** Bug 288312 has been marked as a duplicate of this bug. ***

Comment 29

12 years ago
fix now please

Comment 30

12 years ago
(In reply to comment #29)
> fix now please

Please read http://bugzilla.mozilla.org/page.cgi?id=etiquette.html before you
make any further comments.

Comment 31

12 years ago
I finally figured on how to fix it. 

I just figured to edit connection.xul file in browser.jar

Thank you for replies  

C:\xxxxx\Mozilla Firefox\chrome\browser\content\browser\preferences

then find this 

            style="width: 23em !important;">

replace with this 

            style="width: 63em !important;">


Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050417
Firefox/1.0+

->WFM

This was resolved by Bug 289217
(Reporter)

Comment 33

12 years ago
http://forums.mozillazine.org/viewtopic.php?t=251950&start=22

I no longer experience chopped off panels under my setup. From linked thread it
appears this has now been solved for other people but not in all cases. Could
someone provide details of a test case where it doesn't?

Since this bug is filed to re-introduce resizing of the option panel, if the
panels are no longer chopped off in all cases and resizing is not going to be
re-introduced then this bug should probably be marked wontfix.
Summary: Options panel cannot be resized. → Options panel cannot be resized. Chopped off panels.

Comment 34

12 years ago
Is anyone still seing this bug?

Comment 35

12 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050422
Firefox/1.0+

WFM

Comment 36

12 years ago
I can still see this bug, but it's only there if you change the default font in
windows xp. So, in your display properties, if the font for the text in a dialog
is set to tahoma (this is the default setting), everything is OK, if you change
it to something else, e.g. Microsoft Refence Sans Serif in my case, the panels
get cut off again.

Summary: Options panel cannot be resized. Chopped off panels. → Options panels are cropped

Comment 37

12 years ago
NOT BLOCKING 1.1???

Comment 38

12 years ago
I really don't understand why you don't want to make the "internal dialogs" like
the new options and the about dialog resizeable. Of course it is preferable to
have it all visible from the beginning, but something will always break it and
will leave people unable to set everything from the options panel. 
Or is there an additional bug in the tracker about the resize problem?

Comment 39

12 years ago
*** Bug 294866 has been marked as a duplicate of this bug. ***

Comment 40

12 years ago
Created attachment 184483 [details]
Windows XP: Deer Park Alpha 1 - Sanitize Button under privacy
On Linux, it also happens (Deer Park Alpha 1) if animatefadein is false. If it
is true, the window is resized at every section change.

_FrnchFrgg_

Comment 42

12 years ago
Created attachment 184666 [details]
funny "Options panel" with some themes 

Themes such as Modern Pinball, Brushed, Pheonity generate no panel but Title
and OK/Cancel Button.
(Reporter)

Comment 43

12 years ago
That's because the new options panel is completely different, in fact is in a
differently named chrome file. That's what it looks like if you install themes
designed for the old options panel. See this thread for list of themes
compatible with the new panel.

http://forums.mozillazine.org/viewtopic.php?t=240370

Updated

12 years ago
Blocks: 279760

Updated

12 years ago
Blocks: 284713
I don't see this problem anymore.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050610
Firefox/1.0+ ID:2005061022

Comment 45

12 years ago
Yeah, WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2)
Gecko/20050619 Firefox/1.0+

Comment 46

12 years ago
(In reply to comment #44)
> I don't see this problem anymore.
> 
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050610
> Firefox/1.0+ ID:2005061022

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050620
Firefox/1.0+ ID:2005062003

AFAIK, this only affects people using non-default themes on Windows XP.

And since many people do, I believe this issue should be addressed!

Comment 47

12 years ago
It is also effecting thunderbird too.  

Comment 48

12 years ago
Remember, the themes could be normal, but the fonts can be enlarged to a point
to cut off things.  This is an accessibility problem.
Happens on Linux -> OS: All.
OS: Windows XP → All

Comment 50

12 years ago
*** Bug 300017 has been marked as a duplicate of this bug. ***

Comment 51

12 years ago
*** Bug 285223 has been marked as a duplicate of this bug. ***

Comment 52

12 years ago
(In reply to comment #36)
> I can still see this bug, but it's only there if you change the default font in
> windows xp. So, in your display properties, if the font for the text in a dialog
> is set to tahoma (this is the default setting), everything is OK, if you change
> it to something else, e.g. Microsoft Refence Sans Serif in my case, the panels
> get cut off again.
> 
> 


Yep I can confirm this with the FlyakieOSX theme. Chopped off sanitize when
using no default font.This really should be blocking 1.5 imo.
Submitted patch for a resizable Options dialog. 

Should keep people happy until a more complete solution supporting themes and
locales can be put together.

BTW:This bug is *not* just limited to "NT" based versions of Windows.

Comment 54

12 years ago
where did you submitted patch? 

Thank you :D 
Mouse

(In reply to comment #53)
> Submitted patch for a resizable Options dialog. 
> 
> Should keep people happy until a more complete solution supporting themes and
> locales can be put together.
> 
> BTW:This bug is *not* just limited to "NT" based versions of Windows.
Created attachment 191147 [details] [diff] [review]
Patch for resizable Options dialog
Attachment #191147 - Flags: review?
Attachment #191147 - Flags: approval1.8b4?
(In reply to comment #42)
> Created an attachment (id=184666) [edit]
> funny "Options panel" with some themes 
> 
> Themes such as Modern Pinball, Brushed, Pheonity generate no panel but Title
> and OK/Cancel Button.

Brushed WFM as it's the theme I used to test my patch (see my previous post)
Comment on attachment 191147 [details] [diff] [review]
Patch for resizable Options dialog

You need to ask review from a specific person, and you would ideally attach a
"diff" created using cvs diff -up8. Also, don't ask for approval until review
is given.
Attachment #191147 - Flags: review?
Attachment #191147 - Flags: approval1.8b4?

Comment 58

12 years ago
Comment on attachment 191147 [details] [diff] [review]
Patch for resizable Options dialog

This patch really isn't a patch. You need to download the file from CVS, then
make your changes, then diff it (cvs diff -pU8 works well), then submit it as a
patch.

Updated

12 years ago
Attachment #191147 - Attachment is obsolete: true
Steve, is this the change you made:

 function openPreferences(paneID)
 {
   var instantApply = getBoolPref("browser.preferences.instantApply", false);
-  var features = "chrome,titlebar,toolbar,centerscreen" + (instantApply ?
",dialog=no" : ",modal");
+  var features = "chrome,titlebar,toolbar,centerscreen,resizable=yes" +
(instantApply ? ",dialog=no" : ",modal");

Comment 60

12 years ago
yeah I only used this change and it worked.  



(In reply to comment #59)
> Steve, is this the change you made:
> 
>  function openPreferences(paneID)
>  {
>    var instantApply = getBoolPref("browser.preferences.instantApply", false);
> -  var features = "chrome,titlebar,toolbar,centerscreen" + (instantApply ?
> ",dialog=no" : ",modal");
> +  var features = "chrome,titlebar,toolbar,centerscreen,resizable=yes" +
> (instantApply ? ",dialog=no" : ",modal");
> 

Created attachment 191154 [details] [diff] [review]
Steve's Patch against trunk

This makes the options dialogue resizable, note that the size is not persisted
so I don't think this is an aceptable solution.
(In reply to comment #57)
> (From update of attachment 191147 [details] [diff] [review] [edit])
> You need to ask review from a specific person, and you would ideally attach a
> "diff" created using cvs diff -up8. Also, don't ask for approval until review
> is given.
> 

Sorry not up with all the flags yet! Tried to get a person selected for the
review flag but it wouldn't let me so I left it blank...
On the second point would GNU DiffUtils be any good? I can use whatever best
suits the submission process. Thanks
(In reply to comment #59)
> Steve, is this the change you made:
> 
>  function openPreferences(paneID)
>  {
>    var instantApply = getBoolPref("browser.preferences.instantApply", false);
> -  var features = "chrome,titlebar,toolbar,centerscreen" + (instantApply ?
> ",dialog=no" : ",modal");
> +  var features = "chrome,titlebar,toolbar,centerscreen,resizable=yes" +
> (instantApply ? ",dialog=no" : ",modal");
> 

Yes it is, sorry should've diff'd it (not used to Bugzilla yet)
(In reply to comment #61)
> Created an attachment (id=191154) [edit]
> Steve's Patch against trunk
> 
> This makes the options dialogue resizable, note that the size is not persisted
> so I don't think this is an aceptable solution.

Notice how I used the words "until a more complete solution... can be put
together". 
This was *never* intended as "an acceptable solution" more as a "stop-gap" for
the time being.
I think I've worked out how this can be persisted and will submit again shortly
if it works :)

Comment 65

12 years ago
Nice one, works good enough for me atm. :)

(In reply to comment #64)
> (In reply to comment #61)
> > Created an attachment (id=191154) [edit] [edit]
> > Steve's Patch against trunk
> > 
> > This makes the options dialogue resizable, note that the size is not 
persisted
> > so I don't think this is an aceptable solution.
> Notice how I used the words "until a more complete solution... can be put
> together". 
> This was *never* intended as "an acceptable solution" more as a "stop-gap" 
for
> the time being.
> I think I've worked out how this can be persisted and will submit again 
shortly
> if it works :)

OK, on the size persistence issue I've got to the following place:
This are the changes I've made to browser\content\preferences.xul

<prefwindow type="prefwindow"
            id="BrowserPreferences"
            windowtype="Browser:Preferences"
            title="&prefWindow.titleWin;"
            xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
            style="&prefWindow.styleWin;"
       -    >
       +    persist="screenX screenY width height"> 

It will persist the screen position but *NOT* the width and height. I don't
understand why this part doesn't work. I know it works for other extensions...
Persistence bug on prefwindow perhaps? 
Because height and width are being set as a style element and not attributes.

This is the wrong approach anyway, there's some issues with
borders/padding/margins specified in pixels that exacerbate this issue, which
hopefully will be addressed.

The main Linux issue is that we don't specify a height for GNOME, but we should,
that's the real problem that needs to be fixed, then some theme stuff needs to
be fixed to use em instead of pixels and we're golden.

Comment 68

12 years ago
Created attachment 191167 [details]
The way it should be?

IMHO, this is the way all panels should be.  Instead of resizing panels, they
should have scrollbars, etc.  This is what happens in Windows installers when
they're too big for my screen: scrollbars on both the side and bottom.
Mike, the padding and margin issues also apply to all possible form elements...
true? It doesn't seem like that would be easy to solve without breaking themes
other than default since the window height is specified in em in the locale and
each theme can specify different form margins and paddings for these controls.
So, even fixing the margin and padding issues would still break themes other
than the default theme? It might be possible to force the pref panel content to
use the same values in em no matter what theme is used but that seems like a bad
solution as well since the controls would not be consistent with the rest of the ui.
Sure, other themes that specify things in pixels would be broken.  They're
broken now anyway.  Note that I'm referring to fixing Winstripe to not use pixel
offsets, so height's specified in em aren't horrifically inaccurate as you scale
font sizes up/down.

Scrollbars are a non-starter, and I'm not about to rehash this again and again,
its a no, move on.
What I'm referring to are themes that specify things in em that are different
than the em units specified in winstripe. Unless all themes speecified the same
em units for the same elements used in the pref panels then the height that is
specified in the locale (also in em) may be off.

Comment 72

12 years ago
Mike, Robert, see my comment/patch in bug 284713 comment 11. Since this is now 
OS: All, I don't know if we should dupe bug 284713 against this or what.

I also filed bug 302244 to further investigate the em sizing issue in the 
prefs. dialog.

Comment 73

12 years ago
*** Bug 304225 has been marked as a duplicate of this bug. ***
If the padding, margin, etc. units are changed to em for the default themes then
the window height can be calculated for each locale. This won't work for other
themes unless they also specify the same em values for the same elements. Simple
scenario:

winstripe
+-----------+ .25em padding-top
|  Button |
+-----------+ .25em padding-bottom

any other theme with different values
+-----------+ .15em padding-top
|  Button |
+-----------+ .15em padding-bottom

Since the panel contents are loaded dynamically the simplest way to support
themes other than the default is to sizeToContent when the panel loads and this
would only apply when browser.preferences.animateFadeIn is false. At worse this
will cause the window size to increase when the initial window size is smaller
than it needs to be when switching to another panel but this is a whole lot
better than the current situation where there are elements that are not
accessible. It may be possible to have the locale and the theme be able to
provide their individual requirements for height that could then be applied to
the window when it is first loaded but that would probably cause more problems
than its worth.

Comment 75

12 years ago
*** Bug 304682 has been marked as a duplicate of this bug. ***

Comment 76

12 years ago
*** Bug 307097 has been marked as a duplicate of this bug. ***

Comment 77

12 years ago
I see this on Mac OS X aswell.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050904
Firefox/1.0+

Updated

12 years ago
Flags: blocking1.8b5?

Comment 78

12 years ago
*** Bug 307649 has been marked as a duplicate of this bug. ***
*** Bug 307690 has been marked as a duplicate of this bug. ***

Comment 80

12 years ago
*** Bug 307947 has been marked as a duplicate of this bug. ***

Comment 81

12 years ago
Ben already minused this for 1.5. No patch reviewed by Ben nor checked into the
trunk. Too late in the game for this to be listed as a stop ship bug.
Flags: blocking1.8b5? → blocking1.8b5-
As long as the panel is not resizable, it's crazy to not fix this bug for 1.5!
The options dialog is hardly usable in this way!

Updated

12 years ago
Flags: blocking-aviary2.0?

Comment 83

12 years ago
Other Themes like Aquatint 1.3 don't have this problem. I think because of
giving some more space for the whole menu (it's bigger there...). So just give
as much space to support all common operating systems with default settings and
enough space for translations as a quick most-satisfying fix (there might be
more problems than now with "larger-word" languages like german).
sizes are all localizable, so German etc isn't a concern.  This should be fixed
in the 97% case for GNOME, and since most of the comments seem to refer to
hidden prefs being flipped (in a quick skim) this should in theory be fine.  We
need a better solution for sizing dialogs with complex content for 2.0, but
that's not going to happen in 1.5.

Comment 85

12 years ago
You can't be serious. This bug has been reported half a year ago and suddenly it
is too late to be a show stopper?
You can't access parts of the options and you don't want to make the dialog
resizeable (as most people would expect a dialog to be that doesn't show all)
and you don't want to fix it.
Shows the attitude again.
This seems to be fine on XP with built-in themes, StyleXP on the other hand has
had varying issues depending on themes, due to weirdness with specified fonts.

Comment 87

12 years ago
Yup, I *think* with built-in Themes it looks ok. Even more so with the built-in
browser, which doesn't show no size problem at all in all Themes.
Oh we can mess the Winstripe theme, make the menu's M$ look alike, flat, and
just plain ugly, but we can't resize the Pref's box that has been broken since
it was introduced...

come on already...No more than Beta 1.5 has been out there already have been
complaints in the support forums about the box being cut-off.  Not everyone uses
the default 'font' and anything larger just makes it worse, themes or not. 

This makes no sense not to fix this.  If you can't or don't want to make it
'dynamic' then at least make it larger by a few pixels...

Oh wait, you could borrow some from the bookmarks padding if you need a few.
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Comment 90

12 years ago
(In reply to comment #61)
> Created an attachment (id=191154) [edit]
> Steve's Patch against trunk
> This makes the options dialogue resizable, note that the size is not persisted
> so I don't think this is an aceptable solution.

the final solution needs to include persistent size, or the size problem will 
continue to be a major annoyance.

the options panel just needs to be big enough to fit all the tabs, because the 
location of the content in the tab is dependent on that.

Something I posted on MozillaZine forums:

the options panel fix should include something about remembering the size after 
closing the panel so you won't have to resize it again a second time. 

i'm using the resize fix combined with a userChrome.css mod that makes the 
width just large enough to fit all the tabs and, in turn, all the content. 

It looks like the tabs and the alignment off the content is causing the 
cropping of the content in the options panel. What I mean, is some of the 
content is set to align to the right of the panel flush with the last tab, so 
when the panel is two narrow to fit all the tabs, the content is also cut off.

Comment 91

12 years ago
Please post your userChrome.css mod here.  

(In reply to comment #90)
> (In reply to comment #61)
> > Created an attachment (id=191154) [edit] [edit]
> > Steve's Patch against trunk
> > This makes the options dialogue resizable, note that the size is not persisted
> > so I don't think this is an aceptable solution.
> 
> the final solution needs to include persistent size, or the size problem will 
> continue to be a major annoyance.
> 
> the options panel just needs to be big enough to fit all the tabs, because the 
> location of the content in the tab is dependent on that.
> 
> Something I posted on MozillaZine forums:
> 
> the options panel fix should include something about remembering the size after 
> closing the panel so you won't have to resize it again a second time. 
> 
> i'm using the resize fix combined with a userChrome.css mod that makes the 
> width just large enough to fit all the tabs and, in turn, all the content. 
> 
> It looks like the tabs and the alignment off the content is causing the 
> cropping of the content in the options panel. What I mean, is some of the 
> content is set to align to the right of the panel flush with the last tab, so 
> when the panel is two narrow to fit all the tabs, the content is also cut off.

Comment 92

12 years ago
my userChrome.css mod:

/* options panel bug fix */

#BrowserPreferences {\
  /* set this to a number large enough so all the tabs can be displayed */
  width: 51em !important;
  /* set this if content gets cut off on the bottom */
  height: 40em !important;
}

(In reply to comment #91)
> Please post your userChrome.css mod here.  
> 
> (In reply to comment #90)
> > (In reply to comment #61)
> > > Created an attachment (id=191154) [edit] [edit] [edit]
> > > Steve's Patch against trunk
> > > This makes the options dialogue resizable, note that the size is not persisted
> > > so I don't think this is an aceptable solution.
> > 
> > the final solution needs to include persistent size, or the size problem will 
> > continue to be a major annoyance.
> > 
> > the options panel just needs to be big enough to fit all the tabs, because the 
> > location of the content in the tab is dependent on that.
> > 
> > Something I posted on MozillaZine forums:
> > 
> > the options panel fix should include something about remembering the size after 
> > closing the panel so you won't have to resize it again a second time. 
> > 
> > i'm using the resize fix combined with a userChrome.css mod that makes the 
> > width just large enough to fit all the tabs and, in turn, all the content. 
> > 
> > It looks like the tabs and the alignment off the content is causing the 
> > cropping of the content in the options panel. What I mean, is some of the 
> > content is set to align to the right of the panel flush with the last tab, so 
> > when the panel is two narrow to fit all the tabs, the content is also cut off.
> 
> 

Comment 93

12 years ago
sorry, i made a typo:

my userChrome.css mod:

/* options panel bug fix */

#BrowserPreferences {
  /* set this to a number large enough so all the tabs can be displayed */
  width: 51em !important;
  /* set this if content gets cut off on the bottom */
  height: 40em !important;
}

Comment 94

12 years ago
Created attachment 196411 [details] [diff] [review]
patch against TRUNK with persistent height and width
Attachment #196411 - Flags: review?(mconnor)
Comment on attachment 196411 [details] [diff] [review]
patch against TRUNK with persistent height and width

We don't want a resizable prefwindow, period.  That should be fairly clear by
now.  If the widget works right, its unnecessary.
Attachment #196411 - Flags: review?(mconnor) → review-

Comment 96

12 years ago
This widget does NOT work right, as it is an accessibility limitation.  Can't
the pref window check itself against the system, and resize automatically?  (I
DO agree that having a resixable prefs window is weird)  Or can't we at least
have scrollbars inside the window (I know it has been discussed before)?  When I
use big fonts on my system, Windows Installers take up the whole screen on
800x600, so what happens?  They use scrollbars so people can ACCESS the content!
 Why the hell can't we?  It doesn't matter if it looks pretty or not, the main
reason for this is so people can actually get to the content.

Comment 97

12 years ago
(In reply to comment #95)
> (From update of attachment 196411 [details] [diff] [review] [edit])
> We don't want a resizable prefwindow, period.  That should be fairly clear by
> now.  If the widget works right, its unnecessary.
> 

This argument has a hole the size of Texas in it, unfortunately.  It's always
ideal to avoid workarounds or hacks to "fix" a problem that shouldn't exist, but
no one is fixing the problem for 1.5.  I shouldn't have to go to about:config to
tweak a third of the firefox preferences because the Gods of spacing made my
prefs window too small.  How can such a usability problem be so low-priority
that it can be ignored until someone gets around to fixing the underlying
problem?  Why doesn't this block aviary 1.5?

I still think, as I have for a good while now, that if the options panel isn't
going to be fixed the right way, we need a workaround, especially if you're
planning to call Firefox 1.5 a production release.  This is a well-known,
long-known, very common issue and I can completely understand why a lot of
people are very confused about the fact that the development team intends to
ignore the problem completely.

Do /something/, please.  I can live with it, and I have for many moons, but the
average user is going to be very frustrated that they can't change their
preferences because they can't see them, just because they happen to have
configured their Windows fonts unusually.
*** Bug 309023 has been marked as a duplicate of this bug. ***

Comment 99

12 years ago
(In reply to comment #95)
> (From update of attachment 196411 [details] [diff] [review] [edit])
> We don't want a resizable prefwindow, period.  That should be fairly clear by
> now.  If the widget works right, its unnecessary.

Quoting Kevin Stange: "This argument has a hole the size of Texas in it, 
unfortunately."
It does. There are many possible configurations and themes that would cause a 
widget that should work correctly to display awkwardly like the pref window.
The pref window definitely needs to resizeable.
And I strongly recommend that this bug be fixed and the fix be implemented 
before 1.8b5 and 1.9a1.
Usability and accessibility are key. Why make it hard for users to change the 
most basic options of Firefox? That is entirely, going against the priorities 
of the Firefox project and what has made Firefox so great.
Speaking of arguments, lets try this one: the average user who is going to be
confused by this isn't going to tweak their Windows theme to something really
oddball.  I haven't been able to reproduce this using standard themes/fonts, if
someone wants to make a valid point, let's get a sample configuration that the
prefwindow breaks.

The prefwindow being resizable, without a resize widget, can lead to some pretty
evil things that the typical user everyone's so worried about will not be able
to readily undo.  Its not as black and white as everyone is assuming it is.
(In reply to comment #100)
> let's get a sample configuration that the
> prefwindow breaks.

here you are an example: http://s01.imagehost.org/0414/broken.png italian
firefox with mostly crystal (a large-used theme) theme installed. As you can see
the button in the bottom-right is broken, and I can't see all the text.

Comment 102

12 years ago
i have screenshots that REALLY show the problem but i haven't uploaded them yet.

will do when i have time.

(In reply to comment #100)
> Speaking of arguments, lets try this one: the average user who is going to be
> confused by this isn't going to tweak their Windows theme to something really
> oddball.  I haven't been able to reproduce this using standard themes/fonts, if
> someone wants to make a valid point, let's get a sample configuration that the
> prefwindow breaks.
> 
> The prefwindow being resizable, without a resize widget, can lead to some pretty
> evil things that the typical user everyone's so worried about will not be able
> to readily undo.  Its not as black and white as everyone is assuming it is.

Comment 103

12 years ago
Created attachment 196696 [details]
1.5b1 and 1.6a1 Screenshot with WinXP and Aquatint

The options panel looks the same in 1.5b1 and 1.6a1 so I only uploaded one
image.

I did not configure my settings in any way that would change the optoins panel
appearance except for the Aquatint theme.
comment 101 isn't even the prefwindow, its the customize toolbar window. 
Comment 103 is a theme issue, if Aquatint wants to use heavily padded tabs, they
should override the style rule for the window size to compensate.

To clarify what I assumed was crystal clear: At issue is whether, say, Windows
XP can be configured in a reasonable configuration such that the default theme
exhibits this behaviour.
(In reply to comment #104)
> comment 101 isn't even the prefwindow, its the customize toolbar window.

you're right: I opened a different bug, but someone colesd it as a duplicate of
this bug, so I posted it here.
(In reply to comment #104)
> comment 101 isn't even the prefwindow, its the customize toolbar window.

you're right: I opened a different bug, but someone cloesd it as a duplicate of
this bug, so I posted it here.

Comment 107

12 years ago
(In reply to comment #104)
> comment 101 isn't even the prefwindow, its the customize toolbar window. 
> Comment 103 is a theme issue, if Aquatint wants to use heavily padded tabs, they
> should override the style rule for the window size to compensate.
> 
> To clarify what I assumed was crystal clear: At issue is whether, say, Windows
> XP can be configured in a reasonable configuration such that the default theme
> exhibits this behaviour.

Can easily be configured, define reasonable;)

Steps to reproduce on XP with default Firefox theme...

1)Change system message-box text font to 8px Lucida Console, Trebuchet, Georgia
(to name a few)via Windows Display Properties>Appearance>Advanced>Message
Text>Font. Apply setting.
2.Open Options>Privacy. Buttons are clipped.
3.Set as in step 1 to 8px Tahoma. Options are not clipped.

Comment 108

12 years ago
(In reply to comment #107)
> (In reply to comment #104)
> > comment 101 isn't even the prefwindow, its the customize toolbar window. 
> > Comment 103 is a theme issue, if Aquatint wants to use heavily padded tabs, they
> > should override the style rule for the window size to compensate.
> > 
> > To clarify what I assumed was crystal clear: At issue is whether, say, Windows
> > XP can be configured in a reasonable configuration such that the default theme
> > exhibits this behaviour.
> 
> Can easily be configured, define reasonable;)
> 
> Steps to reproduce on XP with default Firefox theme...
> 
> 1)Change system message-box text font to 8px Lucida Console, Trebuchet, Georgia
> (to name a few)via Windows Display Properties>Appearance>Advanced>Message
> Text>Font. Apply setting.
> 2.Open Options>Privacy. Buttons are clipped.
> 3.Set as in step 1 to 8px Tahoma. Options are not clipped.
> 
> 

Sorry, to be clear, by "Advanced>Message Text>Font" I mean click on "Message
Text" in the Picture so that the drop-down reads "Item: Message Box" (clear as
XP gets) and then adjust "Font:" properties.

Updated

12 years ago
Flags: blocking1.8b5- → blocking1.8b5?

Comment 109

12 years ago
sorry i think i messed up the flags.

but i still think this should be fixed or at least some patch should checked-in
to the trunk and branch builds,, because their are numerous configurations and
themes that may cause the options panel to skewed.

an alternate solution instead of making it resizeable would be to have the
options panel expand to the necessary size to fit all the content because right
now, the buttons on the right get cut off because they are set to "float: right"
or something like that, which causes them to be cut off when they really should
be easily visible.

Comment 110

12 years ago
not a blocker.
Flags: blocking1.8b5? → blocking1.8b5-

Comment 111

12 years ago
(In reply to comment #110)
> not a blocker.
Just curious if anyone can confirm my steps to reproduce? I know that there's
pressure to get 1.5 out, but there are several very noticeable UI bugs still in
existance (XP menu shadows, print preview SNAFU, search-engine tooltip, this
bug, off the top of my head, and others, I'm sure). Can't the userChrome fix
(#BrowserPreferences {
  width: 43em !important;
  height: 43em !important;
} adjust numbers if needed) be incorporated into classic.jar? I don't mean to
spam, but these bugs are all very noticeable to novices, I'd hate to see Fx 1.5
chopped down by a hostile reviewer. If any one UI bug is fixed, it can only
help, especially if you are catering to XP users. I know that commenting @ #110
looks bad, but I'll take that chance... No further comments from me for 2 weeks,
I promise.
(In reply to comment #110)
> not a blocker. hhh

Comment 112

12 years ago
(In reply to comment #13)
> Can you tell me about your Windows display settings? I tried this using Luna
> Blue and Energy Blue with a number of different font sizes, and could not get
> the dialog to clip its contents. The window sizes using ems, so it should always
> scale. The one glitch I did notice is that if you had the Options window open
> while you changed your settings, it did not adjust its size automatically.
> That's likely a bug with the XULWindow code - it should listen for system
> settings changes and if the window is sized in ems, resize itself. That's sort
> of an edge case though and maybe a little tricky so I'm not sure how quickly
> that bug is going to be fixed. 

Can't we just make it like Ben proposed it should be: window is resized
automatically, instead of it being resized manually?  Also, see this video for a
demo of it (sorta old):
http://www.bengoodger.com/software/mb/options/prefwindowv/PrefwindowV2.wmv.

Comment 113

12 years ago
(In reply to comment #112)
> Can't we just make it like Ben proposed it should be: window is resized
> automatically, instead of it being resized manually?  Also, see this video 
for a
> demo of it (sorta old):
> http://www.bengoodger.com/software/mb/options/prefwindowv/PrefwindowV2.wmv.

you can make it resize automatically - just set:

browser.preferences.animateFadeIn - to "true" in about:config.

but that only works for resizing vertically, not horizontally, which can be 
another problem.

Created attachment 198523 [details] [diff] [review]
patch1: sizetocontent onload

this fixes it for me on gtk2.
Attachment #198523 - Flags: review?(mconnor)
The patch doesnt seem to have any effect for me, the privacy pane is still cut off.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051004
Firefox/1.6a1 ID:2005100413
With further experimentation, removing the fixed height style on the pref window
makes the resizing actually do something. But it seems to do what I expected and
only takes the first pane into account. Since the other panes aren't actually
overlayed onto the window until they are switched to, they aren't taken into
account in sizeToContent.

The only way round that I guess would be to load them all at start rather than
on pane switch. That would probably also fix bug 283949 but presumably there are
some performance implications which is why this is this way in the first place?
Comment on attachment 198523 [details] [diff] [review]
patch1: sizetocontent onload

> only takes the first pane into account. Since the other panes aren't actually
> overlayed onto the window until they are switched to, they aren't taken into
> account in sizeToContent.

sure it's not just because of that pane content growing just a bit when the
pref values get filled in as you switch to that pane? I get the same height
window regardless of which pane gets initially	displayed, on linux. (granted,
I don't know overlay-dynamic-fu.)
Attachment #198523 - Attachment is obsolete: true
Attachment #198523 - Flags: review?(mconnor)
When opening with the content pane first, the height is 390px. With the Privacy
pane it is 450px.

Incidentally, I notice that linux builds have a fixed height set as well and
this patch does not remove that, I found on windows that sizeToContent did
nothing when there was a fixed height applied.

Comment 119

12 years ago
I too am seeing only part of some tabs in the Options dialog.  v1.5 beta 2 under
Windows 2000 SP4, 1280*1024 screen resolution, using the default theme.  It
seems to me that the simplest and most elegant solution would be to make this
dialog resizable.
Created attachment 199029 [details] [diff] [review]
patch2: s/height/min-height/ + sizetocontent on pane change

The cropping is easily enough reproducible (thanks, comment 107) with default
themes both on windows and linux without extra pref content or pref panes by
reducing the font size used in the dialog so that the font-size relative ems
that the window size is specified in don't cover whatever non-font-relative
paddings exist in the pref pane.

This patch does sizeToContent whenever the pref pane is changed, growing the
height as necessary. It never shrinks, presumably because the previously seen
panes are bracing it.

The fixed height set on the prefwindow is changed to a min-height, so that with
such settings where the cropping never was a problem, the prefwindow behaves
exactly as before.

sizeToContent is useless for fixing horizontal cropping though, as it uses the
unwrapped width for paragraphs. It might be a good idea to be a bit more
generous with the width styles; however, as width cropping of a few dozen px is
unlikely to make pref content inaccessible, I'm not bothering with tweaking
those here.

Tested on winxp and linux.
Assignee: bugs → tuukka.tolvanen
Status: NEW → ASSIGNED
Attachment #199029 - Flags: superreview?(mscott)
Attachment #199029 - Flags: review?(mconnor)

Comment 121

12 years ago
(In reply to comment #120)
> Created an attachment (id=199029) [edit]
> patch2: s/height/min-height/ + sizetocontent on pane change
> 
> The cropping is easily enough reproducible (thanks, comment 107) with default
> themes both on windows and linux without extra pref content or pref panes by
> reducing the font size used in the dialog so that the font-size relative ems
> that the window size is specified in don't cover whatever non-font-relative
> paddings exist in the pref pane.
> 
> This patch does sizeToContent whenever the pref pane is changed, growing the
> height as necessary. It never shrinks, presumably because the previously seen
> panes are bracing it.
> 
> The fixed height set on the prefwindow is changed to a min-height, so that with
> such settings where the cropping never was a problem, the prefwindow behaves
> exactly as before.
> 
> sizeToContent is useless for fixing horizontal cropping though, as it uses the
> unwrapped width for paragraphs. It might be a good idea to be a bit more
> generous with the width styles; however, as width cropping of a few dozen px is
> unlikely to make pref content inaccessible, I'm not bothering with tweaking
> those here.
> 
> Tested on winxp and linux.

Thanks for confirming.

Comment 122

12 years ago
Comment on attachment 199029 [details] [diff] [review]
patch2: s/height/min-height/ + sizetocontent on pane change

my gut tells me we really don't want to be calling sizeToContent every time we
load a new pref panel.

Ben wrote this so I'll let him decide.
Attachment #199029 - Flags: superreview?(mscott) → superreview?(bugs)
(In reply to comment #122)
> Ben wrote this so I'll let him decide.

The 1.5 train has almost left the platform - will a decision be taken on this highly visible issue anytime soon?

Comment 124

12 years ago
*** Bug 314937 has been marked as a duplicate of this bug. ***

Comment 125

12 years ago
Created attachment 202460 [details]
userchrome.css fix for options panel being cut off

Comment 126

12 years ago
Created attachment 202478 [details]
improved userChrome.css fix

(there are some more options panel dialogs being cut off)

Updated

12 years ago
Attachment #202460 - Attachment is obsolete: true
*** Bug 316505 has been marked as a duplicate of this bug. ***
Comment on attachment 199029 [details] [diff] [review]
patch2: s/height/min-height/ + sizetocontent on pane change

I'm almost certain that repeated sizeToContent calls result in constantly shrinking windows (see the hack in the bookmarks dialog that shows this)

Comment 129

12 years ago
*** Bug 318252 has been marked as a duplicate of this bug. ***

Comment 130

12 years ago
Hey, here's my problem.

The theme I use is from http://521.2ya.com, it's the Advance 4[xp]/pro2 theme, on the default scheme.

Here is a screenshot of what happens to my options window. http://i.hyynes.net/nick,look.jpg
*** Bug 322540 has been marked as a duplicate of this bug. ***
*** Bug 323176 has been marked as a duplicate of this bug. ***

Comment 133

12 years ago
Created attachment 209531 [details]
userChrome.css fix for all rigid dialogue boxes
in Options...

userChrome.css fix for all rigid dialogue boxes in Options.., including the Language dialog

Comment 134

12 years ago
Comment on attachment 209531 [details]
userChrome.css fix for all rigid dialogue boxes
in Options...

This fix is pretty much the same as the above attachment, but makes the Languages Dialog a dencent size as well.
Attachment #209531 - Attachment description: userChrome.css fix for all rigid dialogue boxes → userChrome.css fix for all rigid dialogue boxes in Options...

Comment 135

12 years ago
Comment on attachment 209531 [details]
userChrome.css fix for all rigid dialogue boxes
in Options...

This fix is pretty much the same as the above attachment, but makes the Languages Dialog a decent size as well.
*** Bug 325569 has been marked as a duplicate of this bug. ***
*** Bug 325941 has been marked as a duplicate of this bug. ***
*** Bug 326376 has been marked as a duplicate of this bug. ***
what's left here really isn't a blocker, but an acceptable patch would be taken.

sizeToContent is unreliable though, as I noted earlier.
Flags: blocking-firefox2? → blocking-firefox2-
Comment on attachment 199029 [details] [diff] [review]
patch2: s/height/min-height/ + sizetocontent on pane change

this is not the behaviour we want here, and sizeToContent isn't reliable.
Attachment #199029 - Flags: superreview?(bugs)
Attachment #199029 - Flags: review?(mconnor)
Attachment #199029 - Flags: review-
(In reply to comment #128)
> (From update of attachment 199029 [details] [diff] [review] [edit])
> I'm almost certain that repeated sizeToContent calls result in constantly
> shrinking windows (see the hack in the bookmarks dialog that shows this)

I didn't see any such issue when testing this patch on winxp or linux. That said, the patch doesn't leave a manually enlarged prefwindow alone (on platforms where that's possible), which is wrong.
Assignee: tuukka.tolvanen → nobody
Status: ASSIGNED → NEW
QA Contact: mconnor → preferences

Comment 142

11 years ago
*** Bug 329624 has been marked as a duplicate of this bug. ***

Comment 143

11 years ago
*** Bug 330151 has been marked as a duplicate of this bug. ***

Comment 144

11 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.0.2) Gecko/20060310 Firefox/1.5.0.2 with IFox theme: options do not seem to be clipped at this time.

http://www.radar.250x.com/tb.html

Comment 145

11 years ago
Options dialog is too small in Firefox 1.0.5.2. Using Windows 98. I'm even using small fonts (normal size, 96 dpi).  Screenshot attached.

Comment 146

11 years ago
Created attachment 219390 [details]
Options dialog is too small - cannot resize. Also can't access file download actions.

Comment 147

11 years ago
*** Bug 338184 has been marked as a duplicate of this bug. ***

Comment 148

11 years ago
*** Bug 343005 has been marked as a duplicate of this bug. ***

Comment 149

11 years ago
*** Bug 351114 has been marked as a duplicate of this bug. ***
*** Bug 357304 has been marked as a duplicate of this bug. ***

Comment 151

11 years ago
What occurs here under Linux with Firefox 1.5.0.7 and default theme is that the default height of the Preferences dialogue is chosen so that the latest opened Preferences tab fits in the window. But this height may be too small for the other Preferences tabs.

Could you please change the summary so that it mentions "Firefox Preferences" (in addition to Options)? Under Linux, the window name is "Firefox Preferences", not "Options", and the current summary makes this bug difficult to find (and probably leads to duplicates).

Updated

11 years ago
Summary: Options panels are cropped → Firefox Options (Preferences) panels are cropped (cut off)
*** Bug 340249 has been marked as a duplicate of this bug. ***

Comment 153

11 years ago
It is really disappointing to see that this very simple but very annoying bug is still around. It was in FF 1.0, it was in FF 1.5 and is now in FF 2.0 although there are tons of bug reports in Bugzilla. If it were something difficult I could understand that, but this bug is so simple to reproduce and could be fixed with a few lines of CSS in some chrome within 30 minutes. But still all users on all platforms are plagued with it.

OK, I'm using Firefox 2.0 on MacOSX 10.4.8 at 1024x768.

To reproduce this bug: Open Preferences panel. Select Feeds. Close the panel. Reopen Preferences panel. The panel has become smaller. Go to Content. All buttons and preferences in the lower 1/3 of the window are cut because panel has been shrunken. Solution: Close the Content window and reopen it. All is perfect again.

Panel normal:
http://img511.imageshack.us/img511/3819/grossab9.jpg

Panel cropped:
http://img511.imageshack.us/img511/1033/kleinuh6.jpg

Until the Mozilla developers add a resize field to the Preferences panel or do something else substantial to fix this for good you can use this old CSS (between the lines), it worked on Mac FF 1.5 and works fine on Mac FF 2.0 (should work on Windows and Linux as well):

----------------------------------------------------------------

/* this file fixes the all the dialog size problems in Tools -> Options... */


/* Change the numbers below to suit the fonts you use, and save it as
 * userChrome.css into your profile-directory/chrome/ directory eg:
 *
 * c:\windows\Application Data\Mozilla\Firefox\Profiles\(random)\chrome\
 */


/* set default namespace to XUL - do NOT remove this line */
@namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"); 


#BrowserPreferences {
  width: 78ex !important;
  height: 40em !important;
}


#ConnectionsDialog {
  width: 78ex !important;
}


#FontsDialog {
  width: 78ex !important; 		
  height: 35em !important;
}


#OCSPDialog {
  width: 78ex !important;		 
  height: 22em !important; 
}


#LanguagesDialog {
  width: 60ex !important;		 
  height: 30em !important; 
}

----------------------------------------------------------------

Comment 154

11 years ago
*** Bug 360798 has been marked as a duplicate of this bug. ***
*** Bug 361045 has been marked as a duplicate of this bug. ***

Updated

11 years ago
Duplicate of this bug: 355372

Comment 157

10 years ago
Is there any plan to fix this bug?  It seems like no one is assigned to it, even though it seems like a pretty big problem that's been around for years.  It makes Firefox seem pretty unpolished to the average user.

Comment 158

10 years ago
(In reply to comment #157)
> Is there any plan to fix this bug?  

You answered your own question:

> no one is assigned to it,

Hence, nobody is planning on fixing it.

Updated

10 years ago
Flags: blocking-firefox3?

Comment 159

10 years ago
I have the same issue using W2k and XP SP2.

The lower and the rightmost items on the tools->options dialog window are cropped if the font for dialog items is not the system default (Tahoma, 8 points).

I'm always using Tahoma 7 points since this is still readable properly.

I tried other fonts (proportional and non proportional, and different sizes) and the options dialog gets resized, but not in the right dimensions.

This Bug is there since at least FF 1.5.0, and also present in FF2 and the latest release firefox-3.0a3pre.en-US.win32 from 2/24/2007.
Blocking, but I can't reproduce according to the steps in comment 153. Can someone come up with solid STR for the 1.8.1/1.9 branches?
Flags: blocking-firefox3? → blocking-firefox3+

Comment 161

10 years ago
This doesn't really need a STR. It's pretty obvious. Just install firefox from ftp.mozilla.org , open firefox using a new profiles and then open Edit > Preferences and you'll see that the the Preferences dialog window is cropped at the bottom.

Comment 162

10 years ago
(In reply to comment #161)
> This doesn't really need a STR. It's pretty obvious. Just install firefox from
> ftp.mozilla.org , open firefox using a new profiles and then open Edit >
> Preferences and you'll see that the the Preferences dialog window is cropped at
> the bottom.
> 

I forget to mention that I'm running Linux with latest gtk+ 2.10.11

Comment 163

10 years ago
(In reply to comment #161)
> This doesn't really need a STR. It's pretty obvious. Just install firefox from
> ftp.mozilla.org , open firefox using a new profiles and then open Edit >
> Preferences and you'll see that the the Preferences dialog window is cropped at
> the bottom.
> 
With that STR, this bug is WORKSFORME. More information such as OS, screen size, screen resolution, DPI, OS font family/size settings and other relevant OS settings is needed.

Comment 164

10 years ago
(In reply to comment #163)
> (In reply to comment #161)
> > This doesn't really need a STR. It's pretty obvious. Just install firefox from
> > ftp.mozilla.org , open firefox using a new profiles and then open Edit >
> > Preferences and you'll see that the the Preferences dialog window is cropped at
> > the bottom.
> > 
> With that STR, this bug is WORKSFORME. More information such as OS, screen
> size, screen resolution, DPI, OS font family/size settings and other relevant
> OS settings is needed.
> 

I'm running Linux 2.16.20.4 with gnome 2.18 and latest gtk-engines 2.10 ( clearlooks theme engine ). Font used is 'Bitstream vera sans' which is a extremely popular font among linux users. Font size is 8.
Screen resolution is 1280x1024.

Comment 165

10 years ago
Created attachment 259876 [details]
How to reproduce on WinXP (screenshots)

I've attached a screenshot of how to reproduce this bug.

I'm using Windows XP Home sp2
1024 x 768 resolution
96 DPI (the default)
System font size is "Normal" (not "Large" or "Extra Large")

Thunderbird has the same problem as Firefox.

Comment 166

10 years ago
Sorry, I forgot to mention my version of Firefox:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3

Comment 167

10 years ago
I've been investigating this problem (in Thunderbird, mainly), and here's what I found. There are three issues:

a. The required size of a dialog (to just display its contents and no more) is partly a fixed number of pixels, and partly proportional to the font size.

b. The width of text depends on the font face in a way that is not known to CSS. For example, on my system Bitstream Vera Sans is about 40% wider than Arial Narrow.

c. The width of text is different when the text is translated, and the height might also be different if the text needs more or fewer lines.

Current code sets the dialog size in ems, so it is proportional to the font height. (In CSS, an em is a height.) The number of ems can be set by the translator, dealing with issue c.

Issue a. causes problems.  If your font is smaller than the developer's font, then the dialog overcompensates--it shrinks too much and cuts off content, because it takes no account of the fixed part of its size. (When people see content cut off, they might think it's because their font is large, but in fact this happens when their font is small.)

Issue b also causes problems. If your font is wider than the developer's font (at the same font size) then the dialog might not be wide enough to show all the content.  (I suspect that the platform-dependent sizes were an attempt to address this for platform-default fonts.)

One possible solution is as follows. Remove the style attribute from the dialog element. Place a zero-width vertical strut and a zero-height horizontal strut in the dialog to fix its size, each with a margin sized in px (for the fixed component of the required size) and a height or width in em (for the variable component of the required size). This will set the dialog's size exactly at all font sizes. For issue b., allow plenty of extra width for fat fonts! For issue c., get the strut width from the locale as in the present code.

A second possible solution is as follows. Remove the style attribute from the dialog element. Place an invisible, non-translatable label in the main window containing a text sample to measure the font width. In the code that opens a dialog, compute the dialog size as a fixed component plus a multiple of the size of the sample text. Allow a little extra width because the computed size is still only an estimate. For issue c., get the value of the multiple from the locale.

Both solutions require some work to find the numbers for the fixed and variable parts of each dialog's required size, and some thought about where to put the numbers.
beltzner, comment 120 and comment 107 for str?

Comment 169

10 years ago
(In reply to comment #164)
> (In reply to comment #163)
> > (In reply to comment #161)
> > > This doesn't really need a STR. It's pretty obvious. Just install firefox from
> > > ftp.mozilla.org , open firefox using a new profiles and then open Edit >
> > > Preferences and you'll see that the the Preferences dialog window is cropped at
> > > the bottom.
> > > 
> > With that STR, this bug is WORKSFORME. More information such as OS, screen
> > size, screen resolution, DPI, OS font family/size settings and other relevant
> > OS settings is needed.
> > 
> 
> I'm running Linux 2.16.20.4 with gnome 2.18 and latest gtk-engines 2.10 (
> clearlooks theme engine ). Font used is 'Bitstream vera sans' which is a
> extremely popular font among linux users. Font size is 8.
> Screen resolution is 1280x1024.
> 

@Hussam Al-Tayeb, isn't this bug more for Window users? ...but as for the Preferences on Linux, well it has been working fine for me (regardless of gtk theme, font size etc) ever since Bug 284713 was fixed way back in Sept.9, 2005 on the then nightlies where the Firefox 1.5 was being developed. At least Linux users can manually resize the Preference window, something Window users cannot do.

Comment 170

10 years ago
(In reply to comment #168)
> beltzner, comment 120 and comment 107 for str?
> 
This bug is too generic and too noisy, so I think separate bugs should be filed for specific problems with specific steps to reproduce. This bug could be used as a tracking bug then.

Updated

10 years ago
Duplicate of this bug: 378898
Duplicate of this bug: 379639

Updated

10 years ago
Target Milestone: --- → Firefox 3 beta1

Updated

10 years ago
Duplicate of this bug: 377214

Comment 174

10 years ago
This issue happens for me as well.

Fedora Core 6
xfce4
Sans 8 is my system font
Minefield 3.0a5pre

Edit -> Preferences -> Advanced -> Network

Always results in the right side being clipped.

Comment 175

10 years ago
I get this on my Vista machine but not XP, and then only on the security tab of options. The bottom of the Warning Messages section is cropped. Firefox 2.0.0.4.

Comment 176

10 years ago
(In reply to comment #174)
> This issue happens for me as well.

And for me, on linux. However, I get the problem on a desktop machine with
1280x1024 screen running Fedora core 6, but not on a laptop with 1400x1050 screen running Fedora core 5. I am not aware of any difference in my configuration that could account for the problem.

> Edit -> Preferences -> Advanced -> Network
> 
> Always results in the right side being clipped.

Me too. And also if I click on 'Settings'

Also Preferences --> Content --> Default font: Advanced (button on right.) 

Guys, enough with the "me too" comments. This bug is already marked as blocking Firefox 3.0 and there's already more than enough information in this bug for the developers to fix this bug. Adding more random comments only makes it harder for them to do their job.
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Updated

10 years ago
Duplicate of this bug: 384128

Comment 179

10 years ago
This should depend on Bug 90276 ?
We need to fix this once we're done monkeying with the prefwindow for this release, pushing to M9 in the meantime.
Target Milestone: Firefox 3 M7 → Firefox 3 M9

Updated

10 years ago
Duplicate of this bug: 360548
Created attachment 279198 [details] [diff] [review]
patch - use sizeToContent only when the pane's container is too short and only once per pane.

Hey mconnor, I personally believe this is a very safe and cautious approach. It only calls sizeToContent when the container for the prefpane's _content is too short, it only calls sizeToContent once per prefpane, and it never calls sizeToContent on the initial prefpane shown since that that one is always displayed correctly.
Attachment #279198 - Flags: review?(mconnor)
Comment on attachment 279198 [details] [diff] [review]
patch - use sizeToContent only when the pane's container is too short and only once per pane.

This works but I have another patch almost completed that will accomplish the same end result without using sizeToContent.
Attachment #279198 - Flags: review?(mconnor)
Created attachment 279311 [details] [diff] [review]
patch rev2 - calculate the sizing and set the window's innerHeight

mcconor, this one doesn't use sizeToContent so it should be as safe as it can be. I had to take into account how the last groupbox on a pane may have its bottom border cutoff (see bug 394433). I also had to add a couple of pixels to the .bottomBox padding because even though it worked in most cases there were some edge cases (e.g. 120 dpi, small fonts, etc.) where 2px wasn't enough. I changed the min-height for Linux because I forgot to in Bug 384956.
Assignee: nobody → robert.bugzilla
Attachment #279198 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #279311 - Flags: review?(mconnor)
Comment on attachment 279311 [details] [diff] [review]
patch rev2 - calculate the sizing and set the window's innerHeight

>Index: toolkit/content/widgets/preferences.xml
>===================================================================
>RCS file: /cvsroot/mozilla/toolkit/content/widgets/preferences.xml,v
>retrieving revision 1.61
>diff -u -8 -r1.61 preferences.xml
>--- toolkit/content/widgets/preferences.xml	25 Aug 2007 01:55:29 -0000	1.61
>+++ toolkit/content/widgets/preferences.xml	2 Sep 2007 10:03:43 -0000
>@@ -732,26 +734,42 @@
>             if (prefpanes[i] == aPaneElement) {
>               this._paneDeck.selectedIndex = i;
>               
>               if (this.type != "child") {
>                 var oldPane = this.lastSelected ? document.getElementById(this.lastSelected) : this.preferencePanes[0];
>                 oldPane.selected = !(aPaneElement.selected = true);
>                 this.lastSelected = aPaneElement.id;
>                 this.currentPane = aPaneElement;
>-                this._initialized = true;
>-
please ignore the accidental removal of the newline... I've fixed this in my tree.
I'd like to add the following to the prefWindow constructor so when browser.preferences.animateFadeIn is true so we behave more sanely on Windows / Linux. There is still the problem when opening to the Tabs prefpane since it uses flex to workaround bug 349098 but it at least works when starting from any other prefpane whereas today it gets all messed up.

if (!this._initialized && this._shouldAnimate) {
  if (this.style.minHeight)
    this.style.minHeight = 0;
}
note: I believe I can set the height of the prefpanel using the logic in this patch and thereby remove the need for the flex on the tabs prefpanel
Comment on attachment 279311 [details] [diff] [review]
patch rev2 - calculate the sizing and set the window's innerHeight

ok, I like this better, r=me, thanks!

note to the legions of people cced on this byg: this should be in Firefox 3 alpha 8 at this rate, please test that release if you want to see this fixed.
Attachment #279311 - Flags: review?(mconnor) → review+
Created attachment 279371 [details] [diff] [review]
patch as checked in

One minor change to make this slightly cleaner.
Attachment #279311 - Attachment is obsolete: true
Attachment #279371 - Flags: review+
Checked in to trunk

Checking in mozilla/toolkit/content/widgets/preferences.xml;
/cvsroot/mozilla/toolkit/content/widgets/preferences.xml,v  <--  preferences.xml
new revision: 1.62; previous revision: 1.61
done
Checking in mozilla/browser/components/preferences/preferences.xul;
/cvsroot/mozilla/browser/components/preferences/preferences.xul,v  <--  preferences.xul
new revision: 1.12; previous revision: 1.11
done
Checking in mozilla/browser/locales/en-US/chrome/browser/preferences/preferences.dtd;
/cvsroot/mozilla/browser/locales/en-US/chrome/browser/preferences/preferences.dtd,v  <--  preferences.dtd
new revision: 1.9; previous revision: 1.8
done
Checking in mozilla/browser/themes/winstripe/browser/preferences/preferences.css;
/cvsroot/mozilla/browser/themes/winstripe/browser/preferences/preferences.css,v  <--  preferences.css
new revision: 1.19; previous revision: 1.18
done

Filed spinoff Bug 394666 for comment #186 and other things I have found to make the prefWindow behave better on Windows / Linux.
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Target Milestone: Firefox 3 M9 → Firefox 3 M8

Comment 191

10 years ago
The last checkin only fixes half the issue.
It does fix the vertical cut off and now the preferences aren't cropped at the bottom.
But there is still the vertical direction. The 'advanced' tab is horizontally cropped (at the right).
So height is fixed but there is still a width issue in 'advanced' tab.
Can this be easily fixed?

I'm investigating that and other issues in Bug 394666 per comment #190.
(In reply to comment #191)
> The last checkin only fixes half the issue.
> It does fix the vertical cut off and now the preferences aren't cropped at the
> bottom.
> But there is still the vertical direction. The 'advanced' tab is horizontally
> cropped (at the right).
> So height is fixed but there is still a width issue in 'advanced' tab.
> Can this be easily fixed?
Filed bug 394791 for this issue

Updated

10 years ago
Blocks: 396914

Updated

9 years ago
Duplicate of this bug: 427640

Updated

8 years ago
Depends on: 394299
Blocks: 412325
Blocks: 396541
Blocks: 349098
Blocks: 394433
Blocks: 394299
No longer depends on: 394299
Duplicate of this bug: 355407

Comment 196

6 years ago
The same bug in firefox nightly 8.0a1
You need to log in before you can comment on or make changes to this bug.