Open Bug 404752 Opened 17 years ago Updated 3 years ago

Borders round preference groups are missing


(SeaMonkey :: Preferences, defect)

Not set


(Not tracked)


(Reporter: hand_of_fate2000, Unassigned)




(2 files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2pre) Gecko/2007112102 SeaMonkey/2.0a1pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2pre) Gecko/2007112102 SeaMonkey/2.0a1pre

In previous builds, there was a border round each group of options in the "Preferences" panel, but this border is missing in the latest nightly builds. Without the border it is not always clear which options come under which title.

The borders are missing in both the new "Preferences" panel and th "legacy prefwindow".,

Reproducible: Always
the groupbox borders appear to be there for me,


Could you please provide screenshots of *both* preference dialoges.

And while you're at it, just verify for us that a new profile does not fix this.
The borders are indeed there under Windows, but not Linux. A new profile does not solve it.
behavior changed between 11/14 and 11/15, looks like bug 403753 (done on purpose).  Perhaps we need some theme changes to make it look better.
Version: unspecified → Trunk
If this was done "on purpose" then this is a request that it be UNdone "on purpose".

The borders were there for a reason, and have a purpose to fulfill. Without the borders the layout is unclear, and looks cluttered and unprofessional. What is needed to "make it look better" is the group borders, which should not have been removed.
The "on purpose" was more in relation to toolkit drivers (pushed by Firefox developers/drivers) to get a more native theme on Linux, and in this case Gnome.

Those working on the suite will have to decide if they want to override this core-toolkit change. I personally think they should, but I don't have final say on this (and this Bug surely should not turn into an opinion bash one way or the other on the merits of this change; imho)

Confirming the bug, because it *does* exist;
Ever confirmed: true
I don't like the rounded groupboxes we now get on Windows either, but there's not a lot we can do about that, unless global themeing gets moved to content.
I think this styling they introduced in bug 403753 is completely senseless and even having it in is a blocker bug because the UI gets almost unusable for a normal user with this. I'm tempted to file a bug about confusing UI with group boxes and request blocking1.9? for it.

The only good solution for this can be to go through nsITheme for styling group boxes, hardcoding the crappy style of one random bad theme can only lead into doom.
Depends on: 403753
Unfortunately, they are correct in a way as this is laid out in the GNOME HIG, see but I still think this should be heavily dependent on the default theme, and if GNOME doesn't have control over that in their themes, then this is one more point where they suck heavily.
Still, bug 349859 is probably the right way to solve this problem.
The first thing to note here is that you're quoting from the guidelines for 
GNOME, and not all users of SeaMonkey are using Gnome. Gnome's style should not
be forced on people who have chosen not to use Gnome.

Secondly, many of the arguments in that document are rather doubtful to say the
least, and it's even more doubtful whether they apply to the SeaMonkey
Preference panel.

The borders in the SeaMonkey preference dialog do not in any way "add visual
noise that can both make a window appear more complex than it really is, and
reduce the ability to quickly scan window elements" as that doubtful document
claim. In fact they enable the user to see which setting belongs in which
category more easily, which makes the panel easier to scan and understand, and
hence make it look less complex. That is the complete opposite of what is being
I'm fully with you, but that unfortunately doesn't change that we do follow GTK/GNOME look-and-feel in the default theme on Linux, even though I'd much more prefer if we'd detect the currently running desktop (environment) and follow its look-and-feel instead, but we don't have the code for that. We'd surely be happy to get that code, if someone can write it up.

I for myself think that whole chapter is a wrong decision on the GNOME side, but still, I think we should make this all go through a native theming framework and make the decisions there.
There's nothing to say that we HAVE to blindly follow all GNOME specifications to the letter. We certainly don't have to blindly follow these specifications at the expense of the usability of the product, or at the expense of users of other environments.

Any "specifications", wherever they come from, need to be carefully considered, and not blindly followed if they are detrimental.

Whatever these specifications say, the borders have a purpose to fulfill, and removing them makes the product less user-friendly in all environments (including but not limited to GNOME).
Might I also point out that because this affects everything with a <groupbox> element in it, this change applies to extensions as well.  If you keep it like this, you'll end up with quite a few extension developers complaining about their XUL rendering wrong, myself included.

Mozilla should not be trying to get an exact match with GNOME's style.  My suggestion, if we're aiming for a general Linux theme, is to create something that looks equally at-place in both GNOME and KDE.  (and looks decent enough in other environments)  The default theme should be general and unbiased.  If someone prefers that it exactly match their desktop environment, well then that's what theme add-ons are for.
(Filter "spam" on 'prefs-nobody-20080612'.)
Assignee: prefs → nobody
QA Contact: prefs
You need to log in before you can comment on or make changes to this bug.