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)

x86
Windows 98
enhancement

Tracking

(Not tracked)

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
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
*** Bug 328269 has been marked as a duplicate of this bug. ***
QA Contact: composition
Product: Core → MailNews Core
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
No longer depends on: 524874
Depends on: 524874
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.