293427 - New tabbed browsing preferences dialog box is clipped - it's too short.

Status: RESOLVED FIXED

(SeaMonkey :: Preferences, defect)

Description

[Jason Bassford]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050507
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050507

The new tabbed browsing preferences window is to short.  The bottom half of the
"A new window" text at the bottom of both columns is cut off by the buttons.

Reproducible: Always

Steps to Reproduce:
1. Edit -> Preferences -> Tabbed Browsing
Actual Results:  
Text is clipped off.

Expected Results:  
Text should not be clipped - the dialog box needs to be expanded.

Comment 1

[Jason Bassford]

Attachment: Screenshot of clipped text in dialog box.

Here's a screenshot.  I confirmed that other people were seeing this (from
Mozillazine) before filing the bug.

Comment 2

[Jason Bassford]

Hmm.  I see that the preferences dialog box is the same size in all instances. 
(I just went through every preference and confirmed that the new tabbed browsing
dialog is the only one with this problem.)  So either it needs to expand in
general, it needs to resize itself dynamically to specific content, or the new
preference layout needs to be adjusted to fit into the current window size.

Comment 3

[Worcester12345]

It looks fine on this version:
Mozilla 1.8b2
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050506

Comment 4

[Jason Bassford]

Still seeing it in 5/9 on a different computer altogether.

Comment 5

[Peter Weilbacher]

I don't have windows so I cannot try there, on Linux it seems fine. DOM
Inspector tells me that I have a font size of 13.3px and I get a window of
684x534px which is close to the size 52x41em set in
xpfe/components/prefwindow/resources/locale/en-US/win/platformPrefOverlay.dtd
It would be easy to change the height there (as it seems to be a Win-only
problem at the moment) but that file contains this comment:

XUL/FE DEVELOPERS: DO NOT MODIFY THIS VALUE. It represents the correct
size of this window for en-US.

(Hmm, the same comment also says that 1em would be the width of the character
"m" which disagrees with the definition of 1em in the CSS specs.)

Comment 6

[Worcester12345]

(In reply to comment #3)
> It looks fine on this version:
> Mozilla 1.8b2
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050506

WinXP Pro SP2, 17" monitor, 1024x768 resolution.

Comment 7

[Felix Miata]

Attachment: 72 DPI Linux Screenshot

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050509

This bug is a function of DPI. Today's on WinXP @ 96 DPI looks exactly like
reporter's screenshot. In contrast, OS/2 & Linux at high DPI leave more than 30
mm of space between the bottom two radio selections and the buttons.

Comment 8

[Jason Bassford]

If it matters, I'm also running XP SP2, but my work resolution is 1280x1024 and
my home resolution is 1600x1200.  Although I really don't see how screen
resolution could possibly be affecting this.  (And if it did, I'd expect people
with a lower resolution to see the problem, not people with a higher resolution.) 

I would assume it should be font size that's the only thing going on here - but
my font size is set to normal.

The only other thing I can think of is that I'm using a custom uxtheme - as you
can see from the screenshot, the window "Close" button isn't standard.  However,
that button take up *less* room than the Windows default so, again, that doesn't
seem to me as if it could be the issue.

Comment 9

[Felix Miata]

Resolution and DPI are independent. Low DPI means the dialog is too small no
matter what your OS or resolution are. DPI affects point sizes, and points are
how moz themers generally size UI text, which in turn impacts required dialog sizes.

Comment 10

[Jason Bassford]

Exactly.  We had a mid-air collision and I almost didn't submit my previous
comment at all (because yours pinpointed the problem a lot more accurately) but
I decided to do so anyway, even if it did make me appear to know a lot less than
you.  Which, in this case, is true. <grin>

Comment 11

[Ian Neal]

Attachment: Possible new layout v0.1a

Could make the radio group horizontal - just not sure whether to indent. Any
comments?

Comment 12

[Jason Bassford]

First, I would make the "Add tabs" radio line up vertically with the other
elements in the left-hand column.  After that, I'm not quite sure where "Replace
existing tabs" should go.  Lining it up with the elements in the bottom
right-hand column might look a little odd.

Perhaps if you changed "Replace existing tabs" to just "Replace tabs" it would
end up as a "middle" column with space for a possible right-hand column (lining
up with the bottom right-hand column) in the future.  Then again, I don't know
if the actual wording can be changed at this point without more complicated debate.

Something else that might work would be to get the "A new tab in the current
window" to fit on just a single line, which would also save on vertical space. 
A possible rewording for *that* that would work would be:

Current tab/window
New tab in current window
New window

That's not too much of a verbage change, it takes up 3 single lines, and conveys
the same meaning...

Comment 13

[Felix Miata]

I have no problem with Ian's proposal.

Comment 14

[Peter Weilbacher]

(In reply to comment #12)
> Something else that might work would be to get the "A new tab in the current
> window" to fit on just a single line, which would also save on vertical space. 

Args, I created the new controls so that the labels appear on one line. Did you
check your dpi settings in Mozilla (or in the system if you have "System
setting" under Appearance -> Fonts)? Strange to see now that it doesn't seem to
work for Ian, either.
Otherwise I agree that shortening the labels won't really hurt.

One could also just move the "When opening a bookmark group" box behind the "Tab
Display" box. "Hide the tab bar..." will probably break, but one still wins
about three lines worth without changing the wording. Horizontal radio buttons
with long texts are not very pretty.

Comment 15

[Peter Weilbacher]

Attachment: Different possibility

Something like this.

On the left I resized the prefs window in height so that the Downloads panel
just fits and in width so that the text "A new tab in the current window" just
folds. That should represent things the way they are on Jason's machine. The
top left "Tab Display" box is flexible.

On the right I used the same size and also shortened the new labels. That
creates a bit space at the bottom (to be used for new options :-) ).

Comment 16

[Ian Neal]

The choice on the right seems best to me

Comment 17

[Jason Bassford]

I agree with Ian, the example on the right looks the best and should solve this
problem.

I'm wondering if it might be possible to somehow get the top left items onto one
line each again.  Changing to "Hide tab bar with one tab" and "Select tabs
opened from links" might just do it.

(I don't even have a "System setting" under Appearance -> Fonts...  The setting
for "Allow documents to use other fonts" is currently set to 96 DPI, but
changing it to 72 DPI doesn't make a difference.)

Comment 18

[Felix Miata]

(In reply to comment #17)
> (I don't even have a "System setting" under Appearance -> Fonts...  The setting
> for "Allow documents to use other fonts" is currently set to 96 DPI, but
> changing it to 72 DPI doesn't make a difference.)

https://bugzilla.mozilla.org/show_bug.cgi?id=114270#c7

Comment 19

[Peter Weilbacher]

Attachment: First patch

Ah, OK, the "System setting" is only unhidden on Unix and OS/2.

It's a matter of a few pixels, it just about fits on one line with the dialog
size I made my last screenshot with, but a just a bit smaller and the second
line breaks. If necessary, one could perhaps strip the plural "s" from that as
well.

Other than the shortened labels in the first box this is the patch to do what I
posted in the right part of the screenshot, including changed help text.

Comment 20

[Ian Neal]

Comment on attachment 183151 [details] [diff] [review]
First patch

>Index: xpfe/components/prefwindow/resources/content/pref-tabs.xul
>===================================================================
>+  <hbox>
Maybe needs equalsize="always"

>+    <groupbox id="generalTabPreferences" flex="1">
>+      <caption label="&tabDisplay.label;"/>
>+      <checkbox id="tabStrip"
>+                label="&autoHide.label;" 
>+                accesskey="&autoHide.accesskey;" 
>+                prefstring="browser.tabs.autoHide"/>
>+      <checkbox id="tabBackground"
>+                label="&background.label;" 
>+                accesskey="&background.accesskey;" 
>+                prefstring="browser.tabs.loadInBackground"
>+                reversed="true"/>
>+    </groupbox>

Comment 21

[Peter Weilbacher]

(In reply to comment #20)
> >+  <hbox>
> Maybe needs equalsize="always"

Then the second groupbox also needs flex="1", but I wanted to get someone with
the problem to first _test_ the patch to see if the shorter labels help to put
everything on one line. If not, it might be better to only have the top left
(but not the top right) box resizable, otherwise the right one -- where the
title makes it very wide -- will get cut off.

Comment 22

[Jason Bassford]

Attachment: Screenshot of first patch.

The patch works like a charm.  I'm attaching a screenshot of it on my system.

Comment 23

[Peter Weilbacher]

Attachment: Slightly improved patch

OK, great, then it fits either way. This then adds equalsize="always" and the
flexes to both of the upper boxes, so that they are always "in sync" with the
lower ones even if the panel gets resized.

neil and jag, you recently looked at another patch for the tabbed browsing
prefs panel, so this should be quick to review. :-)

Comment 24

[[e-mail]]

Attachment: Alternative rearrangement

Because I'm not too keen on the previous patch's wording changes.

Comment 25

[Peter Weilbacher]

Comment on attachment 183385 [details]
Alternative rearrangement

Even on your setup the lower boxes are cut off -- not sure if you have the dpi
"problem" or not.

Isn't there another wording more to your liking that could be used to shorten
the text in the "Tab Display" box? There is just too much wasted space on this
page...

Comment 26

[Felix Miata]

Attachment: image for testcase

Comment 27

[Felix Miata]

Attachment: HTML testcase to show DPI

Those who don't know their DPI can use this to find out what it is set to, and
whether it is accurate.

Comment 28

[jag (Peter Annema)]

I agree with Neil, the current wording is much better than the shorter versions
proposed in the patch.

Perhaps the pref panel is simply too crowded? How about a different approach: we
move all the "how do you want us to handle links" prefs into a new panel. That
would include the mouse-clicks and ctrl+enter prefs from the third groupbox.

I don't really like the horizontally laid out radio group. Though I guess there
are worse things, and if we can't come up with another solution I'd be able to
live with it.

Comment 29

[Jason Bassford]

Having a dialog box that some people don't like (but which fits) is better than
having one that doesn't fit at all.  Especially, as it appears, getting what we
want to go in is going to one of those long debates.  I say check in what we
currently have (fixing the actual problem here), and then work on better
presentation in another bug.

Comment 30

[[e-mail]]

Attachment: Horizontal orient

This will at least make the panel usable with a 10px font.

Comment 31

[jag (Peter Annema)]

Comment on attachment 183630 [details] [diff] [review]
Horizontal orient

sr=jag

Comment 32

[Ian Neal]

Comment on attachment 183630 [details] [diff] [review]
Horizontal orient

Fine as a temporary fix until a new layout can be decided upon

Comment 33

[[e-mail]]

Comment on attachment 183630 [details] [diff] [review]
Horizontal orient

Trivial temporary fix for a Suite pref panel.

Comment 34

[Peter Weilbacher]

Another idea if it's not too late: change the two radio buttons (to add or
replace tabs) into a checkbox, labeled "Add tabs instead of replace" or similar.

Comment 35

[Asa Dotzler [:asa]]

Comment on attachment 183630 [details] [diff] [review]
Horizontal orient

a=asa for seamonkey only change.

Comment 36

[[e-mail]]

Tweak checked in.

Comment 37

[Jason Bassford]

I'm okay with how things are after this patch.  While the wording could be
tweaked, I'm okay with closing this bug.  Anybody who wants to change the
wording can do that elsewhere...

Comment 38

[Felix Miata]

Attachment: screenshot - WinXP 800x600 72 DPI

Can look pretty bad the way it's currently designed, but not just the tabs
panel.

URI in screenshot: http://members.ij.net/mrmazda/auth/dpi-screen-window.html

Comment 39

[Ian Neal]

Attachment: Possible Tab Browser Pref Pane

This is a possible layout for tab browsing pref pane without some of the prefs
which have been moved to a new pref pane.

Comment 40

[Ian Neal]

Attachment: Possible new Link Handling Pref Pane

This is a possible layout for a new "Link Handling" pref pane.

Any comments about this or the reduced "Tab Browsing" pref pane?

Comment 41

[Ian Neal]

Comment on attachment 183366 [details] [diff] [review]
Slightly improved patch

Cancelling old request

Comment 42

[Felix Miata]

The new panel begins "Open tabs instead..." With that description, those first
two checkboxes make more sense in the "Tabbed Browsing" panel than in the new
"Link Handling" panel. The location bar item there isn't described as a link
either directly or indirectly.

Comment 43

[Jason Bassford]

I like the separation (good job), and I also agree with Felix's comment. 
Anything that's about tabs only (the first section of the links panel) should,
instead, be in the tab section.

Comment 44

[Ian Neal]

Attachment: Revised Tab Browser Pref Pane v0.1c

Comment 45

[Ian Neal]

Attachment: Revised Link Handling Pref Pane v0.1c

Moved "Open tabs instead of windows for" groupbox two "Tabbed Browsing" pref
pane

Comment 46

[Felix Miata]

Suits me.

Comment 47

[Ian Neal]

Attachment: Patch for Revised Pref Panes v0.1c

This patch:
* Moves "Link..." prefs from "Tabbed Browsing" to new "Link Handling" pref pane

* Updates help to reflect extra pref pane

Comment 48

[Peter Weilbacher]

Oh my! I think what Felix found in comment 38 is a more basic problem how the
dpi setting and the height and width of the prefs panel (in em) are coupled.
This should be solved elsewhere! Otherwise you will also need to seperate the
Downloads panel, the M&N Composition panel and probably some others as well.

Additionally, it is definitely not a good way to seperate more and more panels
into two and create a lot of wasted space. This is not good UI design and does
not at all help users to find what pref they are looking for! (A user would say
"I want everything to open in Tabs". He would then probably look first in the
Tabbed Browsing panel and not finding the options he wants somewhere under
Advanced.)

May I also point out that in attachment 183341 [details] the renaming was completely
optional. One could do the same thing without renaming and still end up with a
panel that is probably shorter than the Downloads panel.

Comment 49

[Felix Miata]

(In reply to comment #48)
> Additionally, it is definitely not a good way to seperate more and more panels
> into two and create a lot of wasted space. This is not good UI design and does
> not at all help users to find what pref they are looking for! (A user would say
> "I want everything to open in Tabs". He would then probably look first in the
> Tabbed Browsing panel and not finding the options he wants somewhere under
> Advanced.)

I hear you, but link open options are also about new windows, and I don't see
"windows" in the select tree.

This kind of complication is why Firefox prefs are as they are. Those who can't
handle extensive options in prefs can choose Firefox instead.

Comment 50

[Sander]

Are there any systems shipping with DPI set to 72 by default? If not, are there
any reasons to assume a more than minute group of people have it set it like
that? (What were their reasons for setting it?)

It seems to me you can break pref panel no matter what just by setting ever
lower DPI settings. Is there anything that "works" at, say, 48 DPI? I agree with
Peter that creating ever more pref panels is not the way to solve this, but that
(if at all possible) we should find a more global solution.

Comment 51

[jag (Peter Annema)]

I like the new patch v0.1c, though I do agree, we should find a more generic
solution for this.

Is the problem that though the font and dialog size changes with the DPI, the
images (e.g. checkbox, radio button) and such don't, causing the over flow?

Is there a generic solution to this?

The simplest solution seems to be to make the dialog height something like
LINE_COUNT * max(fontHeight96DPI, fontHeightCurrentDPI) where LINE_COUNT is
experimentally determined (looks like 25, give or take).

Can we make the width a certain amount of em, and the height "fit-to-content"?

Just brain storming here.

Comment 52

[Ian Neal]

I have spun the DPI issue into Bug 296695, so this patch can get reviewed/approved.

Comment 53

[Peter Weilbacher]

Do we need the patch even if the DPI issue can get resolved?

Comment 54

[Serge Gautherie (:sgautherie)]

Ian,
Are you still working on this ?

Comment 55

[Ian Neal]

This will probably get wrapped into any post new pref window reorganisation of pref panes...

Comment 56

[Jens Hatlak (:InvisibleSmiley)]

I think this is fixed, probably through bug 390734 (found through bug 484567, verified with new profile in 20090418 nightly on WinXP). Please confirm and close if you agree (I haven't checked other OSs or DPI settings).

Comment 57

[Philip Chee]

WFM on Windows and Linux. Looks like this was fixed by the <prefwindow> migration.