524874 - Attaching Windows shortcuts (.lnk files) *via drag and drop* lies about file size and type and creates useless attachments (original file with .lnk extension)

Status: NEW

(Thunderbird :: Message Compose Window, defect)

Description

[Syysk]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; ja; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; ja; rv:1.8.0.5) Gecko/20060719 Thunderbird/1.5.0.5 Mnenhy/0.7.4.0 - Build ID: 20091027032153

Thunderbird 3 beta～trunk Windows Shortcuts (.lnk) into the attachment and send not working 

I test Windows XP SP3 and Windows Vista SP2

Thunderbird 2 is working
Mozilla/5.0 (Windows; U; Windows NT 5.0; ja; rv:1.8.0.5) Gecko/20060719 Thunderbird/1.5.0.5 Mnenhy/0.7.4.0 - Build ID: 2009081210

file.lnk send It is executable as file.lnk

Thunderbird 3 is not working
Mozilla/5.0 (Windows; U; Windows NT 5.0; ja; rv:1.8.0.5) Gecko/20060719 Thunderbird/1.5.0.5 Mnenhy/0.7.4.0 - Build ID: 20091027032153

file.lnk send It is not executable as file.lnk
file.lnk is breaks

Reproducible: Always

Steps to Reproduce:
1.Desktop file make shortcut
2.Attach file and send
Actual Results:  
Recive file not working

Expected Results:  
Recive file working

Comment 1

[Ludovic Hirlimann [:Usul]]

Syysk-san any error message in Tools -> Error console when you try to do this ?

Comment 2

[Syysk]

The error is not displayed at Mail Sending. 

I understand
Thunderbird 3.0 sends substance. 

Make textfile 10kb
aaa.txt (10kb) make shortcut aaa.txt.lnk (1kb)

Thunderbird 2.0
before:aaa.txt.lnk (1kb) after:aaa.txt.lnk (1kb)

aaa.txt.lnk click open aaa.txt

Thunderbird 3.0 (trunk)
before:aaa.txt.lnk (1kb) after:aaa.txt.lnk (10kb)

aaa.txt.lnk click open error
aaa.txt.lnk change aaa.txt open normaly

Comment 3

[[:Aureliano Buendía]]

It seems to work here

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5pre) Gecko/20091028
Lightning/1.0pre Shredder/3.0pre ID:20091028031844

Only issue is this: attaching file via drag and drop and send it TB store also
*.lnk extension (that is invalid). Using button "attach" on compose window, the
file foo.txt.lnk is attached as foo.txt (this is right).

Anyway when mail with foo.txt.lnk arrive if you save file as foo.txt it work.

The issue, for me, is that drag and drop a *.lnk file TB attach it with wrong
extension.

Comment 4

[Wayne Mery (:wsmwk)]

If this is really a regression, at started with a specific version, please change version field to a specific version  (not trunk)

Comment 5

[Syysk]

Thunderbird 2.0.0.23
Mozilla/5.0 (Windows; U; Windows NT 5.0; ja; rv:1.8.0.5) Gecko/20060719 Thunderbird/1.5.0.5 Mnenhy/0.7.4.0 - Build ID: 2009081210

xxx.txt
drag and drop a xxx.lnk is attached as xxx.lnk

Thunderbird 3.0.1
Mozilla/5.0 (Windows; U; Windows NT 5.0; ja; rv:1.8.0.5) Gecko/20060719 Thunderbird/1.5.0.5 Mnenhy/0.7.4.0 - Build ID: 20100111101938

xxx.txt
drag and drop a xxx.lnk is attached as xxx.txt.lnk

Comment 6

[Wayne Mery (:wsmwk)]

Does this still fail?

Comment 7

[Thomas D. (:thomas8)]

(In reply to Wayne Mery (:wsmwk) from comment #6)
> Does this still fail?

Yes, and very cunningly (TB12.0.1 on WinXP)

Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1

STR

1 on desktop, create test.txt, containing text "hello world"
2 on desktop, create test.txt.lnk (right-drag test.txt, create link here)
3a click [Attach] button (or Ctrl+Shift+A) and attach test.txt.lnk (!)
3b then, *drag* text.txt.lnk (!) into composition window
4 send and receive that msg
5 "Save all" attachments (default action)

Actual result

3a non-drag attaching of .lnk file: Link is resolved on the fly, and original file is added:
test.txt (11 bytes)

3b drag-attaching of .lnk file: Link is not immediately resolved, attachment pane UI pretends to add .lnk file and shows size of .lnk file:
test.txt.lnk (468 bytes)

That's wrong and very misleading, especially when the link points to a big file: Attachment UI might show 468 bytes, but we really send the original which might be 10 MB or more. It's also ux-inconsistent as different methods of attaching the same file should not affect the actual attachment in any way.

4 attachments received after sending:
- test.txt (11 bytes)
- test.txt.lnk (11 bytes)
Obviously, the .lnk file contains the original .txt file.
So extension is wrong, leading to problems after step 5.

5 test.txt (ok - the original opens fine)
  ^test.txt[.lnk] (.broken - useless and not actionable for normal user)
The .lnk file (txt file with wrong extension) is very ux-unfriendly:
- is a txt file but acts like a link because of hidden .lnk extension
- from TB download manager, cannot open file
- from TB download manager, cannot open containing directory
- from OS file manager, cannot open file
- from OS file manager, cannot rename file (because .lnk extension is hidden)

Workarounds:

1) From TB message reader, "Save as..." and remove .lnk extension manually before saving
2) From OS, use command prompt to rename file or advanced file managers

Using the workarounds, original file can be recovered and opens correctly.
Workaround 1) is possible for normal users, but not obvious.
Workaround 2) is only for advanced users.

Comment 8

[Thomas D. (:thomas8)]

Arguably, lying about what will be sent and creating useless attachments from normal user interaction is a "major loss of function". It's hard to tell how specific that situation is. It's also breach of privacy because attachment UI claims to send the .lnk only, not the original file itself. Violation of ux-consistency and ux-userfeedback is obvious.

Comment 9

[Thomas D. (:thomas8)]

Expected behaviour:

- regardless of the *method* of attaching a .lnk file (non-drag vs. drag methods), the result should always be the same
- since we convert non-dragged .lnk to original file, we need to do the same for dragged .lnk files: convert to original (linked) file immediately after drag & drop, and update attachment UI accordingly (file size, type, extension)

I wonder what I should do if I actually *want* to send the .lnk shortcut file and *not* the linked original, but that's a different issue and probably more of an expert use case (I guess you have to rename .lnk before sending, or zip it).

Comment 10

[Thomas D. (:thomas8)]

...or should this be in "OS integration" component?

Comment 11

[Thomas D. (:thomas8)]

This bug is a holdover (not exactly a duplicate afaics) of ancient Mailnews Core bug 276869 (7 years old).

Comment 12

[Thomas D. (:thomas8)]

Suyash (or other interested coders), this might be a slightly bigger challenge, but I think can be solved reasonably straightforward like this:
- examine how we handle "normal" case of attaching .lnk files (STR 3a), which works as expected (assuming there's not much point of sending the actual .lnk file pointer instead of the original file pointed).
- hook up into the same functions (or duplicate respective code parts) after .lnk file has been added via drag and drop.

I always assume that as soon as we get hold of the file path (by whichever method of attaching), subsequent handling functions should be the same regardless of the method of attaching.

Comment 13

[Rachel Martin]

https://github.com/Betterbird/thunderbird-patches/blob/d81881df322d7e1fb4434b5dca92cee0d822e315/91/features/09-feature-attach-recent.patch#L148