Closed Bug 63758 Opened 24 years ago Closed 23 years ago

Region selection button cut off during profile creation

Categories

(SeaMonkey :: Startup & Profiles, defect, P2)

PowerPC
Mac System 9.x
defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.1

People

(Reporter: amyy, Assigned: samir_bugzilla)

Details

(Whiteboard: Fix in hand; have r, sr, a)

Attachments

(4 files)

Mtrunk build 12-26

Steps:
1. start program
2. when ask for profile selection, click on manage profiles
3. click on create profile
4. click next->

RESULT:
the region selection button is cut off
this may be the same as bug 62955- many windows showing buttons cut off
marking duplicate

*** This bug has been marked as a duplicate of 62955 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Reporter, is this still the case in the latest nightly? If so, we have to reopen
bug 62955 as it was verified fixed a couple of days ago.

Verifying duplicate.
Status: RESOLVED → VERIFIED
oops, yes I am seeing on 122904- Mac trunk build
Yes, it still exists in 12-29-04 Mac build.
Still in 01-08 Mac Mtrunk build.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
nominating nsbeta1, this is a bad first impression. I saw it on todays trunk
also Mac 2001-11-04Mtrunk
Keywords: nsbeta1
Is this *still* reproducable?
I have not seen lately
checked trunk build for 1/22 and branch build for 1/26
For Mac Branch build 01-26-11 I didn't see it, but I still see the cut off 
button in 01-26-04 Mtrunk build.  There is a smoketest result email talked about 
this today from Terri Preston too.
Ok, gotta fix this, setting target milestone mozilla0.9
Target Milestone: --- → mozilla0.9
Marking nsbeta1+, mozilla0.9.1
Keywords: nsbeta1nsbeta1+
Priority: -- → P2
Target Milestone: mozilla0.9 → mozilla0.9.1
nav triage team:

Reassigning to ccarlen owner of profile manager
Assignee: ben → ccarlen
Status: REOPENED → NEW
Actually the Profile manager UI has been changed recently, so the Region 
selection button is display fine now.
Status: NEW → RESOLVED
Closed: 24 years ago23 years ago
Resolution: --- → FIXED
I am barely seeing Region Selection button  on Mac- build 2001050804
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Looking at it.
Status: REOPENED → ASSIGNED
Patch makes the wizard slightly larger which is needed for the modern skin and
its big buttons. Also tested with classic skin. Ben, could you look at this? I
know little of XUL.
Whiteboard: patch, review needed
CC'ing vishy for review and hewitt for sr.
-> vishy
Assignee: ccarlen → vishy
Status: ASSIGNED → NEW
sending to ben
Assignee: vishy → ben
nav triage team:

Let's get this checked in, r=pchen. Adding alecf to cc for sr=
yuck, I shudder with this ugliness, but sr=alecf because I can't think of a
better way to fix this right now
r=ben on the patch. We'll eventually rewrite this wizard using hewitt's XBL 
wizard stuff. 

patch checked in. 
Status: NEW → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
I see more of the button than previousy but bottom part is still partially 
hidden
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
is this fixed enough for the 0.9.1 milestone?
Whiteboard: patch, review needed → good enough for 0.9.l?
If this is fixed, can we close it for verification and open a new bug for any
remaining problems?
Attached image Screen shot of UI
For the US builds, per Grace, this button is readable (small portion still cut
off) and usable for the milestone release.  However, Mac users tend to be more
focused on the look and feel so this may be an issue point for those users.

For the non-US builds, it does look back as per Jon Rubin's screenshot.  The
accompanying text cannot be read.
Since the target market for this feature will be unable to even find the button,
I don't think we should let this slide.  Since the patch to increase the size is
so trivial, please size it a little generously for this milestone and file a
different bug for any fine-tuning you think is required.
Whiteboard: good enough for 0.9.l? → good enough for 0.9.l? No - Ja version unusable
--> samir. 
Assignee: ben → sgehani
Status: REOPENED → NEW
Whiteboard: good enough for 0.9.l? No - Ja version unusable → good enough for 0.9.l? No - Ja version unusable. no patch
Adding meself to the bug.

Samir - I know you just got this one, but how we doing on it?
Jaime,
Haven't looked at it yet.  Looking now.
Status: NEW → ASSIGNED
Tested on an opt build on yxia's Mac OS 9.1 Ja system.

ben, please r.
alecf, please sr.

Thanks.

(Please don't assign int'l bugs to me: I don't have a Ja system.  We were lucky
this was a silly xul hack this time.  In the future I may not be equipped to
deal with such bugs and assigning it to me will cause a layer of indirection
before the bug gets fixed and hence, unnecessary delay.  Thanks!)
Whiteboard: good enough for 0.9.l? No - Ja version unusable. no patch → Fix in hand
Whiteboard: Fix in hand → Fix in hand; need r, sr, a
heh. works for me for 0.9.1
Any chance this can go in after the branch?
sr=alecf
Good point Alec.  I'll try and wait till we branch to check this in.
Whiteboard: Fix in hand; need r, sr, a → Fix in hand; have sr; need r, a
I'm not the module owner, but r=vishy. This is a very simple one-liner. 
Whiteboard: Fix in hand; have sr; need r, a → Fix in hand; have sr; have r, need a
not sure why we would wait for the branch to fix this. If we do not fix the 
underlying problem, then we would have to repeat this hack at the end of m0.9.2. 
Better to fix this on the trunk, and file another bug to mozilla1.0 for getting 
the right fix for the problem. 
I agree with vishy. Why are we waiting? Wouldn't it be less work to check it in
once?
the reason that we don't check it in on the trunk is that the reviewer and super
reviewer think its a nasty hackish fix.  If it gets checked in on the trunk then
the problem is masked.  Please hold until the branch.  Thanks. 

a=asa@mozilla.org for checkin on the branch (not on the trunk).
Firstly, we are waiting for drivers@mozilla.org to respond to my approval
request to checkin this patch.  Jaime, you were cc'ed on the mail seeking
approval from drivers@mozilla.org.  We were waiting for approval which was just
granted.

Secondly, regarding whether we should checkin to the branch or trunk: on the
mac, I discovered that even on 'en' systems the dialog text was still being
chopped a little with the height set to 21.  Hence, bumping up the height to 23
may be the "real" fix already -- so both trunk and branch are appropriate.
(Although it is probably still a bug that the dialog doesn't accomodate all the
widgets -- may be the real estate is not enough and so this is not bug? -- and
so I filed bug 83554 for further investigation.) 
Whiteboard: Fix in hand; have sr; have r, need a → Fix in hand; have r, sr, a
I talked to asa and explained why I'd like to see this one on the trunk also (so
that if it does not regress for intl builds on the trunk during the m0.9.2
cycle). He agreed to let us have this one on the trunk as well. Please check
this into both places. 
Fix checked in to trunk and beta1 branch.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
verified  on branch 2001060409
Keywords: vtrunk
verified in trunk build 2001061205
Status: RESOLVED → VERIFIED
Keywords: vtrunk
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: