52564 - UW IMAP UI: New Folder Dialog is not displaying completely

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect, P3)

Description

[Karen Huang]

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

[Karen Huang]

Attachment: Attached the UW New folder dialog is not displaying completely

Comment 2

[Karen Huang]

Adding keywords: nsbeta3

Comment 3

[scottputterman]

reassigning to jefft.

Comment 4

[R.K.Aa.]

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

Comment 5

[jefft]

Don't know why ... Accepting ...

Comment 6

[selmer (gone)]

This is not even close to P1 or P2, nsbeta3-.

Comment 7

[Ninoschka Baca]

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 
appears)

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

[scottputterman]

reassigning jefft's bugs to naving

Comment 9

[Navin Gupta]

Have a fix

Comment 10

[Scott MacGregor]

sr=mscott

Comment 11

[Navin Gupta]

Fix checked in for both problems

Comment 12

[Navin Gupta]

Marking fixed..

Comment 13

[Peter "jag" Annema]

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

[Peter "jag" Annema]

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

Comment 15

[Navin Gupta]

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

[Peter "jag" Annema]

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

[Navin Gupta]

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

[Peter "jag" Annema]

You rock, thanks for filing that bug :-)

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

Comment 19

[Navin Gupta]

Reopening the bug. The fix is dependent on 62987, 63224. However the 
problem Ninoschka is reporting seems to be fixed.

Comment 20

[Peter "jag" Annema]

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
names).

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

[Peter "jag" Annema]

Working on a patch for this last suggestion.

Comment 22

[Navin Gupta]

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

[Peter "jag" Annema]

Attachment: [patch] don't resize, set to (reasonable) fixed size

Comment 24

[Peter "jag" Annema]

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

[Navin Gupta]

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

[Peter "jag" Annema]

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

[Navin Gupta]

Attachment: Made some minor changes to your patch as suggested by you.

Comment 28

[Navin Gupta]

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
work.

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

Comment 29

[Peter "jag" Annema]

| 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

[Navin Gupta]

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

[Peter "jag" Annema]

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

So do you see that js exception in your console?

Comment 32

[Navin Gupta]

Yes I am seeing the exception

Comment 33

[Peter "jag" Annema]

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

[Navin Gupta]

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

Comment 35

[Navin Gupta]

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.

Comment 36

[Peter "jag" Annema]

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

I can check in these fixes regardless though.

Comment 37

[Navin Gupta]

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

[Scott MacGregor]

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

Comment 39

[Navin Gupta]

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

UW:IMAP
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.

Comment 40

[Karen Huang]

Reopening this bug since this problem is existing on today's build 
02-16-09-Mtrunk build....

Comment 41

[Karen Huang]

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.......

Comment 42

[scottputterman]

marking nsbeta1+ and moving to mozilla0.9.2

Comment 43

[scottputterman]

moving to 0.9.3

Comment 44

[Navin Gupta]

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. 

Comment 45

[Navin Gupta]

Attachment: screenshot of the current new folder dialog.

Comment 46

[Karen Huang]

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.......

Comment 47

[Navin Gupta]

Attachment: proposed fix.

Comment 48

[Navin Gupta]

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

[Håkan Waara]

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

Comment 50

[Navin Gupta]

Attachment: screenshot of the new folder dialog after the fix.

Comment 51

[Håkan Waara]

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

Comment 52

[Navin Gupta]

Attachment: screen shot of the folder dialog after the fix.

Comment 53

[racham]

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.

bhuvan

Comment 54

[scottputterman]

adding the nsbranch keyword

Comment 55

[Navin Gupta]

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

[Navin Gupta]

Attachment: screen shot of then new folder dialog first time

Comment 57

[Navin Gupta]

Attachment: screen shot of the new folder dialog for first time !!!

Comment 58

[Navin Gupta]

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

[scottputterman]

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

[Navin Gupta]

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

Comment 61

[racham]

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.

r=bhuvan

Comment 62

[(not reading, please use [e-mail] instead)]

your last patch seems fine.  sr=sspitzer

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

#1)

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

[Navin Gupta]

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

[Navin Gupta]

partial fix landed on trunk.

Comment 65

[Karen Huang]

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

[Navin Gupta]

For the migrated profile does the server settings migrate properly ?

Comment 67

[Karen Huang]

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

[esther]

trunkverified
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 

Comment 69

[scottputterman]

When the branch is open, please check this into it today.

Comment 70

[Navin Gupta]

fix landed on branch

Comment 71

[scottputterman]

Let's mark this fixed and open another bug for the fact that it still doesn't
show up completely the first time.

Comment 72

[Karen Huang]

Rest issue logged on bug 90734.
Verified this bug on 07-13-06-0.9.2 branch build too.