Closed Bug 52564 Opened 24 years ago Closed 23 years ago

UW IMAP UI: New Folder Dialog is not displaying completely

Categories

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

Product:
SeaMonkey
Component:
MailNews: Message Display
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.3

People

(Reporter: huang, Assigned: naving)

References

Details

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

Attachments

(9 files)

Attached the UW New folder dialog is not displaying completely
11.28 KB, image/gif
Details
[patch] don't resize, set to (reasonable) fixed size
2.66 KB, patch
Details | Diff | Splinter Review
Made some minor changes to your patch as suggested by you.
2.73 KB, patch
Details | Diff | Splinter Review
screenshot of the current new folder dialog.
15.84 KB, image/jpeg
Details
proposed fix.
1.68 KB, patch
Details | Diff | Splinter Review
screenshot of the new folder dialog after the fix.
24.17 KB, patch
Details | Diff | Splinter Review
screen shot of the folder dialog after the fix.
24.17 KB, image/jpeg
Details
screen shot of then new folder dialog first time
17.84 KB, patch
Details | Diff | Splinter Review
screen shot of the new folder dialog for first time !!!
17.84 KB, image/jpeg
Details 
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.
Adding keywords: nsbeta3
Keywords: nsbeta3
QA Contact: esther → huang
reassigning to jefft.
Assignee: putterman → jefft
*** Bug 52563 has been marked as a duplicate of this bug. ***
Don't know why ... Accepting ...
Status: NEW → ASSIGNED
Target Milestone: --- → M18
This is not even close to P1 or P2, nsbeta3-.
Whiteboard: [nsbeta3-]
Target Milestone: M18 → Future
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.
reassigning jefft's bugs to naving
Assignee: jefft → naving
Status: ASSIGNED → NEW
Have a fix
sr=mscott
Fix checked in for both problems
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Marking fixed..
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.
Okay, so when I leave out resizeTo(0, 0); Mozilla segfaults. This shouldn't
happen. Is there a bug filed on this?
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)).  
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'' ?
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... 
You rock, thanks for filing that bug :-)

I am indeed working in that code and will add the XXX comments.
Reopening the bug. The fix is dependent on 62987, 63224. However the 
problem Ninoschka is reporting seems to be fixed.
Status: RESOLVED → REOPENED
Depends on: 62987, 63224
Resolution: FIXED → ---
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.
Working on a patch for this last suggestion.
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.
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?
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. 
 
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.
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.


| 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"?
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
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?
Yes I am seeing the exception
Blocks: 61876
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.
Okay, r=naving. Checkin the fix ASAP, when you get the super-review.
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.
Blocks: 64320
I thought sizeToContent() was fixed, thus fixing those problems?

I can check in these fixes regardless though.
No longer blocks: 64320
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()
sr=mscott on the 12/20 16:28 patch.
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.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Reopening this bug since this problem is existing on today's build 
02-16-09-Mtrunk build....
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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-]
marking nsbeta1+ and moving to mozilla0.9.2
Whiteboard: [nsbeta1+]
Target Milestone: Future → mozilla0.9.2
moving to 0.9.3
Target Milestone: mozilla0.9.2 → mozilla0.9.3
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
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.......
Blocks: 68789
Attached patch proposed fix. — — Splinter Review 

    
    

    
  
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 

    
    

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

    
    

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

    
    

    
  
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

    
    

    
  
adding the nsbranch keyword
Keywords: nsBranch

    
    

    
  
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)

    
    

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

    
    

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

    
    

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

    
    

    
  
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

    
    

    
  
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.

    
    

    
  
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. 

    
    

    
  
partial fix landed on trunk.

    
  
Keywords: vtrunk

    
    

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


    
    

    
  
For the migrated profile does the server settings migrate properly ?


    
    

    
  
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.

    
    

    
  
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 

    
  
Whiteboard: [nsbeta1+] → [nsbeta1+][nsbranch+]

    
    

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

    
    

    
  
fix landed on branch

    
    

    
  
Let's mark this fixed and open another bug for the fact that it still doesn't
show up completely the first time.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED

    
    

    
  
Rest issue logged on bug 90734.
Verified this bug on 07-13-06-0.9.2 branch build too.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: