Entering a new profile name pushes the buttons out of the dialog box

VERIFIED FIXED

Status

SeaMonkey
Startup & Profiles
P3
normal
VERIFIED FIXED
16 years ago
13 years ago

People

(Reporter: K'Trina Medina, Assigned: Conrad Carlen (not reading bugmail))

Tracking

({fixed1.4.1, polish})

Trunk
fixed1.4.1, polish
Dependency tree / graph
Bug Flags:
blocking1.3 -
blocking1.4.1 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(9 attachments, 7 obsolete attachments)

21.88 KB, image/png
Details
2.51 KB, patch
timeless
: review+
Details | Diff | Splinter Review
5.88 KB, image/png
Details
5.95 KB, image/png
Details
1.39 KB, patch
Details | Diff | Splinter Review
6.95 KB, image/png
Details
829 bytes, patch
Conrad Carlen (not reading bugmail)
: review+
jag (Peter Annema)
: superreview+
Details | Diff | Splinter Review
27.99 KB, image/png
Details
1.99 KB, patch
Conrad Carlen (not reading bugmail)
: review-
Details | Diff | Splinter Review
(Reporter)

Description

16 years ago
Steps to reproduce:
1. Install MacOSX build 2001-02-04-08-trunk
2. Open the profile manager and click Create Profile then Next
3. Enter New Profile Name 

Results:
The Choose Folder, User Default and Region Selection buttons get pushed to the
right of the dialog box 

Expected results:
The location path should wrap
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla1.1
Platform -> All (reproduced on Windows XP)
OS: MacOS X → All
Hardware: Macintosh → All

Comment 2

15 years ago
on my Mac OS X box, the buttons start pushing off the screen after only the
6th character. It takes 23 only characters to push the buttons entirely off the
screen and make the dialog unusable. In my opinion, the dialog is unusable after
only 14 characters because so much of the button is obscured.

Comment 3

15 years ago
Created attachment 82907 [details]
"Create Profile" dialog on german Windows 2000: Buttons *always* cut off

I think the problem is worse than it appears to you:
You have no screenshot attached, but from the comments I think at least in the
beginning the buttons are completely visible on english Windows versions.

That is *not* true with at least german Windows 2000 (and probably more
languages as well): as you can see on the screenshot, the buttons are cut off
already at the very beginning! and no matter what profile you enter, the
buttons are *never* completely visible.
(and I think this does not look very professional to a new mozilla user
creating his first profile...)

The reason is probably the different name of the standard path for user data in
other language versions of Windows. "application data" contains a space and
this is used for a wrap, I suppose. "Anwendungsdaten" does not contain a space
and therefore there is a quite long string not wrapped (and the window is not
resizable, so I never saw the complete labels of the buttons...).

It might be possible that in other languages the buttons are not visible at
all.
So I propose to raise this bug's severity and address the problem really soon.

Comment 4

15 years ago
Created attachment 98320 [details] [diff] [review]
Proposed patch

Updated

15 years ago
Keywords: patch, polish, review, ui

Updated

15 years ago
Blocks: 146490

Updated

15 years ago
Blocks: 104624

Updated

15 years ago
Attachment #98320 - Flags: review+

Updated

15 years ago
Attachment #98320 - Flags: superreview?(bzbarsky)

Comment 5

15 years ago
uh...

from what I see, bug 174121 might be just a dupe of this one....

Comment 6

15 years ago
*** Bug 174121 has been marked as a duplicate of this bug. ***

Comment 7

15 years ago
Just played around a bit with this patch and it looks very nice - thanks, Neil!
The buttons stay visible all the time.

Since the patch is here for 4 Months now and the first impression of Mozilla
users with german Windows2000/XP is still a box with only partly visible
buttons, could somebody please superreview it? 

Review has been done almost 4 Months ago...

Currently it's on bzbarsky's sr= list, but I know this queue is quite long (I
currently count 17 sr= requests). Maybe someone else might do the superreview?
Thanks very much!
(And sorry for the spam but maybe this patch has simply been forgotten...)

Comment 8

15 years ago
Patch proposed, tested, and reviewed, could this be considered for 1.3 ?
If the path to your profile is long, you can´t use long names, because the
buttons are sliding out of reach.
The bug is trivial, but I wouldn´t see it as polish, because functionality is
sincerely reduced, at least for german users insisting on long profile names.
Flags: blocking1.3?

Comment 9

15 years ago
We're not going to hold the release for this but we'll consider a fully reviewed
patch if it's low-risk. 
Flags: blocking1.3? → blocking1.3-

Updated

15 years ago
Attachment #98320 - Flags: superreview?(bzbarsky) → superreview?(dmose)
Comment on attachment 98320 [details] [diff] [review]
Proposed patch

As discussed with Neil in IRC, this needs at least more commentary, possibly a
bit of restructuring as well.
Attachment #98320 - Flags: superreview?(dmose) → superreview-

Comment 11

15 years ago
*** Bug 196825 has been marked as a duplicate of this bug. ***
*** Bug 197028 has been marked as a duplicate of this bug. ***

Comment 13

15 years ago
Created attachment 117096 [details] [diff] [review]
Updated for review
Attachment #98320 - Attachment is obsolete: true

Updated

15 years ago
Attachment #117096 - Flags: superreview?(dmose)
Attachment #117096 - Flags: review?(timeless)

Updated

15 years ago
Attachment #117096 - Flags: review?(timeless) → review+
Comment on attachment 117096 [details] [diff] [review]
Updated for review

Sorry for not getting to this sooner.  The comments are helpful; thanks.  It
would be nice to have a little vertical whitespace as well.

>+  // use this funky regexp to split the text up
>+  // split long words in case someone names their profile
>+  // llanfairpwllgwyngyllgogerychwyrndrobwyll-llantysiliogogogoch
>+  // magic word length constant pulled from chatzilla
>+  var words = aValue.match( /(\b\w{1,20}\b)|.\s*/g );

20 seems to be an arbitrary constant.  Rather than looking at the number of
characters in the string, isn't the right thing to do actually figure out what
the width of aValue is rendered with the current font?	I'm thinking about CJKV
fonts in particular where the average character width is likely to be
significantly greater than with latin fonts.  If that's too hard, I can be
convinced that this is a reasonable hack, but better justification than "that's
how chatzilla does it" would be nice.
Attachment #117096 - Flags: superreview?(dmose) → superreview-

Comment 15

14 years ago
I suppose that 1.4 will last for some time, so it would be nice to get this in
at least as a quick&dirty hack, if it doesn´t break more than what is already
broken.
I would rather prefer to get the second patch in and (not) improved later,
than not to get the second patch in and also not improved later.
Later is mozilla 1.5, and I doubt anybody will then do anything in the suite.

Comment 16

14 years ago
re-reading comment #14, the negative superreview from 12 weeks ago:

20 seems to be an arbitrary constant.....
....
If that's too hard, I can be convinced that this is a reasonable hack, ....

I assume this patch will only improve the situation, not worsen it.
Lack of this patch gives a very bad impression to new users using mozilla the
first time, and the first 20 seconds are important to a new relationship ;-)

could this be considered once more, checked in while waitng for the blocker bugs?
Would be nice to have it in 1.4, not 1.4.1 sometime, if there will be one.
Flags: blocking1.4?

Comment 17

14 years ago
Created attachment 125902 [details]
Profile Default User, no buttons visible

Worse than ever!
Today I wanted to create a new profile, and didn´t see buttons.
When I deleted the name 'Default User', to enter a new one, some buttons got
visible, but I couldn´t remember what they should mean.

Comment 18

14 years ago
Created attachment 125904 [details]
profile with name deleted, ready for input of new name

Here you see, that after deleting 'Default User', buttons get partly visible,
but can´t be read.
The path shown is a standard windows path, with a three-letter-username.
If I would have used a six-letter-name, the buttons wouldn´t have get visible.
OS is Win98SE.

Now imagine, you are a new user, installing mozilla first time, and want to use
a personal name for your profile, or create a second one.
If you don´t see the buttons, all is well, but if you see them, how to get info
what they will do? There is no help for this.

Raising Severity to major because of this.

Comment 19

14 years ago
Created attachment 125913 [details] [diff] [review]
Alternative, simpler approach

This patch adresses the _button_ problem differently:
It moves them out of the directory-<hbox> down next to the "Click Finish..."
label.

Motivation: this label has a fixed length in english and is very likely to be
similarly short in other languages. If not, it can still use several lines;
there is plenty of room next to the buttons.

Remarks: the "width: 28em" of this label makes the buttons appear at the
correct place: the right. The containing iframe is hardcoded to be 30em wide,
so this fixed 28em are not about to cause problems anyhow.
The <hbox id="dirbox"> seems unneeded now. This id does not show up anywhere
else in lxr, so this hbox could be removed imo. But I'm not completely sure, so
I left it in for others to decide.

Problem: the displayed directory label is still unchanged, this means it might
still be too long to show completely. Solving this problem requires splitting
the string as proposed in the other (refused) patches.
But obviously main developers and reviewers do not recognize how ugly the
problem is with non-english Windows versions and do not care much about the
large number of people using them, therefore this limited approach trying to
satisfy both sides...

Advantages: My solution solves the main problem - the invisible buttons - with
very small changes (which might make it more "reviewable", maybe even
"approvable"...) and does not prevent solving the problem completely (as in the
previous patches). In contrary: it leaves more horizontal space to the
directory label, thus reducing it's number of necessary linebreaks.

Comment 20

14 years ago
Comment on attachment 125913 [details] [diff] [review]
Alternative, simpler approach

Requesting r= from timeless and sr= from dmose (as they had a look at the
previous patches).
This fixes the main problem, maybe even in time for 1.4 (??), but in all cases
still leaves room for an approach as in the patches by Neil.
Please also see my previous comment.
Attachment #125913 - Flags: superreview?(dmose)
Attachment #125913 - Flags: review?(timeless)

Comment 21

14 years ago
Created attachment 125914 [details]
Screenshot of the last patch

How it looks like with this patch: the buttons are at the bottom of the box,
cannot be pushed anywhere by the directory label.

Comment 22

14 years ago
Comment on attachment 125913 [details] [diff] [review]
Alternative, simpler approach

the original real problem (really long paths) still needs to be addressed (your
picture shows /something/ being cut off). but imo there's nothing wrong with
this change.
Attachment #125913 - Flags: review?(timeless) → review+

Comment 23

14 years ago
timeless: I said that in comment #19.

The problem this patch _can_ cause is that the buttons are pushed _down_ if the
directory name is too long. "Too long" being four full lines, which in my tests
was around 250 characters.
But only one button is slightly covered then while all three are already mostly
invisible when the path is not changed at all, so this is still definitely a
major improvement of the buttons problem.

Comment 24

14 years ago
conrad: could we change the layout of the buttons to horizontal? =)
Assignee: ben → ccarlen
Status: ASSIGNED → NEW
Target Milestone: mozilla1.1alpha → ---

Comment 25

14 years ago
Created attachment 125946 [details] [diff] [review]
Buttons horizontally aligned

Timeless: you mean something like this?

Buttons horizontally next to each other under the directory label.

Comment 26

14 years ago
Comment on attachment 125946 [details] [diff] [review]
Buttons horizontally aligned

Requesting r= from timeless. Feel free to move sr= request to this patch if you
like this better.

The <vbox id="dirbox"> may still be removed if it serves no purpose. Its id is
never being used in lxr.
Attachment #125946 - Flags: review?(timeless)

Comment 27

14 years ago
Created attachment 125947 [details]
Screenshot from last patch

Last patch looks like this. It's your choice.
Comment on attachment 125947 [details]
Screenshot from last patch

.

Updated

14 years ago
Attachment #125947 - Attachment is patch: false
Attachment #125947 - Attachment mime type: text/plain → image/png

Updated

14 years ago
Attachment #125947 - Attachment description: Screenshot from lastt patch → Screenshot from last patch
(Assignee)

Comment 29

14 years ago
The horizontal layout is a big improvement over what we have now. I think the
grouping could be better, though. The two buttons on the left are associated,
but have nothing to do with the 3rd. Does "Use Default" mean the
default directory or the default region (to the uninitiated, 1st time user
that's not too bright)? Can the "Region Selection" button be right-aligned, or
separated in some way? 

Comment 30

14 years ago
Created attachment 126005 [details] [diff] [review]
Buttons horizontally, grouped

ccarlen, so more like this?

If the spacer would be flex="1" the right button would be right-aligned which
looks nicer, BUT it also would make it disappear if the directory label is too
long.
I also could fix its position on the very right of the visible area, BUT what
if some translation of its label is a few chars longer?
So I used a spacer with fixed width; translations may shift the buttons to the
right (or left), but there is plenty of room for longer labels now.
Attachment #125913 - Attachment is obsolete: true
Attachment #125914 - Attachment is obsolete: true
Attachment #125946 - Attachment is obsolete: true
Attachment #125947 - Attachment is obsolete: true

Updated

14 years ago
Attachment #125913 - Flags: superreview?(dmose)

Updated

14 years ago
Attachment #125946 - Flags: review?(timeless)

Comment 31

14 years ago
Created attachment 126006 [details] [diff] [review]
Buttons horizontally, grouped, order somewhat reversed

However, I did not like the button placement of the previous patch: the
directory modification buttons are the most likely ones to be used and I guess
from an usability perspective they should appear on the right (that's where
they "always" are and I felt they had to be when I saw the previous patch).
So this patch puts the "Region Selection" button to the left, but leaves
everything else intact (grouping,...).

Comment 32

14 years ago
Created attachment 126007 [details]
Screenshot of last patch

How the last patch looks like.

Read comment #30 on why the directory buttons cannot be placed at the very
right.
Also look at the attachments in bug 146490 for the larger buttons on MacOS;
these alone already would push the right button out of the visible area if it
was positioned to be at the very right border.

Comment 33

14 years ago
Created attachment 126008 [details] [diff] [review]
Simplified patch (does the same as attachment 126006 [details] [diff] [review] above)

Let "dirbox" stay a <hbox>, no need to change it to <vbox> anymore.
Sorry for the spam!
Attachment #126006 - Attachment is obsolete: true

Comment 34

14 years ago
Comment on attachment 126008 [details] [diff] [review]
Simplified patch (does the same as attachment 126006 [details] [diff] [review] above)

Requesting r= from ccarlen and sr= from dmose.
Please feel free to change requests to the patch without reversal or other
reviewers if appropriate.
I'll be away for a few days soon, so please also request approval1.4 if timing
still allows a chance to get it in 1.4.
Thanks!

BTW: I have no checkin permission, so...
Attachment #126008 - Flags: superreview?(dmose)
Attachment #126008 - Flags: review?(ccarlen)

Comment 35

14 years ago
Created attachment 126021 [details] [diff] [review]
Alternatively, just make the overflow work
Comment on attachment 126008 [details] [diff] [review]
Simplified patch (does the same as attachment 126006 [details] [diff] [review] above)

Temporarily removing this from my sr queue, since it appears that there is a
possible alternative patch.  Conrad, once you've chosen which patch you want
and reviewed it, go ahead and add the appropriate patch to my sr list.
Attachment #126008 - Flags: superreview?(dmose)
(Assignee)

Comment 37

14 years ago
Created attachment 126290 [details]
screenshot of attachment 126008 [details] [diff] [review] on OSX using Classic skin
(Assignee)

Comment 38

14 years ago
Created attachment 126291 [details] [diff] [review]
variation of 126008 which allows OSX buttons to fit

Had to widen the wizard by 2em and reduce spacer between buttons.
Attachment #126008 - Attachment is obsolete: true

Updated

14 years ago
QA Contact: ktrina → gbush

Comment 39

14 years ago
Comment on attachment 126291 [details] [diff] [review]
variation of 126008 which allows OSX buttons to fit

Question: what happens when l10n makes the labels longer?
(Assignee)

Comment 40

14 years ago
> Question: what happens when l10n makes the labels longer?

More of them will fit than currently do ;-)

