Closed Bug 1699051 Opened 4 years ago Closed 4 years ago

Attachment cannot be dragged from one email message to another

Categories

(Thunderbird :: Message Compose Window, defect)

Thunderbird 87
defect

Tracking

(thunderbird_esr78 unaffected, thunderbird88 fixed)

RESOLVED FIXED
89 Branch
Tracking Status
thunderbird_esr78 --- unaffected
thunderbird88 --- fixed

People

(Reporter: msajner, Assigned: aleca)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file, 4 obsolete files)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:86.0) Gecko/20100101 Firefox/86.0

Steps to reproduce:

One message with attchment listed in the folder. Trying to drag the attachment to newly composed email message.

Actual results:

It si impossible to drop the attachment, resp. the attchment is NOT added to the new message

Expected results:

Attachment should be added to the new email message The only solution is first to save the original attachment to the disk and than drag it from there.

I think it has always been this way?

Flags: needinfo?(thee.chicago.wolf)

(In reply to Wayne Mery (:wsmwk) from comment #1)

I think it has always been this way?

No, until recent versions, I think 86/87... it was working like that np. With the introduction of new attachments handling, it broke.

Flags: needinfo?(alessandro)
Keywords: regression

Tested with 87.0b3 and I cannot drag an attachment from an (expanded) attachment pane to a new message. I've never done it this way though. I always save the file somewhere and then attach that way. If what Marek says is true, I too never knew that was a TB capability.

Flags: needinfo?(thee.chicago.wolf)

This does work ok in 78.8.1 so OP is correct that it did work at some point.

Confirmed, this works in 78 but not in daily or beta.
Regressed by bug 1640760.
I'll take care of it.

Assignee: nobody → alessandro
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(alessandro)
Regressed by: 1640760
Depends on: 1676094
Status: NEW → ASSIGNED

Bug 1676094 introduces a nice array to cherry pick which file type can trigger the revealing of the attachment overlay.
I'll extend that to re-enable attachments dragged from another message.

Attached patch 1699051-attachments.diff (obsolete) — Splinter Review

Easy fix.
You need the patch from bug 1699051 if it hasn't landed yet.

To test this, drag an attachment from a received message directly on top of the compose window for a new message and be sure that the attachment overlay appears and the file is attached on drop.

Attachment #9210500 - Flags: review?(richard.marti)
Attached patch 1699051-attachments.diff (obsolete) — Splinter Review

Tiny comment typo.

Attachment #9210500 - Attachment is obsolete: true
Attachment #9210500 - Flags: review?(richard.marti)
Attachment #9210501 - Flags: review?(richard.marti)

Comment on attachment 9210501 [details] [diff] [review]
1699051-attachments.diff

You meant the patch from bug 1676094 is needed. :-)

Attachment #9210501 - Flags: review?(richard.marti) → review+

Comment on attachment 9210501 [details] [diff] [review]
1699051-attachments.diff

I found a little regression caused by this.
If you click and drag a text link it should add it to the body as normal text but instead it triggers the attachment overlay.
I have to use a different and unique data type.

Attachment #9210501 - Flags: review+ → review-
Attached patch 1699051-attachments.diff (obsolete) — Splinter Review

Used the correct data type.

Attachment #9210501 - Attachment is obsolete: true
Attachment #9210545 - Flags: review+
Attached patch 1699051-attachments.diff (obsolete) — Splinter Review

Unbitrotted

Attachment #9210545 - Attachment is obsolete: true
Attachment #9211050 - Flags: review+

Small comment typo.

Attachment #9211050 - Attachment is obsolete: true
Attachment #9211060 - Flags: review+

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/1f5c475aceb3
Re-enable the support for attaching files dragged from another message. r=Paenglab

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 89 Branch

Beta?

Flags: needinfo?(alessandro)

Comment on attachment 9211060 [details] [diff] [review]
1699051-attachments.diff

