404752 - Borders round preference groups are missing

Status: NEW

(SeaMonkey :: Preferences, defect)

Description

[Ed]

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

Comment 1

[Justin Wood (:Callek)]

the groupbox borders appear to be there for me,

winxp/current-seamonkey-trunk

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.

Comment 2

[Ed]

The borders are indeed there under Windows, but not Linux. A new profile does not solve it.

Comment 3

[Ed]

Attachment: New prefwindow, showing the lack of borders

Comment 4

[Ed]

Attachment: Legacy prefwindow, again without borders

Comment 5

[Andrew Schultz]

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.

Comment 6

[Ed]

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.

Comment 7

[Justin Wood (:Callek)]

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;

Comment 8

[[e-mail]]

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.

Comment 9

[Robert Kaiser]

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.

Comment 10

[Robert Kaiser]

Unfortunately, they are correct in a way as this is laid out in the GNOME HIG, see http://developer.gnome.org/projects/gup/hig/1.0/controls.html#controls-frames 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.

Comment 11

[Ed]

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

Comment 12

[Robert Kaiser]

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

Comment 13

[Ed]

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

Comment 14

[Dave Garrett]

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.

Comment 15

[Serge Gautherie (:sgautherie)]

(Filter "spam" on 'prefs-nobody-20080612'.)