User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:220.127.116.11) Gecko/20081029 Firefox/18.104.22.168 Build Identifier: 22.214.171.124 (20081105) Moving folders by drag and drop starts copying files without first asking for confirmation. Since this is potentially a time-consuming (minutes, even hours) and destructive process (files in the old location are deleted), it should ask for such confirmation, much as deleting a folder does. I found this bug because my mouse bumped against my computer and caused a huge number of folders to be moved. My only indication of what was going on was the warning that filters would be updated. (And a disk activity light that never went off while TB appeared to be hung.) This also points up a few related bugs that I will describe here, but which someone may want to separate. 1. The "filters associated with this folder will be updated" (or similar wording) alert does not specify which folder it is referring to. If multiple folders are involved, it is hard to know what is going on, since the same alert repeats multiply, giving the impression that TB might be stuck in a loop. This alert box should specify the folder name. This will also have the side benefit that progress on multiple folders is evident. 2. The alert in (1) does not allow any way to cancel the operation, only to say 'ok' and the option to turn off the notification for the future. It should allow a cancellation option. 3. It appears that in a folder move operation which involves updating filters, the folder files are copied before the filter update alert is displayed. The file copy is potentially very time consuming. The update alert should occur before copying starts. This also makes more sense if the user wants to cancel an operation. Reproducible: Always Steps to Reproduce: 1.drag and drop folder[s] from one folder to another in folder pane (leftmost pane in standard display window setup). Actual Results: files moved without confirmation Expected Results: confirmation before destructive operation ask for confirmation.
Hi Peter. Thanks for the report. While one can appreciate the pain cause by doing something accidental, what you describe is an exception and not normal workflow. And I know of no other software that ask for confirmation on drag and drops. cc: Bryan for comment. wontfix? As for your other issues, one issue per bug is the norm, so they should be taken up in other bugs some of which I think may already exist - please search first.
I did search first, extensively. I did my duty to report the bugs when I found nothing similar. I am not involved in maintaining this program; presumably those who are are more intimately familiar with what bugs currently exist. However, feel free to ignore the bug reports. After all, Microsoft and many others have gone far doing that.
(In reply to comment #2) > ...However, feel free to ignore the bug reports. volunteers endeavor not to do that. :) punting to bryan gets this to a person who can offer useful insight. in any case, please file new bugs for each item which interests you. Principles @ https://developer.mozilla.org/en/Bug_writing_guidelines - esp item 3 - may useful
Hi, thanks wayne! We've taken the approach to this problem from a different angle. By implementing the super status bar + activity manager ( bug 257942 ) we should be giving people a window into what Thunderbird is doing. Also the activity manager allows people to cancel / undo operations where possible. So I believe this would solve your problem from the POV where you couldn't understand what TB was doing and couldn't stop it. Soon you'll be able to see what is happening and have a change to stop / undo it. Implementing the confirmation dialog presents a dangerous slippery slope for the application. If I add a dialog for confirmation it will get in the way of some people who are intending to do the drag & drop move. Then we'll need to add a "[x] Don't ask me again" checkbox to the dialog. Finally with the "[x] don't ask again" checked you could end up in the same situation. Arguably your individual situation could have been different if you didn't check the box, but essentially someone will end up there. Thus we have the Activity Manager solution; not asking permission but forgiveness when we're wrong. Of course the lockup / slowdown of Thunderbird is a bit of a separate problem that will need to be solved somehow for any kind of solution to be effective. Not sure what to do about that other than file separate bugs. Marking wontfix only because we're attempting to fix this in a different way.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WONTFIX
Thanks. Bryan's comment sounds like a good approach. As for the screwed if you ask, screwed if you don't ask problem, my druthers would be for a large list of such preferences as many applications have. In this case it would be a preference item about confirmation of certain drag and drop operations. Obviously, if you turn off confirmation, I could still get screwed the way I did, but hey then I have no one to blame but myself. Also, I would differentiate between say drag and drop of a single message vs drag and drop of a whole set of folders, since the cost of fixing inadvertently doing one of them is much more than the other. However, the tendency in FF/TB for the past few years has been to decrease the number of preference options, which I happen to disagree with, but that's the way it is, so I am not suggesting adding one. The most important thing is to have as clear a display of what TB is doing at any given time as is practical.
(In reply to comment #5) > Obviously, if you turn off confirmation, I could still get screwed the way I > did, but hey then I have no one to blame but myself. Also, I would > differentiate between say drag and drop of a single message vs drag and drop of > a whole set of folders, since the cost of fixing inadvertently doing one of > them is much more than the other. You make a really good point here. Though the tendency of most people is not to blame themselves and to blame us, even if they checked the box. :) I like the approach of double checking a "large" move of folders vs. a regular move. I think it would be really difficult to determine what constitutes a large move vs. a regular move. Most choices of a constant value will end up being wrong quickly but we would want to be simple enough that people could easily understand why we're asking. *shrug*
(In reply to comment #6) > (In reply to comment #5) > > I like the approach of double checking a "large" move of folders vs. a regular > move. I think it would be really difficult to determine what constitutes a > large move vs. a regular move. Most choices of a constant value will end up > being wrong quickly but we would want to be simple enough that people could > easily understand why we're asking. *shrug* At the risk of stating the obvious, I can only think of 2 criteria for "large move": number of files, and total number of bytes. Ultimately, of course, the criterion is the user's cost to undo the move. As for choosing thresholds, that is a lot trickier. I'd suggest the following: 1. Set an arbitrary threshold of say 3 files and 50 MB. 2. If either one of these is exceeded, ask first with a question of the form: You are asking to move <n> folders containing <w> MBytes. Are you sure? [y|cancel] (Don't ask me again unless I want to move more than [k] files or [m] MBytes [ ] | never ) (currently <k0> files, <m0> MBytes) 3. The default values might change with new TB versions as you get feedback and typical machine speeds, types of storage, etc. change. My rationale for using both the number of files and the total size, again perhaps stating the obvious, is that the number of files determines the effort of clicking and dragging by hand to undo, while the total size largely determines the amount of time the user has to wait for the undo to happen, assuming bytes actually have to be copied. If only pointers have to be moved, the total bytes could be ignored in the threshold. I would guess that moving multiple folders or large folders is not very common, so it would not be a major nuisance to get such a dialog from time to time. Also, I do not know what the program logic is that is involved in such moves. It might be possible to replace some copies with pointer moves, thus reducing the cost dependency on size. (But I wouldn't recommend that if it comes with a reduced robustness if a crash happens in the middle of an operation.)
You need to log in before you can comment on or make changes to this bug.