UW IMAP UI: New Folder Dialog is not displaying completely

VERIFIED FIXED in mozilla0.9.3


MailNews: Message Display
18 years ago
14 years ago


(Reporter: Karen Huang, Assigned: Navin Gupta)


Windows NT
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [nsbeta1+][nsbranch+,pdt+])


(9 attachments)



18 years ago
Used 09-13-12-M18 commercial build:

Overview: Refer to bug 28254, after uncheck dual-use folder, there is new design 
New Folder Dialog for UW IMAP server, but it seems that sometimes OK & Cancel 
buttons are not displaying completely from this new folder dialog. (please see 
attached gif file)

1) Login to a UW IMAP mail account
2) Select File|New|Folder... 
3) Actual Results: It displays New folder dialog not completely, OK & Cancel 
buttons sometimes are not displaying completely.

Expected Results: Should display the New folder dialog with OK & 
Cancel buttons completely

Additional Info: This is not occurring every time, but it occurs sometimes.

Comment 1

18 years ago
Created attachment 14645 [details]
Attached the UW New folder dialog is not displaying completely

Comment 2

18 years ago
Adding keywords: nsbeta3
Keywords: nsbeta3
QA Contact: esther → huang

Comment 3

18 years ago
reassigning to jefft.
Assignee: putterman → jefft

Comment 4

18 years ago
*** Bug 52563 has been marked as a duplicate of this bug. ***

Comment 5

18 years ago
Don't know why ... Accepting ...
Target Milestone: --- → M18

Comment 6

18 years ago
This is not even close to P1 or P2, nsbeta3-.
Whiteboard: [nsbeta3-]
Target Milestone: M18 → Future

Comment 7

18 years ago
FYI: Creating a folder on Local Folders also has display problems:
- Select Local Folders
- Select File|New|Folders
- Type the name of the new folder (i.e. Folder1)
- Click on the button below to choose a parent folder.
- After selecting a parent folder notice that you can see part of the parent 
folder, the OK button is difficult to see and the Cancel button is completely 
out of view (the longer the description to the parent the worse the problem 

Workaround: You can click the "x" box to close the dialog or the Enter key to 
create the new folder. Either way it looks sloppy.

Comment 8

18 years ago
reassigning jefft's bugs to naving
Assignee: jefft → naving

Comment 9

18 years ago
Have a fix

Comment 10

18 years ago

Comment 11

18 years ago
Fix checked in for both problems


18 years ago
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 12

18 years ago
Marking fixed..

Comment 13

18 years ago
Can someone explain to me why exactly resizeTo(0, 0); is needed there?
sizeToContent() shouldn't need it, and if it somehow doesn't resize unless you
set the size to 0, 0, then there's a bug.

Comment 14

18 years ago
Okay, so when I leave out resizeTo(0, 0); Mozilla segfaults. This shouldn't
happen. Is there a bug filed on this?

Comment 15

18 years ago
resizeTo(0,0) is required because resizeToContent() does not work as it is
supposed to work. resizeToContent() when called without resizeTo(0,0) more than
one time cause the new Folder window to occupy the
entire desktop. You can comment it out and try. I don't know if there is a bug
filed on resizeToContent() because it should resize to just the content on the
window (without resizeTo(0,0)).  

Comment 16

18 years ago
Isn't it custom in those cases to file a bug if you can't find one, and if the
workaround is needed right now, add it with a ``// XXX this next bit added
temporarily because of bug N'' ?

Comment 17

18 years ago
Okay filed a new bug #62987. If you are working on the same part of the code can
you add the comment you suggest. Thanks for pointing out my mistake... 

Comment 18

18 years ago
You rock, thanks for filing that bug :-)

I am indeed working in that code and will add the XXX comments.

Comment 19

18 years ago
Reopening the bug. The fix is dependent on 62987, 63224. However the 
problem Ninoschka is reporting seems to be fixed.
Depends on: 62987, 63224
Resolution: FIXED → ---

Comment 20

18 years ago
What could be done is changing newFolderDialog.xul to start at a good size
(which allows for long folder names), remove the resizeTo and sizeToContent from
newFolderDialog.js and msgFolderPickerOverlay.js, and add a large enough
resizeTo in case of UW:IMAP (large enough for added content and long folder

The menulist should probably be given a crop="left" to cause an ellipsis to
appear at the left side if the folder name would become too long.

Comment 21

18 years ago
Working on a patch for this last suggestion.

Comment 22

18 years ago
Probably we can just allow the new folder dialog with the users having the ability
to resize the windows and we can wait for window.sizeToContent to be fixed.
sizeToContent() and resizeTo() are no longer needed in msgFolderPickerOverlay.js
I think somebody has checked in the code that fixes the problem of long folder
name not displaying completely in the dialog without these commands.

Comment 23

18 years ago
Created attachment 21073 [details] [diff] [review]
[patch] don't resize, set to (reasonable) fixed size

Comment 24

18 years ago
There was another sizeToContent() in the menu's oncommand in
newFolderDialog.xul, if that's what you were referring to. Did that work for
you, btw?

Comment 25

18 years ago
I just applied your patch. Cropping on left doesn't look that good. I think we 
will have to wait for sizeToContent() to be fixed. 

Comment 26

18 years ago
Well ... Crashing isn't good either, and just taking out sizeToContent() and
making UW:IMAP users resize their dialog doesn't seem right.

Does it look slightly better when you crop right? I just realized I was cropping
the box name instead of the server name.

You could also try a larger width, find something that's more reasonable.

Comment 27

18 years ago
Created attachment 21096 [details] [diff] [review]
Made some minor changes to your patch as suggested by you.

Comment 28

18 years ago
The problems now seems to be fixed by cropping on the right. However a new
problem has been introduced that was not there before. It may be related to the 
new code (newFolderDialog.js ....etc). If you have a UW:IMAP account and have 
the properties set to dualuseFolder the first time you do a new folder the 
dialog does not show the option of messages only or folders only folder. From 
the second time onwards it does show the content correctly. 

Also about the fix I don't know if there are some other IMAP servers which may
have different content for the newFolderDialog. In that case the fix would not

Other than the above two issues I think you have proposed a good fix.

Comment 29

18 years ago
| If you have a UW:IMAP account and have the properties set to dualuseFolder
| the first time you do a new folder the dialog does not show the option of
| messages only or folders only folder. From the second time onwards it does
| show the content correctly. 

Yes, I've seen that in testing... Can you check your console output? It will say
something like document.getElementById("folderGroup").selectedItem not being
defined. The problem here (at least for me) seems to be that the XBL binding
didn't happen at that time.

| Also about the fix I don't know if there are some other IMAP servers which may
| have different content for the newFolderDialog. In that case the fix would not
| work.

Can you explain what you mean here with "different content"?

Comment 30

18 years ago
different content refers to the "different content" we see on the 
newFolderDialog in these two cases( w & w/o UW:IMAP). So I was suggesting if 
there were a third case. However it looks like that you can either have 
dualUsefolders or !dualUsefolders

Comment 31

18 years ago
Ah, okay. Then no, there won't be a third case. (Well, not with what's currently

So do you see that js exception in your console?

Comment 32

18 years ago
Yes I am seeing the exception


18 years ago
Blocks: 61876

Comment 33

18 years ago
naving: I take it this means I have r=naving. I'll see if I can get a= and get
this checked in.

About the exception: I'll file a bug on hyatt about that once I get a smaller
testcase. It is not related, but annoying still. We could add a try/catch around
those lines (with a big XXX comment ;-) ) if really needed.

Comment 34

18 years ago
Okay, r=naving. Checkin the fix ASAP, when you get the super-review.

Comment 35

18 years ago
Peter, There are a log of bugs being filed related to new folder
window crashing, occupying the entire desktop. Can you please check in 
the patch or do you want me to check it for you.


18 years ago
Blocks: 64320

Comment 36

18 years ago
I thought sizeToContent() was fixed, thus fixing those problems?

I can check in these fixes regardless though.
No longer blocks: 64320

Comment 37

18 years ago
I don't find a consistent behavior. I have seen new folder window
causing crash on Linux if you take a few tries to select the 
parent folder in pull-down. Also someone reported the window 
occupying the entire desktop on Win 2000. I think we don't need 
to use sizeToContent()

Comment 38

18 years ago
sr=mscott on the 12/20 16:28 patch.

Comment 39

18 years ago
Peter, thanks for your patch. I have just checked in your patch. 

There is still an issue of new Folder 
window not listing the messages only folder and folders-only folder
options when the new Folder window comes up for the first time only. It 
is not a problem second time onwards. 

This patch however helps in fixing all the crashes on linux and the new Folder
window occupying the whole screen on windows. 

Marking this bug fixed. There is already another bug logged for the UW:IMAP 
issue/problem  mentioned above.
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED

Comment 40

17 years ago
Reopening this bug since this problem is existing on today's build 
02-16-09-Mtrunk build....
Resolution: FIXED → ---

Comment 41

17 years ago
Problem is still existing on current 05-04-06-trunk build
remove OLD nsbeta3 & nsbeta3- keywords & status whiteboard, adding nsbeta1 for 
the NEW keyword. This should be fixed, otherwise users will misunderstand that 
they cannot create new folder.......
Keywords: nsbeta3 → nsbeta1
Whiteboard: [nsbeta3-]

Comment 42

17 years ago
marking nsbeta1+ and moving to mozilla0.9.2
Whiteboard: [nsbeta1+]
Target Milestone: Future → mozilla0.9.2

Comment 43

17 years ago
moving to 0.9.3
Target Milestone: mozilla0.9.2 → mozilla0.9.3

Comment 44

17 years ago
We need to fix this one in 0.9.3 because the new folder dialog does not
show completely. This happens everytime. The user may not be able to create 
a new folder. I will attach the screen shot. 
Severity: normal → critical

