Attachment cannot be dragged from one email message to another
Categories
(Thunderbird :: Message Compose Window, defect)
Tracking
(thunderbird_esr78 unaffected, thunderbird88 fixed)
Tracking | Status | |
---|---|---|
thunderbird_esr78 | --- | unaffected |
thunderbird88 | --- | fixed |
People
(Reporter: msajner, Assigned: aleca)
References
(Regression)
Details
(Keywords: regression)
Attachments
(1 file, 4 obsolete files)
1.91 KB,
patch
|
aleca
:
review+
wsmwk
:
approval-comm-beta+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 2•4 years ago
|
||
(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.
Updated•4 years ago
|
Comment 3•4 years ago
|
||
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.
Comment 4•4 years ago
|
||
This does work ok in 78.8.1 so OP is correct that it did work at some point.
Assignee | ||
Comment 5•4 years ago
|
||
Confirmed, this works in 78 but not in daily or beta.
Regressed by bug 1640760.
I'll take care of it.
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 6•4 years ago
|
||
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.
Assignee | ||
Comment 7•4 years ago
|
||
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.
Assignee | ||
Comment 8•4 years ago
|
||
Tiny comment typo.
Comment 9•4 years ago
|
||
Comment on attachment 9210501 [details] [diff] [review]
1699051-attachments.diff
You meant the patch from bug 1676094 is needed. :-)
Assignee | ||
Comment 10•4 years ago
|
||
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.
Assignee | ||
Comment 11•4 years ago
|
||
Used the correct data type.
Assignee | ||
Comment 12•4 years ago
|
||
Unbitrotted
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 13•4 years ago
|
||
Small comment typo.
Comment 14•4 years ago
|
||
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
Updated•4 years ago
|
Assignee | ||
Comment 16•4 years ago
|
||
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
Comment 17•4 years ago
|
||
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 18•4 years ago
|
||
Comment on attachment 9211060 [details] [diff] [review]
1699051-attachments.diff
[Triage Comment]
Approved for beta
Comment 19•4 years ago
|
||
bugherder uplift |
Thunderbird 88.0b2:
https://hg.mozilla.org/releases/comm-beta/rev/958946bd3688
Reporter | ||
Comment 20•4 years ago
|
||
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?
Assignee | ||
Comment 21•4 years ago
|
||
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.
Comment 22•4 years ago
|
||
WFM as well.
Comment 23•4 years ago
|
||
Walt isn't aware of using any Dovecot server, and can't reproduce the issue using 88.0b3 on Windows 10.
Reporter | ||
Comment 24•4 years ago
|
||
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.
Comment 25•4 years ago
|
||
(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.
Reporter | ||
Comment 26•4 years ago
|
||
(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.
Comment 27•4 years ago
|
||
(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.
Reporter | ||
Comment 28•4 years ago
|
||
(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?
Comment 29•4 years ago
|
||
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
Comment 30•4 years ago
|
||
(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
- Prepare the situation where you can repro the issue but don't yet drag the PDF file to the new message
- CTRL-SHIT-J to open error console
- Click the trash can icon up on top-left to clear the error console screen
- Try to now repro the issue
- If it fails, go to error console and see if there's anything there
Reporter | ||
Comment 31•4 years ago
|
||
(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
- Prepare the situation where you can repro the issue but don't yet drag the PDF file to the new message
- CTRL-SHIT-J to open error console
- Click the trash can icon up on top-left to clear the error console screen
- Try to now repro the issue
- 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...?
Comment 32•4 years ago
|
||
(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.
Description
•