User-Agent: Mozilla/5.0 (X11; U; Linux i686; hu-HU; rv:1.7.12) Gecko/20051107 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; hu-HU; rv:1.7.12) Gecko/20051107 the content doesn't fit into the window. Reproducible: Always Steps to Reproduce: 1. open preferences window 2. for example security->cookies won't fit into the window 3. Actual Results: text won't fit Expected Results: preferences window should be larger, or should resise if clicking to a sub-item with huge content

The Preferences has be sized properly for me ever since Bug 284713 was fixed early Sept. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051109 Firefox/1.5 ID:2005110904 Do you still get this problem with a en-US build for example? You should be able to manually resize the Preferences or you could even force the size by putting below in userChrome.css in your Firefox profile. #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; }

Reporter, can you attach a fullscreen screen capture to show us the problem on your system?

Now I downloaded this file to test if problem exists: http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest/mozilla-i686-pc-linux-gnu.tar.gz Mozilla/5.0 (X11; U; Linux i686; hu-HU; rv:1.7.12) Gecko/20051107 The preferences window is too small with this version too. This is a fullscreen screenshot: http://people.inf.elte.hu/pentek_i/doksik/Linux/bugs/Mozilla/preferences.png

Same here: content for the preferences window is too large. I'll attach a screenshot. Note that I've set fontsize in userChrome.css to 10px. Standard font size for the UI is WAY too big.

I've also found the same bug in Thunderbird i expect that someone reads this because somebody says that it's fixed but is not. In Firefox the Preferences menu is bigger (i don't know if this was fixed in firefox) suggestions: make the window have scrollers, resize option, or automatic sizing.

Your screenshot appears to be a preference panel from an extension. If an extension puts too much content on their panel, it will overflow. We can't do a lot about that. Is anyone still seeing this bug with SeaMonkey? Mozilla Suite is no longer supported. http://www.mozilla.org/projects/seamonkey/

I do. Notice how the UI is clipped at the bottom. The Prefs UI is resizable but the new size won't stick -- when closed and reopened, the popup is too small again. Using: - Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5pre) Gecko/2008032107 SeaMonkey/2.0a1pre - Modern theme - I have font-size settings in userChrome.css but I don't think they should affect this popup -- and regardless, IMHO the prefs panel "ought" to be able to sense the size of its contents. Here are my font-size CSS rules: /*************************************************************** * FONTS AND MENUS * ***************************************************************/ /* * define a sans-serif font family for chrome */ * { font-family: "Andale Sans" , "Arial" , sans-serif !important } /* * define a smaller font for Mail & Newsgroups Account Settings */ #accountManager, #accountManager * { font-size: 7pt !important } /* * define a smaller font for the menus */ menubar, menubutton, menulist, menu, menuitem, menupopup { font-size: 7pt !important } menupopup > * { font-size: 7pt !important } toolbar, toolbarbutton { font-size: 7pt !important }

This is not only true on Linux. It is the case on Windows too (and has been since the earliest days of the Mozilla suite). At least the prefs window can be resized on trunk now. Before you simply couldn't ever access stuff. I'm surprised this hasn't been reported more. How is the window size calculated? Is there something I do that makes this happen, changing the font or the grid size perhaps?

Do you still see this after the prefwindow rewrite with current SeaMonkey 2.0a trunk builds?

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20081225 SeaMonkey/2.0a3pre - Build ID: 20081225000454 I still see it, but it depends on the theme: the Modern theme already has it in the main Browser page...

...the default theme, which is OK in the main Browser page, has it in the first subpage of the MailNews prefs...

...and KaiRo's EarlyBlue theme (which, unlike the previous two, is not distributed with SeaMonkey) has it in neither.

Setting Version to Trunk (where I still see the bug) and Platform to All (in the light of comment #8)

Do you see this in safe-mode or in a new profile with no userChrome.css over-rides and with no tweaks to prefs.js/user.js

I see it identically in safe mode (but default theme only of course). Now let's close Sm again and create a virgin profile...

In a virgin profile I don't see the bug (neither in Classic nor Modern theme).

In your original problem profile try renaming userChrome.css, prefs.js and (if it exists user.js) and then retest in safe mode.

Maybe some of the CSS rules I mentioned in comment #7 are relevant? But why couldn't it be possible to have "height: auto" by default instead of some fixed height for the preferences window? Wouldn't that cure the problem for any reasonable user font size (possibly with "overflow: visible" or somesuch if the user-chosen font is "unreasonably" large?)

> But why > couldn't it be possible to have "height: auto" by default instead of some fixed > height for the preferences window? Wouldn't that cure the problem for any > reasonable user font size (possibly with "overflow: visible" or somesuch if the > user-chosen font is "unreasonably" large?) I'll let Karsten or KaiRo answer your question

Here is how to see this bug on Windows: Go to Windows' display settings and change the default font for dialog boxes. I use Comic Sans at size 7pt. Believe it or not Comic is quite a nice readable font for small sizes. With this font, the pref screens are cut off (e.g. Browser or Privacy/Cookies). I'm sure some other fonts are similar. I don't think the actual font size matters, just the font itself. If you use the standard Windows fonts the bug is not there.

This issue was fixed for vertical overflow with bug 868495 for SeaMonkey 2.19 and is pending review for horizontal overflow in bug 1215150. Both allow the window to extend if the content doesn't fit. So, this can probably be closed as a duplicate of bug 868495.

Bug 1215150 checked in today, so this issue is covered by the sum of both patches.