[Approval Request Comment]
Regression caused by (bug #): bug 1640760
User impact if declined: Unable to add attachments to the compose window that are dragged from a received message.
Testing completed (on c-c, etc.): on c-c
Risk to taking this patch (and alternatives if risky): low

Flags: needinfo?(alessandro)
Attachment #9211060 - Flags: approval-comm-beta?

A common case is dragging an attachment from a sent message so you don't have to go and find the original in the file system to attach it again to a similar new message.

Comment on attachment 9211060 [details] [diff] [review]
1699051-attachments.diff

[Triage Comment]
Approved for beta

Attachment #9211060 - Flags: approval-comm-beta? → approval-comm-beta+

I have retested this fix with 88.0b2 to confirm, that the attachment now drops on the new message properly, it creates the attachment icon in the edit widow, but when trying to send the message, I am getting this Dovecot error:

Disconnected in APPEND (1 msgs, 20 secs, 10388/93808 bytes) in=10550 out=1109 deleted=0 expunged=0 trashed=0 hdr_count=0 hdr_bytes=0 body_count=0 body_bytes=0

I would assume that attachment is visually dropped on the new message but possibly with zero content?

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

This works for me and it was tested.

It works with multiple attachments and formats.

Please, don't reopen bugs at your will but ask for information first.
If the issue is reproducible by another developer, we can open a follow up bug, or reopen this bug.

Pinging our trustworthy tester Walt to see if he can reproduce the issue described in comment 20.

Status: REOPENED → RESOLVED
Closed: 4 years ago4 years ago
Flags: needinfo?(wls220spring)
Resolution: --- → FIXED

WFM as well.

Walt isn't aware of using any Dovecot server, and can't reproduce the issue using 88.0b3 on Windows 10.

Flags: needinfo?(wls220spring)

I am sorry for spontaneous reopen, I was not aware of the process.

Anyway, I have reproduced the issue today again on 88b2, but I failed it to reproduce it with any other file I tried except the only one specific PDF which failed originally. None of other files regardless their type or filename failed.

I took this specific PDF file, tried even to change the PDF extension to .xxx and it fails again. Interestingly enough, despite the .xxx extension, the icon of the attachment is shown still as PDF. Hence I assume the TB looks inside the attachment to see what format it is actually and this probably affects the way how the attachment data is embedded with the message? Possible internal PDF "corruptions" may cause the behavior?

The result is, that the message is actually sent to the recipient (SMTP send OK), but the error appears when TB tries to save the outgoing message to IMAP "Sent" folder on the server. Anyway, the sent message arrives to the recipient with attachment corrupted (truncated from 88kB to about 4,6kB) so there is possibly some problem already on message composition (attachment embedding) stage.

(In reply to Marek Sajner from comment #24)

I am sorry for spontaneous reopen, I was not aware of the process.

Anyway, I have reproduced the issue today again on 88b2, but I failed it to reproduce it with any other file I tried except the only one specific PDF which failed originally. None of other files regardless their type or filename failed.

I took this specific PDF file, tried even to change the PDF extension to .xxx and it fails again. Interestingly enough, despite the .xxx extension, the icon of the attachment is shown still as PDF. Hence I assume the TB looks inside the attachment to see what format it is actually and this probably affects the way how the attachment data is embedded with the message? Possible internal PDF "corruptions" may cause the behavior?

The result is, that the message is actually sent to the recipient (SMTP send OK), but the error appears when TB tries to save the outgoing message to IMAP "Sent" folder on the server. Anyway, the sent message arrives to the recipient with attachment corrupted (truncated from 88kB to about 4,6kB) so there is possibly some problem already on message composition (attachment embedding) stage.

Can you test again with 88.0b3? You should be able to Help > About Thunderbird > and get the update. Otherwise get it from thunderbird.net.

Flags: needinfo?(msajner)

(In reply to Arthur K. [He/Him/His] from comment #25)

(In reply to Marek Sajner from comment #24)

I am sorry for spontaneous reopen, I was not aware of the process.

Anyway, I have reproduced the issue today again on 88b2, but I failed it to reproduce it with any other file I tried except the only one specific PDF which failed originally. None of other files regardless their type or filename failed.

I took this specific PDF file, tried even to change the PDF extension to .xxx and it fails again. Interestingly enough, despite the .xxx extension, the icon of the attachment is shown still as PDF. Hence I assume the TB looks inside the attachment to see what format it is actually and this probably affects the way how the attachment data is embedded with the message? Possible internal PDF "corruptions" may cause the behavior?

The result is, that the message is actually sent to the recipient (SMTP send OK), but the error appears when TB tries to save the outgoing message to IMAP "Sent" folder on the server. Anyway, the sent message arrives to the recipient with attachment corrupted (truncated from 88kB to about 4,6kB) so there is possibly some problem already on message composition (attachment embedding) stage.

Can you test again with 88.0b3? You should be able to Help > About Thunderbird > and get the update. Otherwise get it from thunderbird.net.

I did re-test with 88b3 and the faulty behavior still presist.

Flags: needinfo?(msajner)

(In reply to Marek Sajner from comment #26)

(In reply to Arthur K. [He/Him/His] from comment #25)

(In reply to Marek Sajner from comment #24)

I am sorry for spontaneous reopen, I was not aware of the process.

Anyway, I have reproduced the issue today again on 88b2, but I failed it to reproduce it with any other file I tried except the only one specific PDF which failed originally. None of other files regardless their type or filename failed.

I took this specific PDF file, tried even to change the PDF extension to .xxx and it fails again. Interestingly enough, despite the .xxx extension, the icon of the attachment is shown still as PDF. Hence I assume the TB looks inside the attachment to see what format it is actually and this probably affects the way how the attachment data is embedded with the message? Possible internal PDF "corruptions" may cause the behavior?

The result is, that the message is actually sent to the recipient (SMTP send OK), but the error appears when TB tries to save the outgoing message to IMAP "Sent" folder on the server. Anyway, the sent message arrives to the recipient with attachment corrupted (truncated from 88kB to about 4,6kB) so there is possibly some problem already on message composition (attachment embedding) stage.

Can you test again with 88.0b3? You should be able to Help > About Thunderbird > and get the update. Otherwise get it from thunderbird.net.

I did re-test with 88b3 and the faulty behavior still presist.

Could be something with the file. Is the PDF something you can attach here if it's not a privacy matter? Or perhaps you can email to me and I can test here at my work PC and try and repro? It seems aside from this specific PDF it's working.

(In reply to Arthur K. [He/Him/His] from comment #27)

(In reply to Marek Sajner from comment #26)

(In reply to Arthur K. [He/Him/His] from comment #25)

(In reply to Marek Sajner from comment #24)

I am sorry for spontaneous reopen, I was not aware of the process.

Anyway, I have reproduced the issue today again on 88b2, but I failed it to reproduce it with any other file I tried except the only one specific PDF which failed originally. None of other files regardless their type or filename failed.

I took this specific PDF file, tried even to change the PDF extension to .xxx and it fails again. Interestingly enough, despite the .xxx extension, the icon of the attachment is shown still as PDF. Hence I assume the TB looks inside the attachment to see what format it is actually and this probably affects the way how the attachment data is embedded with the message? Possible internal PDF "corruptions" may cause the behavior?

The result is, that the message is actually sent to the recipient (SMTP send OK), but the error appears when TB tries to save the outgoing message to IMAP "Sent" folder on the server. Anyway, the sent message arrives to the recipient with attachment corrupted (truncated from 88kB to about 4,6kB) so there is possibly some problem already on message composition (attachment embedding) stage.

Can you test again with 88.0b3? You should be able to Help > About Thunderbird > and get the update. Otherwise get it from thunderbird.net.

I did re-test with 88b3 and the faulty behavior still presist.

Could be something with the file. Is the PDF something you can attach here if it's not a privacy matter? Or perhaps you can email to me and I can test here at my work PC and try and repro? It seems aside from this specific PDF it's working.

The PDF is rather confidential content. It is system generated PDF invoice from accounting software, it is perfectly readable by all PDF readers and browser plugins... as header of the file states it's PDF 1.7 version document. Anyway I would expect the attachment is dragged and dropped to the new message widow as a raw block of binary data without further analysis/modification/conversion by TB?

Anybody but the reporter using a Dovecot server?
From comment 20

I am getting this Dovecot error:

Disconnected in APPEND (1 msgs, 20 secs, 10388/93808 bytes) in=10550 out=1109 deleted=0 expunged=0 trashed=0 hdr_count=0 hdr_bytes=0 body_count=0 body_bytes=0

(In reply to Marek Sajner from comment #28)

(In reply to Arthur K. [He/Him/His] from comment #27)

(In reply to Marek Sajner from comment #26)

(In reply to Arthur K. [He/Him/His] from comment #25)

(In reply to Marek Sajner from comment #24)

I am sorry for spontaneous reopen, I was not aware of the process.

Anyway, I have reproduced the issue today again on 88b2, but I failed it to reproduce it with any other file I tried except the only one specific PDF which failed originally. None of other files regardless their type or filename failed.

I took this specific PDF file, tried even to change the PDF extension to .xxx and it fails again. Interestingly enough, despite the .xxx extension, the icon of the attachment is shown still as PDF. Hence I assume the TB looks inside the attachment to see what format it is actually and this probably affects the way how the attachment data is embedded with the message? Possible internal PDF "corruptions" may cause the behavior?

The result is, that the message is actually sent to the recipient (SMTP send OK), but the error appears when TB tries to save the outgoing message to IMAP "Sent" folder on the server. Anyway, the sent message arrives to the recipient with attachment corrupted (truncated from 88kB to about 4,6kB) so there is possibly some problem already on message composition (attachment embedding) stage.

Can you test again with 88.0b3? You should be able to Help > About Thunderbird > and get the update. Otherwise get it from thunderbird.net.

I did re-test with 88b3 and the faulty behavior still presist.

Could be something with the file. Is the PDF something you can attach here if it's not a privacy matter? Or perhaps you can email to me and I can test here at my work PC and try and repro? It seems aside from this specific PDF it's working.

The PDF is rather confidential content. It is system generated PDF invoice from accounting software, it is perfectly readable by all PDF readers and browser plugins... as header of the file states it's PDF 1.7 version document. Anyway I would expect the attachment is dragged and dropped to the new message widow as a raw block of binary data without further analysis/modification/conversion by TB?

Ok, just checking.

How about this: With TB running, do a

  1. Prepare the situation where you can repro the issue but don't yet drag the PDF file to the new message
  2. CTRL-SHIT-J to open error console
  3. Click the trash can icon up on top-left to clear the error console screen
  4. Try to now repro the issue
  5. If it fails, go to error console and see if there's anything there

(In reply to Arthur K. [He/Him/His] from comment #30)

(In reply to Marek Sajner from comment #28)

(In reply to Arthur K. [He/Him/His] from comment #27)

(In reply to Marek Sajner from comment #26)

(In reply to Arthur K. [He/Him/His] from comment #25)

(In reply to Marek Sajner from comment #24)

I am sorry for spontaneous reopen, I was not aware of the process.

Anyway, I have reproduced the issue today again on 88b2, but I failed it to reproduce it with any other file I tried except the only one specific PDF which failed originally. None of other files regardless their type or filename failed.

I took this specific PDF file, tried even to change the PDF extension to .xxx and it fails again. Interestingly enough, despite the .xxx extension, the icon of the attachment is shown still as PDF. Hence I assume the TB looks inside the attachment to see what format it is actually and this probably affects the way how the attachment data is embedded with the message? Possible internal PDF "corruptions" may cause the behavior?

The result is, that the message is actually sent to the recipient (SMTP send OK), but the error appears when TB tries to save the outgoing message to IMAP "Sent" folder on the server. Anyway, the sent message arrives to the recipient with attachment corrupted (truncated from 88kB to about 4,6kB) so there is possibly some problem already on message composition (attachment embedding) stage.

Can you test again with 88.0b3? You should be able to Help > About Thunderbird > and get the update. Otherwise get it from thunderbird.net.

I did re-test with 88b3 and the faulty behavior still presist.

Could be something with the file. Is the PDF something you can attach here if it's not a privacy matter? Or perhaps you can email to me and I can test here at my work PC and try and repro? It seems aside from this specific PDF it's working.

The PDF is rather confidential content. It is system generated PDF invoice from accounting software, it is perfectly readable by all PDF readers and browser plugins... as header of the file states it's PDF 1.7 version document. Anyway I would expect the attachment is dragged and dropped to the new message widow as a raw block of binary data without further analysis/modification/conversion by TB?

Ok, just checking.

How about this: With TB running, do a

  1. Prepare the situation where you can repro the issue but don't yet drag the PDF file to the new message
  2. CTRL-SHIT-J to open error console
  3. Click the trash can icon up on top-left to clear the error console screen
  4. Try to now repro the issue
  5. If it fails, go to error console and see if there's anything there

When dropped the attachment and then sent the message, I go only those messages in error console:

Prompter: internal dialogs not available in this context. Falling back to window prompt. Prompter.jsm:1033
set modalType resource://gre/modules/Prompter.jsm:1033
ModalPrompter resource://gre/modules/Prompter.jsm:989
getPrompt resource://gre/modules/Prompter.jsm:65
CompleteGenericSendMessage chrome://messenger/content/messengercompose/MsgComposeCommands.js:4827
GenericSendMessage chrome://messenger/content/messengercompose/MsgComposeCommands.js:4763
SendMessage chrome://messenger/content/messengercompose/MsgComposeCommands.js:5027
doCommand chrome://messenger/content/messengercompose/MsgComposeCommands.js:992
doCommand chrome://messenger/content/messengercompose/MsgComposeCommands.js:1188
goDoCommand chrome://global/content/globalOverlay.js:101
oncommand chrome://messenger/content/messengercompose/messengercompose.xhtml:1
Prompter: internal dialogs not available in this context. Falling back to window prompt. Prompter.jsm:1033
set modalType resource://gre/modules/Prompter.jsm:1033
ModalPrompter resource://gre/modules/Prompter.jsm:989
getPrompt resource://gre/modules/Prompter.jsm:65
getDefaultPrompt resource:///modules/MessageSend.jsm:300
notifyListenerOnStopCopy resource:///modules/MessageSend.jsm:439

Not sure if it's really related...?

(In reply to Marek Sajner from comment #31)

Not sure if it's really related...?

Maybe. Maybe not. At least documenting any errors thrown might be useful. Thanks for this.

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

Attachment

General

Created:
Updated:
Size: