71787 - Way too easy to drag the Inbox folder into another folder on first connect

Status: RESOLVED WORKSFORME

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Simon Fraser [no longer active]]

Twice now in one day, I've mistakenly moved my IMAP inbox folder into another 
folder. It happens because I click my inbox as soon as the mail window comes up, 
then move the mouse a bit while waiting for the window contents to show. It seems 
that the mouse up event is only processed later, with the result that a drag was 
detected. This is *really* annoying.

Comment 1

[Simon Fraser [no longer active]]

Well, something really bad happened. After copying the moved "INBOX" folder 
contents back into the newly created inbox (in 4.x), I ended up with lots of 
duplciate messages. After a session of deleting duplicates (again in 4.x), my 
inbox blew up with thousands of duplicate messages (65,000+ msgs), and I'm 
getting "mail over quota" errors. IS are going to purge my inbox  :(

I don't know what role NS6 played in this fiasco, but it certainly precipitated 
something very bad.

Comment 2

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

accepting.

I'll take a look at this one simon.

moving (renaming) special folders like Sent, Drafts, Inbox, Trash, Templates,
Unsent Messages will cause us problems.

since any of those messages have special flags on them, I can fix
messengerdnd.js to make it so you can't dnd (to move) those folder.  you will be
able to dnd to copy.

perhaps the user should be prevent from renmaing special folders, too.

with some of those folders (like sent) if we allow the user to rename it, bad
things will start happening.  (I have to go check, in 4.x I think we'd recreate
the special folders if you renamed one.)

I know we have a bad bug where if you rename a folder that is the target of
filter, we don't do what 4.x does.

adding laurel, putterman, naving and glick to the cc list for comments and
suggestions.

Comment 3

[Navin Gupta]

I am wondering how you got into this situation. I am able to drag the inbox 
but I am not able to drop it anywhere except on Local folders. Even if you 
drop on local folders it is a copy operation, just the way 4x does. 

May be we should not even allow drag operation on inbox. That would be easy, 
but again it raises the question of parity with 4x.

Comment 4

[Navin Gupta]

Sorry, I was trying to reproduce on Windows and the problem seems to be on 
Mac.

Comment 5

[scottputterman]

I can't drag them on Windows either so it sounds like we do have code that
prevents it from happening, just not on the mac. I think it's ok to not allow
them to be dragged for a move, but allow the current functionality of allowing a
copy.

Comment 6

[timeless]

These comments are wrt pop:
there's a bug somewhere out there to fix mail so that special folder's names 
are localizable. folders should be special because of flags, not because of 
names. we really should support rename [but that's for the other bug].

As for move, i don't think there's much reason to support it.

... If we ever convert to a system where all mail handling is controlled by 
filters (so folders are only special because of the icon they are assigned in 
filters and the mapping they get). Then we could support arbitrary movement 
because it would just be an update to the filters.

IMAP is special i guess... <future>we could probably arrange so that moving the 
inbox folder [or renaming it] creates a _final_ filter from Inbox to the new 
name/location.

Comment 7

[Simon Fraser [no longer active]]

I think the issue here is with immediate user feedback, not more general issues 
of whether a certain IMAP folder can be dragged into another one. The bug was 
filed on dragging the inbox, but I'd be equally annoyed if I mistakely dragged 
another folder somewhere I didn't intend to.

So the real bug is that you handle mouse down events soon after the mail window 
comes up (which catches my mouse down as I try to select the inbox), then you 
stay away from the event loop long enough that things feel locked up (by which 
time I've moved hte mouse somewhere). Then you start handling events again, and 
think that a drag has happened. That's what needs fixing.

Comment 8

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

in messengerdnd.js, we try to preven the drop of a folder that has canRename ==
false.  (we also check that to disable "File | Rename")

we check the folder flags to (in nsMsgFolder.cpp, nsNewsFolder.cpp over rides
it) to determine canRename.

so that's all ok.

sfraser comments about the real problem make sense.

Comment 9

[scottputterman]

moving to 0.9.2

Comment 10

[scottputterman]

moving to 0.9.3

Comment 11

[scottputterman]

moving to 0.9.4

Comment 12

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

slide to 0.9.5

Comment 13

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

sliding way out, to mozilla 1.0

Comment 14

[Simon Paquet [:sipaq]]

1.2alpha is long gone. Clearing Target milestone. Question is, since this is a
mac problem, does this happen on Mac OS X too? If yes, it should be moved over
to that OS, if not this bug should be WONTFIX'ed, since Mac classic is dead.

Comment 15

[Simon Paquet [:sipaq]]

This bug is targeted at a Mac classic platform/OS, which is no longer supported
by mozilla.org. Please re-target it to another platform/OS if this bug applies
there as well or resolve this bug.

I will resolve this bug as WONTFIX in four weeks if no action has been taken.
To filter this and similar messages out, please filter for "mac_cla_reorg".

Comment 16

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 17

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 18

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 19

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 20

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 21

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 22

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420

Comment 23

[Karsten Düsterloh]

WFM with current SeaMonkey trunk.