To really fix this, we need a different layout for this dialog. 

Comment 41

14 years ago
We (localization people) will like any layout better that does at least not push
the buttons out of the window when selecting a longer directory name (and the
German names on Windows are that long by default, I guess others migth as well).

The layout with the buttons below the directory display tneds to be much better
there, and I really like it. The length of the buttons themnselves is not the
big problem for now, though I think that's mainly a theme and general dialog
size problem.
I guess it would be nice to include the overflow patch of Neil as well, if it
really works as expected (make only the directory display scrollable if it does
overflow).

Comment 42

14 years ago
Comment on attachment 126008 [details] [diff] [review]
Simplified patch (does the same as attachment 126006 [details] [diff] [review] above)

Removing the r= request because ccarlen posted an updated version of this patch
to make it work with the large OSX buttons.
I knew they are larger, but did not realize they are *that much* larger...

Actually I like Neil's patch better than my own one, but yes, they could also
be combined.

Robert: yes, Neil's patch works as intended (scrollbar(s) only visible if
needed). Another advantage is that the button length does not matter at all
with that patch: with larger buttons the scrollbars just appear with shorter
directory names.
Attachment #126008 - Flags: review?(ccarlen)
(Assignee)

Comment 43

14 years ago
Comment on attachment 126291 [details] [diff] [review]
variation of 126008 which allows OSX buttons to fit

Until we know that the horizontal row of buttons actually fits in other
language other than english, lets not do this.
Attachment #126291 - Flags: review-
(Assignee)

Comment 44

14 years ago
Comment on attachment 126021 [details] [diff] [review]
Alternatively, just make the overflow work

I think this is safer.
Attachment #126021 - Flags: review+

Comment 45

14 years ago
Conrad, so... are you going to seek sr= on this? The fix is so simple but
important, maybe it can still get into 1.4 final...
(Assignee)

Updated

14 years ago
Attachment #126021 - Flags: superreview?(jaggernaut)

Comment 46

14 years ago
Comment on attachment 126021 [details] [diff] [review]
Alternatively, just make the overflow work

sr=jag
Attachment #126021 - Flags: superreview?(jaggernaut)
Attachment #126021 - Flags: superreview+
Attachment #126021 - Flags: approval1.4?
(Assignee)

Comment 47

14 years ago
Thanks for the patch - checked in.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED

Updated

14 years ago
Attachment #126021 - Flags: approval1.4?

Comment 48

14 years ago
verified all platforms, trunk builds 06/26
Status: RESOLVED → VERIFIED

Comment 49

14 years ago
Comment on attachment 126021 [details] [diff] [review]
Alternatively, just make the overflow work

Requesting approval for later releases on the 1.4 branch. Very simple,
virtually risk-free patch with big benefit.

jag, you removed approval1.4? after setting it (when it was clear this patch
had no chance to get in). 
So if you disagree with setting this new flag, please remove it; it is meant to
do what you might have wanted to do yourself...
Attachment #126021 - Flags: approval1.4.x?

Updated

14 years ago
No longer blocks: 104624

Comment 50

14 years ago
mozilla1.4 shipped. unsetting blocking1.4 request.
Flags: blocking1.4?

Comment 51

14 years ago
Andreas: I think I removed the 1.4 flag 'coz it was too late for 1.4 and I was
in a cleaning mood. 1.4.x seems fine, in fact I just got a request to land it on
that branch.

Updated

14 years ago
Keywords: fixed1.4.1

Updated

14 years ago
Attachment #126021 - Flags: approval1.4.x? → approval1.4.x+

Comment 52

14 years ago
Was this checked into 1.4 or not?

It has the fixed1.4.1 flag but I just approved it today.
Flags: blocking1.4.x+

Comment 53

14 years ago
Looks like jag checked it in on the 7th.

Updated

14 years ago
Blocks: 224532
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.