Closed
Bug 90734
Opened 24 years ago
Closed 23 years ago
Migrated UW IMAP UI: New Folder Dialog is not displaying completely for the FIRST time
Categories
(MailNews Core :: Networking: IMAP, defect)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: huang, Assigned: zhayupeng)
Details
(Keywords: fixedOEM, imap-interop)
Attachments
(1 file)
1.61 KB,
patch
|
naving
:
review+
jst
:
superreview+
asa
:
approval+
|
Details | Diff | Splinter Review |
Used 07-13-06-0.9.2 build:
Overview: Refer to bug 52564, after uncheck dual-use folder, there is new design
New Folder Dialog for UW IMAP server, but it seems that it doesn't display
completely ONLY for the migrated UW profile FIRST time
1) Login to a MIGRATED UW IMAP mail account
2) Select File|New|Folder...
3) Actual Results: It displays New folder dialog not completely for ONLY the
FIRST time (OK & Cancel buttons are not displaying completely)
Expected Results: Should display the New folder dialog with OK &
Cancel buttons completelly EVERYTIME.
Additional Info: It's so strange that this is ONLY occurring on a migrated UW
proifle, but not occurring on a new UW profile.
Reporter | ||
Updated•24 years ago
|
Summary: Migrated UW IMAP UI: New Folder Dialog is not displaying completely for the FIRST launch → Migrated UW IMAP UI: New Folder Dialog is not displaying completely for the FIRST time
Comment 1•23 years ago
|
||
I see this happen on my IMAP accounts as well: First time the dialog is opened,
it does not have the buttons, the "Parent" folder is the top folder instead of
the selected folder (I use the context menu to add new folders), the dialog
appears at 0,0 on the display, and when the dialog is filled in and terminated
with "Enter", the new folder is not created.
Build 2001112013, Redhat Linux 6.2.
Seems like removeAttribute("hidden") will not resize the window. So I just set
it to visiable by default.
Could anyone give r=?
But, I don't know why this bug only happen on first time? The window remember
anything after load it?
![]() |
||
Comment 5•23 years ago
|
||
Doesn't this leave the window bigger than it should be? (since it does not
resize when the content is hidden). This seems like a place where
window.sizeToContent() should be called explicitly...
Comment 6•23 years ago
|
||
Pete, Did you test your patch since this bug is about a very specific scenario.
naving, Yes I tested it. With this patch, the windows' size is correct.
Comment 8•23 years ago
|
||
So in the normal case does it look good (when we have dual use folder) ?
Comment 9•23 years ago
|
||
Comment on attachment 90040 [details] [diff] [review]
patch
ok, I tested for normal case, looks ok, r=naving.
Let me know if you want to
check this in for you.
Attachment #90040 -
Flags: review+
Comment 10•23 years ago
|
||
Comment on attachment 90040 [details] [diff] [review]
patch
sr=jst
Attachment #90040 -
Flags: superreview+
Comment 11•23 years ago
|
||
Comment on attachment 90040 [details] [diff] [review]
patch
a=asa (on behalf of drivers) for checkin to 1.1
Attachment #90040 -
Flags: approval+
Assignee | ||
Comment 12•23 years ago
|
||
checked in trunk
Thanks naving, jst
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 13•23 years ago
|
||
checked in NETSCAPE_7_0_OEM_BRANCH (a=jdunn)
Whiteboard: branchOEM+ → branchOEM+ fixedOEM
Comment 14•22 years ago
|
||
*** Bug 64228 has been marked as a duplicate of this bug. ***
Comment 15•22 years ago
|
||
Marking as VERIFIED, tested on 11/06/06 and working as expected.
Status: RESOLVED → VERIFIED
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•