Closed
Bug 123370
Opened 23 years ago
Closed 21 years ago
Entering a new profile name pushes the buttons out of the dialog box
Categories
(SeaMonkey :: Startup & Profiles, defect, P3)
SeaMonkey
Startup & Profiles
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: ktrina, Assigned: ccarlen)
References
Details
(Keywords: fixed1.4.1, polish)
Attachments
(9 files, 7 obsolete files)
21.88 KB,
image/png
|
Details | |
2.51 KB,
patch
|
timeless
:
review+
dmosedale
:
superreview-
|
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
|
ccarlen
:
review+
jag+mozilla
:
superreview+
mkaply
:
approval1.4.1+
|
Details | Diff | Splinter Review |
27.99 KB,
image/png
|
Details | |
1.99 KB,
patch
|
ccarlen
:
review-
|
Details | Diff | Splinter Review |
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
Updated•23 years ago
|
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla1.1
Comment 1•23 years ago
|
||
Platform -> All (reproduced on Windows XP)
OS: MacOS X → All
Hardware: Macintosh → All
Comment 2•23 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•23 years ago
|
||
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•22 years ago
|
||
Updated•22 years ago
|
Blocks: patchmaker
Attachment #98320 -
Flags: review+
Updated•22 years ago
|
Attachment #98320 -
Flags: superreview?(bzbarsky)
Comment 5•22 years ago
|
||
uh...
from what I see, bug 174121 might be just a dupe of this one....
Comment 6•22 years ago
|
||
*** Bug 174121 has been marked as a duplicate of this bug. ***
Comment 7•22 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•22 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•22 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•22 years ago
|
Attachment #98320 -
Flags: superreview?(bzbarsky) → superreview?(dmose)
Comment 10•22 years ago
|
||
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•22 years ago
|
||
*** Bug 196825 has been marked as a duplicate of this bug. ***
Comment 12•22 years ago
|
||
*** Bug 197028 has been marked as a duplicate of this bug. ***
Comment 13•22 years ago
|
||
Attachment #98320 -
Attachment is obsolete: true
Updated•22 years ago
|
Attachment #117096 -
Flags: superreview?(dmose)
Attachment #117096 -
Flags: review?(timeless)
Attachment #117096 -
Flags: review?(timeless) → review+
Comment 14•22 years ago
|
||
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•22 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•22 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•21 years ago
|
||
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•21 years ago
|
||
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•21 years ago
|
||
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•21 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•21 years ago
|
||
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•21 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•21 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•21 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•21 years ago
|
||
Timeless: you mean something like this?
Buttons horizontally next to each other under the directory label.
Comment 26•21 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•21 years ago
|
||
Last patch looks like this. It's your choice.
Comment 28•21 years ago
|
||
Comment on attachment 125947 [details]
Screenshot from last patch
.
Updated•21 years ago
|
Attachment #125947 -
Attachment is patch: false
Attachment #125947 -
Attachment mime type: text/plain → image/png
Updated•21 years ago
|
Attachment #125947 -
Attachment description: Screenshot from lastt patch → Screenshot from last patch
Assignee | ||
Comment 29•21 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•21 years ago
|
||
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•21 years ago
|
Attachment #125913 -
Flags: superreview?(dmose)
Updated•21 years ago
|
Attachment #125946 -
Flags: review?(timeless)
Comment 31•21 years ago
|
||
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•21 years ago
|
||
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•21 years ago
|
||
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•21 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•21 years ago
|
||
Comment 36•21 years ago
|
||
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•21 years ago
|
||
Assignee | ||
Comment 38•21 years ago
|
||
Had to widen the wizard by 2em and reduce spacer between buttons.
Attachment #126008 -
Attachment is obsolete: true
Updated•21 years ago
|
QA Contact: ktrina → gbush
Comment 39•21 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•21 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•21 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•21 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•21 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•21 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•21 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•21 years ago
|
Attachment #126021 -
Flags: superreview?(jaggernaut)
Comment 46•21 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•21 years ago
|
||
Thanks for the patch - checked in.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Updated•21 years ago
|
Attachment #126021 -
Flags: approval1.4?
Comment 49•21 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•21 years ago
|
No longer blocks: patchmaker
Comment 51•21 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•21 years ago
|
Keywords: fixed1.4.1
Updated•21 years ago
|
Attachment #126021 -
Flags: approval1.4.x? → approval1.4.x+
Comment 52•21 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•21 years ago
|
||
Looks like jag checked it in on the 7th.
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•