Closed Bug 283697 Opened 19 years ago Closed 16 years ago

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

Categories

(Firefox :: Settings UI, defect)

Product:
Firefox
Component:
Settings UI
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Firefox 3 alpha8

People

(Reporter: mcm.ham, Assigned: robert.strong.bugs)

References

(Blocks 1 open bug)

Details

Attachments

(17 files, 6 obsolete files)

Example of problem
37.87 KB, image/jpeg
Details
screenshot XP/W2k
116.62 KB, image/png
Details
connection settings screenshot
7.22 KB, image/png
Details
fix for "Sanitize" button is partly covered at the bottom
12.36 KB, patch
Details | Diff | Splinter Review
I cant see ports for my proxies
93.05 KB, image/jpeg
Details
Windows XP: Deer Park Alpha 1 - Sanitize Button under privacy
13.67 KB, image/gif
Details
funny "Options panel" with some themes
44.84 KB, image/jpeg
Details
Steve's Patch against trunk
1.16 KB, patch
Details | Diff | Splinter Review
The way it should be?
36.34 KB, image/jpeg
Details
patch against TRUNK with persistent height and width
2.38 KB, patch
mconnor
: review-
Details | Diff | Splinter Review
1.5b1 and 1.6a1 Screenshot with WinXP and Aquatint
67.69 KB, image/jpeg
Details
patch2: s/height/min-height/ + sizetocontent on pane change
2.55 KB, patch
mconnor
: review-
Details | Diff | Splinter Review
improved userChrome.css fix
351 bytes, text/css
Details
userChrome.css fix for all rigid dialogue boxes in Options...
803 bytes, text/css
Details
Options dialog is too small - cannot resize. Also can't access file download actions.
9.41 KB, image/gif
Details
How to reproduce on WinXP (screenshots)
238.47 KB, image/gif
Details
patch as checked in
6.90 KB, patch
robert.strong.bugs
: review+
Details | Diff | Splinter Review 
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.
Attached image 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.
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
Attached image 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.
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.
(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+
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
OS should = ALL
Flags: blocking-aviary1.1?
(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. 
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.
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.

(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.
Attached image connection settings screenshot (obsolete) — 
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.
sorry for the last one. this one is with the access keys removed.
Attachment #176720 - Attachment is obsolete: true
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.

(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-
just add flex="1" to the separator befor the button in privacy panel
*** Bug 285995 has been marked as a duplicate of this bug. ***

    
    

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

    
    

    
  
fix now please

    
    

    
  
(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.


    
    

    
  
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

    
    

    
  
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.

    
    

    
  
Is anyone still seing this bug?

    
    

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

WFM

    
    

    
  
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

    
    

    
  
NOT BLOCKING 1.1???

    
    

    
  
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?

    
    

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

    
    

    
  
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_

    
    

    
  


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

    
    

    
  
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

    
  
Blocks: 279760

    
  
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

    
    

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

    
    

    
  
(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!

    
    

    
  
It is also effecting thunderbird too.  

    
    

    
  
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

    
    

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

    
    

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

    
    

    
  
(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.

    
    

    
  
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.

    
    

    
  


  

        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 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.

    
  

        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");


    
    

    
  
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");
> 



    
    

    
  


  
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 :)

    
    

    
  
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.

    
    

    
  

      
      
      
      

        Attached image
          
        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.

    
    

    
  
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.

    
    

    
  
*** 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.

    
    

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

    
    

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

    
    

    
  
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+

    
  
Flags: blocking1.8b5?

    
    

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

    
    

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

    
    

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

    
    

    
  
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!

    
  
Flags: blocking-aviary2.0?

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
(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.

    
    

    
  
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.



    
    

    
  
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.
> 
> 



    
    

    
  
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 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-

    
    

    
  
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.

    
    

    
  
(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. ***

    
    

    
  
(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.

    
    

    
  
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.



    
    

    
  


  
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.

    
    

    
  
(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.



    
    

    
  
(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.

    
  
Flags: blocking1.8b5- → blocking1.8b5?

    
    

    
  
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.

    
    

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

    
    

    
  
(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

    
    

    
  
(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.

    
    

    
  
(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.



    
    

    
  

      
      
      
      

        Attached patch
          
          
        patch1: sizetocontent onload (obsolete)
        — 
          — Splinter Review
      

    


  
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.


    
    

    
  
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.


    
    

    
  


  
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)

    
    

    
  
(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 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?



    
    

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

    
    

    
  


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

    
  

        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)

    
    

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

    
    

    
  
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. ***

    
    

    
  


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

    
    

    
  
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 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

    
    

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

    
    

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

    
    

    
  
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

    
    

    
  
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.

    
    

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

    
    

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

    
    

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

    
    

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

    
    

    
  
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).

    
  
Summary: Options panels are cropped → Firefox Options (Preferences) panels are cropped (cut off)

    
    

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

    
    

    
  
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; 
}

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

    
    

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

    
    

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

    
    

    
  
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.

    
    

    
  
(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.

    
  
Flags: blocking-firefox3?

    
    

    
  
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+

    
    

    
  
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.

    
    

    
  
(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

    
    

    
  
(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.


    
    

    
  
(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.

    
    

    
  


  
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.

    
    

    
  
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

    
    

    
  
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?

    
    

    
  
(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.



    
    

    
  
(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.

Target Milestone: --- → Firefox 3 beta1

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
(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

    
    

    
  
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

    
    

    
  


  
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)

    
    

    
  


  
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+

    
    

    
  


  
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
Closed: 16 years ago
Resolution: --- → FIXED
Target Milestone: Firefox 3 M9 → Firefox 3 M8

    
    

    
  
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

    
  
Blocks: 396914

    
  
Depends on: 394299
Blocks: 394299
No longer depends on: 394299

    
    

    
  
The same bug in firefox nightly 8.0a1

          You need to log in
          before you can comment on or make changes to this bug.