Comment 45

17 years ago
Created attachment 40051 [details]
screenshot of the current new folder dialog.

Comment 46

17 years ago
Yes. This should be fixed earlier - that's why I nominate on 05-07 as following:

>This should be fixed, otherwise users will misunderstand that 
>they cannot create new folder.......


17 years ago
Blocks: 68789

Comment 47

17 years ago
Created attachment 40167 [details] [diff] [review]
proposed fix.

Comment 48

17 years ago
The fix is basically to let the window size itself, rather than hardcoding 
height and width. Also set hidden to false for the newFolderTypeBox before 
accessing the folder group.

cc bhuvan for review 

Comment 49

17 years ago
Looks like bhuvan's fix to bug 72458 also fixes this. Beware of code conflicts.

Comment 50

17 years ago
Created attachment 40172 [details] [diff] [review]
screenshot of the new folder dialog after the fix.

Comment 51

17 years ago
(oh... and the screenshot was attached as text/plain)

Comment 52

17 years ago
Created attachment 40173 [details]
screen shot of the folder dialog after the fix.

Comment 53

17 years ago
This one is different from what I am trying to fix in my bug.

But patch in here (removing the default window sizes) is causing problems on
Linux  builds. When we choose a folder from the picker (which calls for window
resize) is   crashing the app.

We need to better the fix. Probably allow resizing if that works. But that is no
good solution.

The ideal thing to happen is the original owner of SIZE_TO_CONTENT bug (if there
 is one) should fix it and then this patch will work fine.


Comment 54

17 years ago
adding the nsbranch keyword
Keywords: nsBranch

Comment 55

17 years ago
okay, the patch works on all three platforms. The only problem is that 
it does not show the Ok and Cancel button fully for the first time (see 
next screen shot). From the second time onwards it works fine (see the 
screenshot dated 06/26/01 15:25)

Comment 56

17 years ago
Created attachment 40397 [details] [diff] [review]
screen shot of then new folder dialog first time

Comment 57

17 years ago
Created attachment 40398 [details]
screen shot of the new folder dialog for first time !!!

Comment 58

17 years ago
I think this is a big improvement if you compare it with the current one before
the fix. looking for r and sr. 

Comment 59

17 years ago
Is that the first time ever or the first time per session?  Regardless, it looks
like what you have will at least be useable.  Does this affect non-UW servers in
anyway (meaning does the dialog come up the right size)?

Comment 60

17 years ago
For UW server it happens first time per session, and the dialog comes in right 
size for non UW servers. 

Comment 61

17 years ago
Leave this bug open after this fix as we need to fix this correctly even for the
first time. Please identify the bug (or file a new bug) which is responsible for
this layout anamoly and mark the dependency.

your last patch seems fine.  sr=sspitzer

as racham adds, don't close the bug until we resolve the first time problem.


Is this only a first time problem?  what happens if you do new folder on a uw 
imap server, close it, do new folder on local mail, close it, and then do new 
folder on the uw imap server?

#2) does using sizeToContent() still make us crash?  seems like using that 
would be the proper fix (and might fix the "first time problem").  if it still 
makes us crash, we should reopen #62987.

Comment 63

17 years ago
1) yes, this is only the first time problem. uw->local->uw worksfine. 
The order does not matter. It screws up only in the first time. 

2) sizeToContent() doesn't resize; infact it does not let the window
resize on it's own. on linux sizeToContent doesn't crash. 

Comment 64

17 years ago
partial fix landed on trunk.


17 years ago
Keywords: vtrunk

Comment 65

17 years ago
Is this fixed completely? Problem is still occurring on the windows platform 
*migrated* profile for the FIRST time launching....

This did pass for the *new profile* for both Windows & Mac platforms...

Not check for Linux yet since there is problem for the profilemanager......

Comment 66

17 years ago
For the migrated profile does the server settings migrate properly ?

Comment 67

17 years ago
I believe that it does. 
Esther also saw this problem on her migrated UW profile.
The strange thing is: FIRST time launch on windows platform will display this 
new folder dialog uncompletely on the upper left corner. And it is so strange 
that this problem is not occurring on the Mac migrated profile.....

Linux new profile is working fine too.

Comment 68

17 years ago
Scott said the 1st time launch was the part not fixed, so per Karen's testing on
the trunk of this fix we will consider this trunkverified 


17 years ago
Whiteboard: [nsbeta1+] → [nsbeta1+][nsbranch+]

Comment 69

17 years ago
When the branch is open, please check this into it today.
Whiteboard: [nsbeta1+][nsbranch+] → [nsbeta1+][nsbranch+,pdt+]

Comment 70

17 years ago
fix landed on branch

Comment 71

17 years ago
Let's mark this fixed and open another bug for the fact that it still doesn't
show up completely the first time.
Last Resolved: 18 years ago17 years ago
Resolution: --- → FIXED

Comment 72

17 years ago
Rest issue logged on bug 90734.
Verified this bug on 07-13-06-0.9.2 branch build too.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.