Mailbox content gone deep by infinite loop when drag and drop of account onto mailbox in itself.

VERIFIED FIXED in mozilla0.9.1

Status

SeaMonkey
MailNews: Message Display
P2
critical
VERIFIED FIXED
17 years ago
14 years ago

People

(Reporter: hirata masakazu, Assigned: Navin Gupta)

Tracking

({hang})

Trunk
mozilla0.9.1
PowerPC
Mac System 9.x

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta1+])

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
2001041908 mactrunk
Mail/News
Drag and drop the account name onto Inbox within the account.
Result:Infinite loop hang. you have to force quit Mozilla.
Relaunch Mozilla
Result: In box seems to be replaced with a new one. It is empty.
(Reporter)

Comment 1

17 years ago
After the infinite loop hang, there are numerous subdirectories under Inbox.sbd
and old Inbox can be found in the deepest folder.
The account name should not be drag and droppable. 
Summary: Mailbox content lost after infinite loop caused by drag and drop of account onto mailbox. → Mailbox content gone deep by infinite loop when drag and drop of account onto mailbox in itself.

Comment 2

17 years ago
I was able to reproduce with POP account, OK with IMAP (gives an error: "mailbox 
not found", but nothing appears amiss afterward). 
Using 4-19 commercial trunk build mac OS 9.0
Keywords: hang, nsbeta1
QA Contact: esther → laurel

Comment 3

17 years ago
I did not have the empty/replaced Inbox as the reporter did. When I launched 
again (after reboot) all my POP Inbox and other folders were OK.

Comment 4

17 years ago
Submitted talkback and also did a macsbug stdlog, but neither seem to be 
available.

Comment 5

17 years ago
reassigning to naving.  I didn't think we allowed the drag of an account to a
folder?  marking nsbeta1+
Assignee: sspitzer → naving
Priority: -- → P2
Whiteboard: [nsbeta1+]
Target Milestone: --- → mozilla0.9.1

Comment 6

17 years ago
Navin, I think you mentioned to me that you thought our code was preventing this
from happening?
(Assignee)

Comment 7

17 years ago
Yes this bug, if it exists, should be only on mac. 
(Assignee)

Comment 8

17 years ago
Created attachment 32326 [details] [diff] [review]
proposed fix
(Assignee)

Comment 9

17 years ago
If the source folder is a server don't permit drag operation on it. 

Comment 10

17 years ago
r=bienvenu, try seth for sr since he knows the drag drop code.
the fix is correct, but why have the new variable?

how about:

+ // don't allow the user to drag the server
+ if (treeItem.getAttribute('IsServer') == "true") { 
+   return false;
+ }

(Assignee)

Comment 12

17 years ago
fix checked in. verified works on mac. 
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 13

17 years ago
This scenario is OK using apr27 commercial trunk build, mac OS 9.0.
(Also double-checked on win98 and linux rh6.2).
Marking this verified.
However, did find a problem folder-->server/acct level drag&drop problem, logged
separately.
Status: RESOLVED → VERIFIED
(Assignee)

Comment 14

17 years ago
Can you reassign me that bug , you just logged. 
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.