Closed Bug 113435 Opened 23 years ago Closed 3 years ago

Dragging files into text pane of compose window does not add attachment

Categories

(MailNews Core :: Composition, enhancement)

Product:
MailNews Core
Component:
Composition
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 1640760

People

(Reporter: yoz, Unassigned)

References

Details

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.6) Gecko/20011120
BuildID:    2001112009

With most mail clients one can drag & drop a file into the text area of a
message compose window and the mailer will add it to the list of attachments.
With Mozilla, you have to drop it on the attachment area - if you drop on the
text area, it adds two blank lines to the mail (in plaintext mode). I can
understand different behaviour with regard to adding images to an HTML mail, but
it makes no sense with plaintext mail.

Reproducible: Always
Steps to Reproduce:
1.Compose a new mail in plaintext mode
2.Drag a file to the message text pane of the compose window


Actual Results:  look at the blank lines that result, and wonder why the file
isn't in the attachments list

Expected Results:  Add the file as an attachment
-->varada
Assignee: ducarroz → varada
confirming -2002-01-14-06 win98
QA Contact: sheelar → esther
QA Contact: esther → trix
Is this still happening with a current version?

pi
Yes (in RC3, WinXP).
Oddly, the text area presents itself as a valid drop target (i.e. has the
arrow+box cursor rather than that no-go cursor). But when the file is dropped,
it just disappears.
Well, two people see it. With Linux I cannot do it. NEW.

pi
Status: UNCONFIRMED → NEW
Ever confirmed: true
Sorry, I should add that since the initial report the behaviour has changed
slightly - no blank lines are added on a file drop. (However, the wondering
where the file went still occurs.)
Blocks: 154188
taking all of varada's bugs.
Assignee: varada → sspitzer
It seems (in 1.5 Final, Windows 2000, anyway) that the cursor changes to 
DoNotDrop when over the message body.

At this point, Reporter (yoz), if you want to keep this bug open, I would 
suggest changing it to an enhancement; the behavior I see is not buggy, it just 
doesn't offer the feature you were searching for.
Agreed - changed severity to Enhancement
Severity: minor → enhancement
I just encountered this also (winXP). The annoying thing is that the behavior
changes depending on message composition mode:

a) you _can_ drag into the text area and attach if you're sending HTML mail
b) you _cannot_ drag into the text area and attach if sending plain text mail

Observed on: 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
If you look at the actual behavior in the HTML window, what you see is that the 
result of dropping a file depends on the file type.  Image files are turned into 
an <IMG> tag within the message; because of the way images are handled in HTML, 
these images are included in the mail, but they won't show up in the attachments 
panel.  Other file types are turned into a file:// link; those files are not 
included in the mail, and when the message arrives, it's highly unlikely the 
link will work for the recipient unless the path/file is commonly found on many 
systems at the same path.

If you drag to the attachments panel, however, any file is included in the mail, 
as an attachment.

The plain-text mail composer obviously cannot handle embedding messages inline; 
that's probably why it refuses drops on the message body.
Has there been a conscious decision made along these lines, that dropping an
image on the text area implies embedding (rather than attachment) and that the
plain text composer should thus refuse dropped files? Or is it just that
nobody's bothered enabling it?

IMHO, dropping a file on a plain text mail implies attachment, as would dropping
a non-image type on an HTML mail.
I agree with yoz -- there should be no difference between HTML and plain-text
mode for embedding  or attaching files to an outgoing message: both should
create an appropriate MIME attached file. How this gets desplaed by the editing
UI (embed link or whatever in HTML, or add to 'attachment' panel in plain text
mode) is a UI decision 

Also, Mike's observations of non-image embeddings is incorrect (I tested this
myself, as I too was confused) -- they are sent as attached data, and can be
'saved as' by the recipient.  (Mozilla is confusing in this regard by having a
file:// url and a cid: url for each non-image attachment -- in the received
message (at least as received by Mozilla mail) the latter does nothing, while
the former lets you 'save' as expecte).  

Ian is correct about the non-image embeddings; I didn't poke deeply enough.

Note, tho, if the message is sent as plain text the embedded object will not be 
part of the sent mail (i.e. bug 187064).
Regarding the drag-into-HTML-body case, I encountered bug 241921 today, part of 
which related to the discussion here from comment 10 onwards.
In previous comment, I meant bug 241291.

See bug 236178.
*** Bug 215351 has been marked as a duplicate of this bug. ***
*** Bug 254933 has been marked as a duplicate of this bug. ***
*** Bug 261487 has been marked as a duplicate of this bug. ***
Product: MailNews → Core
*** Bug 282402 has been marked as a duplicate of this bug. ***
*** Bug 312029 has been marked as a duplicate of this bug. ***
(In reply to comment #11)
> The plain-text mail composer obviously cannot handle embedding messages inline; 
> that's probably why it refuses drops on the message body.

This is not what happens in TB 1.0.6 (20050716) on Windows XP. There, the behaviour is completely misleading: I can drop the images while composing in plain-text and they appear inline with text. However, when I send the message, images are silently dropped and only the text is delivered. I would argue that this behaviour warrants changing the severity from "enhancement" to at the very least "normal" and possibly "major", since it causes data loss.

BTW, I believe the right thing to do in this case would be to send the message as multipart/mixed and simply alternate plain/text parts with image/<x>, as they occurred in the compose window.
Okay - requesting more info from others on what I should do with this bug, based on Davor's comment.

1: Switch from product "Core" to "Thunderbird"? Is Core/MailNews still being used by the Seamonkey (or whatever it's called now) team?
2: Has anyone tried dragging and dropping in TB 1.5beta?

(In reply to comment #22)
> (In reply to comment #11)
> > The plain-text mail composer obviously cannot handle embedding messages 
> > inline; that's probably why it refuses drops on the message body.
> 
> This is not what happens in TB 1.0.6 (20050716) on Windows XP. There, the
> behaviour is completely misleading: I can drop the images while composing in
> plain-text and they appear inline with text. 

If the image appears in the editor, you are not using the plain-text editor.  
No exceptions; the plain-text editor simply does not support images.


> However, when I send the message,
> images are silently dropped and only the text is delivered. 

Presumably, you are using the HTML editor but sending in plain text.  The symptom of the dropped image in this case is bug 180997.


(In reply to comment #23)
> 1: Switch from product "Core" to "Thunderbird"? Is Core/MailNews still being
> used by the Seamonkey (or whatever it's called now) team?

"Core" means used in TB *and* Seamonkey; this RFE is correctly filed.
(In reply to comment #24)
> If the image appears in the editor, you are not using the plain-text editor.  
> No exceptions; the plain-text editor simply does not support images.

Sorry, I thought if my settings are to always send as text only, I would get the plain text editor to compose the messages.
*** Bug 342024 has been marked as a duplicate of this bug. ***
OS: Windows XP → All
Hardware: PC → All
Assignee: sspitzer → nobody
QA Contact: stephend → composition
Product: Core → MailNews Core
happy birthday to this bug, is it really 9 years old? :)

btw i found a workaround / solution for my specific use case, which is dragging a message or messages to another message in order to add them as an attachment. the solution i found was just to select the message/s you wish to attach, then from the message menu select "forward as attachment", saves an awful lot of fiddly dragging, problem solved (in my use case anyway)
(In reply to comment #30)
> btw i found a workaround / solution for my specific use case, which is dragging
> a message or messages to another message in order to add them as an attachment.

You can also drag and drop onto the address pane of the compose window. I'm not sure what the right behavior for the text pane would be, though. HTML composition makes it a bit more complicated.
howdy y'all,

my workaround for this is to add the following ...
"
@namespace url(http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul);
#attachments-box, #attachmentbucket-sizer {
	display: -moz-box !important;
	visibility: visible !important;
	}
"
... to my stylish style list. you can also just plop it into your userstyle.css file for tbird. 

it makes an empty attachment box open when you open a new compose window. that way you have an always-there drop target that WILL work.

hope that helps,
lee
Lee, as I alluded to above, you don't actually have to do that. If you drag to the address pane, it will open the attachment box automatically.
howdy jim,

yes, i saw that. [*grin*] it's why i added my workaround - to show a VERY obvious drop target. the address pane is ... not obvious to me. thanks for yuor note, tho.

take care,
lee

Great news! Thanks to Alex (:aleca), our highly energetic UX lead, this awesome and much-requested* feature has finally landed in Thunderbird 91 as part of bug 1640760!

Depending on attachment type, you even get to choose between Insert inline vs. Add as attachment.
Check out the screenshot in the New user interface for adding attachments section of my New in Thunderbird 91 SUMO article.

*: 8 duplicates here

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE

Oh wow, a 20 years old request...can I get a badge? :D

(In reply to Alessandro Castellani [:aleca] from comment #37)

Oh wow, a 20 years old request...can I get a badge? :D

I definitely think you deserve a badge!!! :-)

You need to log in before you can comment on or make changes to this bug.