285295 - distracting "saving" dialog during attachment drag

Status: NEW

(MailNews Core :: Attachments, enhancement)

Description

[Eric J. Schwarzenbach]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050223 Firefox/1.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050223 Firefox/1.0.1

When selecting and attachment and dragging it to a folder to save it, a "Saving"
dialog pops up in the middle of the drag. Too quick to read generally, though
the attachment size affects this. I'm not really sure what it is doing...saving
to a temp area in preparation for moving to the folder you drag to? There seems
to be field in the dialog with an application name, which makes me wonder if its
trying to open the file also (though it doesn't succeed apparently).

Anyway someone should review whether this dialog is appropriate at all or
indicative of something wrong going on; however even if it is not, the dialog
popping up in the middle of a drag action is distracting and what I would
consider "surprising" behavior to the user and should be changed.


Reproducible: Always

Comment 1

[Mike Cowperthwaite]

I agree this is a distraction, but when dragging an attachment from an IMAP file 
it's sensible, since the attachment needs to be downloaded.

It could be suppressed for drags from local folders, however.

Comment 2

[Eric J. Schwarzenbach]

I think there are 2 issues here. One is whether it should happen or not, about
which you are probably right (though I'm not sure why it should be a case of
supression of something, vs functionality that is attached to IMAP specific
implementation that doesn't even come into play in the POP case).

The second issue is WHEN it happens. Even in the IMAP case, it shouldn't happen
while the user is still dragging. Keep in mind a drag operation can be aborted
before the drop happens, in which case the download should never occur at all.

Comment 3

[Mike Cowperthwaite]

(In reply to comment #2)
> The second issue is WHEN it happens. Even in the IMAP case, it shouldn't
> happen while the user is still dragging. Keep in mind a drag operation can be
> aborted before the drop happens, in which case the download should never
> occur at all.

I think the point is to get the download started as soon as possible, to improve 
the response.

While working on bug 252479, it occurred to me that even for POP, this dialog 
has a use, of sorts, by indicating that the temporary file has been created from 
the attachment info -- it can take nontrivial time to decode a large Base-64 
file.  However, it occurred to me that it might be cool if the mouse pointer 
itself could indicate some of that status.

I'm thinking that when the drag commences, the pointer be changed to a DO NOT 
DROP icon combined with an hourglass -- indicating "drop not possible because 
waiting (for file to be created, or for download to start)".  Then as soon as 
the file is created, it changes to the standard "dragging item" cursor.

I don't know how dropping to an application is affected by slow access to an 
attachment, in part because I don't know which application owns the drop event. 
If the receiving application gets the drop, and greedily expects its data right 
away, maybe TBird needs to disallow dragging an attachment from IMAP until it's 
already downloaded -- irritating to a user who simply wants to drag it, but so 
is dropping the attachment and getting a File Not Found error.
(Also, see bug 273032).

Comment 4

[Eric J. Schwarzenbach]

(In reply to comment #3)
> (In reply to comment #2)
> > The second issue is WHEN it happens. Even in the IMAP case, it shouldn't
> > happen while the user is still dragging. Keep in mind a drag operation can be
> > aborted before the drop happens, in which case the download should never
> > occur at all.
> 
> I think the point is to get the download started as soon as possible, to improve 
> the response.

That is a good optimization, but the user doesn't need (or want) to know about
this until he has to wait for it (which will be after he unclicked the mouse to
perform the drop, and only if it takes long enough). 

> While working on bug 252479, it occurred to me that even for POP, this dialog 
> has a use, of sorts, by indicating that the temporary file has been created from 
> the attachment info -- it can take nontrivial time to decode a large Base-64 
> file.  However, it occurred to me that it might be cool if the mouse pointer 
> itself could indicate some of that status.
> 
> I'm thinking that when the drag commences, the pointer be changed to a DO NOT 
> DROP icon combined with an hourglass -- indicating "drop not possible because 
> waiting (for file to be created, or for download to start)".  Then as soon as 
> the file is created, it changes to the standard "dragging item" cursor.

You really want to make the user have to wait to complete his drag operation for
this? Imagie if drag and drop file copies on the desktop were implemented that
way? That would be horrible. Again you have to imagine the case of a slow
connection and a large file.

This action is completely analogous to drag and drop file copying between
folders in any graphical OS (where one folder might be on a remote or slow
device). There's nothing new here, it should behave (to the user) exactly as
this well known and well-working operation behaves.

Comment 5

[Mike Cowperthwaite]

Still seeing this on branch or trunk?  I can't reproduce with 2b1-1026, Win2K, but I can easily reproduce it in 1.5.0.7.

Comment 6

[Steven Schram]

Still see it on 2.0.0.6.