Open
Bug 276869
Opened 20 years ago
Updated 2 years ago
Dragging Windows shortcut [file.lnk] into the attachment panel should add the file, not the link
Categories
(MailNews Core :: Composition, enhancement)
Tracking
(Not tracked)
NEW
People
(Reporter: christian, Unassigned)
References
(Depends on 1 open bug)
Details
When opening the "Documents" folder in Win 9x's start menu and dragging one of
the links to the recently opened files there into the attachment pane of
Mozilla's mail compose window adds the link (shortcut) to the mail attachments.
With the mail application of Netscape Communciator 4.x, the file itself was
added (which is a very practical thing to do since most of the times you send
mail attachments that you accessed just a short while ago).
I haven't checked if this is true with Windows 2000/XP/2003 as well (the Start
menu folder name is different there, e.g. Recent Documents), but I am quite sure
so.
Note: This "bug" is about shortcuts not being resolved in mail attachments.
Using the "Documents" Start menu entry is just a common way to encounter this bug.
To reproduce:
1) Open a new mail compose window
2) Click Start->Documents
3) Drag one of the entries (e.g. "mydoc.txt") into the attachment pane of the
new mail compose window
Expected result:
mydoc.txt apprears in the attachment pane of the new mail compose window
Actual result:
"mydoc.txt.lnk" appears in the attachment pane of the new mail compose window
Updated•19 years ago
|
Assignee: composer → nobody
Component: Composer → MailNews: Composition
Product: Mozilla Application Suite → Core
Summary: Dragging shortcuts (e.g. from "Documents") into the attachment pane should add the file, not the link → Dragging Windows shortcut [file.lnk] into the attachment panel should add the file, not the link
Comment 1•19 years ago
|
||
*** Bug 328269 has been marked as a duplicate of this bug. ***
Updated•16 years ago
|
QA Contact: composition
Assignee | ||
Updated•16 years ago
|
Product: Core → MailNews Core
Comment 2•12 years ago
|
||
In Thunderbird (as requested by this bug) we ultimately *do* add the original file when file.lnk is dragged into attachment pane, but we don't update attachment UI accordingly (file size, name, type) and we forget to remove the .lnk extension (or use the original file name anyway), which creates a useless attachment that cannot easily be opened by recipient without extra steps and extra knowledge (TB Bug 524874).
Bug 524874 is *not* a duplicate of this bug, because most of this bug 276869 is already implemented in TB.
Depends on: 524874
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•