Open Bug 188598 Opened 22 years ago Updated 4 months ago

Shouldn't allow drag and drop of OS folders as attachments until it actually works

Categories

(MailNews Core :: Composition, defect)

defect

Tracking

(Not tracked)

People

(Reporter: stephend, Unassigned)

References

Details

Attachments

(1 file)

Build ID: 2003-01-10-08, Windows 2000.

Summary: Shouldn't allow drag and drop of OS folders into attachments.

Steps to Reproduce:

1.  Open a mail compose window.
2.  With an OS folder that contains attachments (anything, really), drag it from
the OS into the compose attachment area.

Expected Results:

No drop feedback, and releasing the mouse button should not include the folder
into the attachment area.

Actual Results:

What follows is the HTML output:

Index of file:///C:/Documents and Settings/stephend/Desktop/attachments/
Up to higher level directory
company_and_products.jpg 	14 KB 	1/8/2003 	7:00:04 PM
home_igloo.jpg 	15 KB 	1/8/2003 	7:00:00 PM
navwheel.gif 	2 KB 	1/8/2003 	7:00:33 PM
products_scape.jpg 	34 KB 	1/8/2003 	7:00:07 PM

Each attachment is then listed as:

<a href="company_and_products.jpg"><img src="internal-gopher-unknown" alt="File:
"/>company_and_products.jpg</a>

And, clicking on the image's file name yields a JS alert() displaying: 'is not a
 registered protocol'.
Summary: Shouldn't allow drag and drop of OS folders into attachments. → Shouldn't allow drag and drop of OS folders as attachments.
it's really compose, I think attachments is for saving / viewing.
Assignee: mscott → sspitzer
Component: Attachments → Composition
Product: MailNews → Core
The Mac version of this is bug 161745.

Actual results are different with TB 1.5: there is a single attachment:
  Content-Type: application/http-index-format;

Which contains e.g. (folder=Test, contents=NestedClass.cpp):
300: file:///<path>/Test/
200: filename content-length last-modified file-type
201: NestedClass.cpp 1072 Sat,%2010%20Mar%202001%2005:04:38%20GMT FILE 

sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.
Assignee: sspitzer → nobody
Filter on "Nobody_NScomTLD_20080620"
QA Contact: stephend → composition
Product: Core → MailNews Core
On Windows XP I dragged a folder from Explorer to the Attachments area of a compose window (a file was already attached) and sure enough a folder icon shows up as a new attachment.

When I tried to open the attachment (double click) it asks me what to do with it, claiming it is of type application/http-index-format.

If I save it somewhere, it creates a file with a random name which actually has the local file:// URL of the folder in it, similar to the above example. This does not seem useful.

I'm not sure if disabling folders-as-attachments is necessarily the best solution (though certainly better than whatever it is doing now).  Perhaps the user would prefer if it automatically attached a ZIP of the folder, for instance.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4pre) Gecko/20091006 Shredder/3.0pre

This still behaves wrongly as described in comment #2.
OS: Windows 2000 → All
Hardware: x86 → All
Summary: Shouldn't allow drag and drop of OS folders as attachments. → Shouldn't allow drag and drop of OS folders as attachments until it actually works

Any news after 18 years?

(In reply to ale5000 from comment #11)

Ale5000, thank you for the ping and adding the screenshot.
You are right, this should be fixed at least by disabling.
You are most welcome to provide a patch and polish this corner of the product. :-)

In the big scheme of things, it doesn't look like a very serious bug and the general public interest is low.
Nothing serious happens, and it's easy to spot that 20 kb cannot be your entire folder.
We have thousands of other bugs on record, many of them much more pressing than this.
The good news is, after an interim period of challenges, we're hiring and also tackling technical backlogs.

Possible approach of fixing this bug
It seems that the production mode (temporary) URL of the pseudo-folder attachment shows the local folder path right after attaching (I wonder how this behaves upon sending...), and the URL ends with a slash. We could use that to identify this as a folder and block adding such URLs as attachments. If my theory is right, fix might be simple. Finding the right spot in code is much harder. Even the smallest of fixes takes time...

Thanks for the reply.

After sending it is a normal text file without extension.

About security it depends, because if the user select various files and also erroneously include a folder with private files in the selection, it may expose filenames inside that folder that may or may not contain sensite informations.

I'm not expert about this but I think drag 'n' drop contains info about the type of the object dragged and can be detected.

Severity: normal → S3
Duplicate of this bug: 1868337

Here is better if possible:
https://searchfox.org/comm-central/rev/e4cbcd9179fa7ebeed2025eafbd2ec27f8a7d066/mail/components/compose/content/MsgComposeCommands.js#10128
We should hide a drop marker if the drag item is an OS file folder.

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

Attachment

General

Creator:
Created:
Updated:
Size: