236178 - Multiple links-to-anchors in a local file attaches multiple copies of file

Status: NEW

(MailNews Core :: Composition, defect)

Description

[Robert Shriver Barnes]

User-Agent:       
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113

When copying a Mozilla Composer generated Table of Contents from either Composer
or the Mozilla browser window into an email the entire document is copied into
the email as a mime attachment, once for every item in the TOC.  Namely, if you
have a document with 20 items in it's toc you will end up with an e-mail contain
20 copies of the document as mime attachments.  This can easily cause people to
be sending multi-megabyte e-mails without even realizing it.

This only happens when either the Moz browser or composer is the source of the
copy and paste.  When other browsers are the source, ie, opera, ect... this does
not happen.

Reproducible: Always
Steps to Reproduce:
1. Create an HTML document in Composer with a number of headings.
2. Generate a table of contents via, Insert->Table of Contents
3. Open a new e-mail in moz mail.
4. Highlight and copy (cntrl-c) the TOC you generated.
5. Paste (cntrl-v) the TOC into the email.
6. Send the email to yourself.

Actual Results:  
When you open the e-mail you will see the numbered TOC and the items in the TOC
will be underlined and highlighted as links.  Clicking on the links will cause
the original document to be opened in a new browser window.

Viewing the source of the e-mail will show you that multiple copies of the
original document have been included in the e-mail, once for each item in the
TOC (20 items in TOC gives you 20 mimed copies of the entire document).

Expected Results:  
The TOC in the e-mail, with no copies of the original document.

Comment 1

[Robert Shriver Barnes]

Attachment: The file being cut and pasted from

Comment 2

[Robert Shriver Barnes]

Attachment: The resulting Email

Comment 3

[Mike Cowperthwaite]

I am unable to duplicate this problem, with 1.6 or 1.7a-0301, under Windows 
2000, by loading that test page.

I'm assuming you're composing HTML mail, rather than plain-text.  In that case, 
inserting the copied TOC includes all the links to the document.  The mail you 
attached shows that the pasted links have been converted to have href's to the 
internal parts of the mail; the copies of the document were included to satisfy 
those internal references.  This is very similar to bug 176416.

Comment 4

[Robert Shriver Barnes]

(In reply to comment #3)
> I am unable to duplicate this problem, with 1.6 or 1.7a-0301, under Windows 
> 2000, by loading that test page.

I am composing and sending html.

I decided to try and reconfirm the problem, so I opened the attached html page
in Mozilla browser, highlighted the toc with the mouse, did control-c to copy
and control-v to paste it into an e-mail.  I then sent the e-mail to myself.  It
produced the same result, i.e. it included 5 copies of the original document.

The way we stumbled across this bug was that one of the people in our office
copied a toc into an e-mail and sent it to our manager, who noticed that the
e-mail was 6 megabytes.  Viewing the e-mail only showed the TOC itself, however
looking in the source showed 90 copies of the document, one for each item in the
toc.

Is it possible that there is something that is different in our mail or general
settings which causes us to have the problem and you not?  We have seen this
problem on installs on two different machines.

Comment 5

[Robert Shriver Barnes]

I just figured out why you did not see the bug.  I believe that you opened the
html document directly from the bugzilla website, in a new tab or window,
whereas I am working with a local file.  When I opened the html doc online via
the bugzilla website, and copied the toc, I got absolute links to the document
on the bugzilla website and no copies of the document in the email.

This bug only seems to happen when working with a local file.  Please try
downloading the html doc locally onto your harddrive, and then copy and pasting
the TOC into an e-mail.  You should see the problem at that point.

Comment 6

[Mike Cowperthwaite]

You're quite right; pasting the TOC (as copied from Mozilla) from that *local* 
document into an HTML message does attach a copy of the entire document for each 
link in the TOC.  Reproduced with 1.6 Final and 1.7-0301, Win2K.

Not a major bug, tho.  Yes, the outgoing mail is larger than desired, but you 
can send the mail and get the information where you want it -- there is no "loss 
of function."

Comment 7

[Robert Shriver Barnes]

Attachment: Testing if this is specific to e-mail messages or if happens in Composer as well

I wanted to check if this might be a more general issue so I tried doing the
copy and paste into Composer.  The results are hard links to the file on disk
and not copies of the file like when composing an e-mail.

Comment 8

[Robert Shriver Barnes]

Trying to track this down, I took a comparative look at the data formats being
used on the windows clipboard to see if this info would be of use.

Copy and Paste from Mozilla

Format 1 - CF_TEXT
Format 7 - CF_OEMTEXT
Format 13 - CF_UNICODETEXT
Format 16 - CF_LOCALE
Ole Private Data = 49171
text/_moz_htmlinfo = 49448
text/_moz_htmlcontext = 49447
HTML Format = 49304
text/html = 49393

Copy and Paste from IE
Format 1 - CF_TEXT
Format 7 - CF_OEMTEXT
Format 13 - CF_UNICODETEXT
Format 16 - CF_LOCALE
Ole Private Data = 49171
Rich Text Format = 49232
HTML Format = 49304

Copy and Paste from Opera
Format 1 - CF_TEXT
Format 7 - CF_OEMTEXT
Format 13 - CF_UNICODETEXT
Format 16 - CF_LOCALE

This info so far leads me to look at three files on the assumption that the
issue is with one of the custom mozilla types text/_moz_htmlinfo or
text/_moz_htmlcontext (although I could be wrong here):

content\base\src\nsContentAreaDragDrop.cpp
layout\base\src\nsCopySupport.cpp
editor\libeditor\html\nsHTMLDataTransfer.cpp

Comment 9

[Kathleen :Brade]

cc'ing Daniel since TOC is mentioned but this really sounds like a mail bug to
me (since it sounds like attachments are automatically added).

Seth--does Mail add attachments for each anchor??

Comment 10

[Robert Shriver Barnes]

(In reply to comment #9)
> Seth--does Mail add attachments for each anchor??

This seems to be even more broad.  I created a local html file with a link to
another html file in the same directory.  I then copied and pasted the link into
an e-mail.  The e-mail attached a copy of the externally linked document.  

I also did another test in which I put 4 links to the same external doc.  In
this case it only attached one copy of the external doc.  However, when I
changed three on the links to point to anchors within the external doc I ended
up with 4 copies in the e-mail.  I also tried linking to multiple different
external docs, same thing - a copy of the relavent doc for each link.

It doesn't seems to matter whether the links in the html page are hard or
relative.  

This seems to attach files to satisfy any local links, weather they are to html
docs, txt files or binary files (it also included a wmf file when I linked to it).

Comment 11

[Robert Shriver Barnes]

It doesn't seem to have anything to do with cut and paste.  I created a new
e-mail   and put a link to a local file in it.  That caused the file to be attached.

So basically e-mail is attaching any and all local files which are linked to.

Comment 12

[Kathleen :Brade]

Is this a regression?  This sounds very serious.  Is it a security concern?

resummarizing (hopefully this is more accurate given what we now know)

Comment 13

[Robert Shriver Barnes]

resummerizing - this occurs with *any* local file linked to in the e-mail, not
just documents.

Comment 14

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

I can't reproduce this bug. Getting a more recent nightly to give it another try.

Comment 15

[Robert Shriver Barnes]

(In reply to comment #12)
> Is this a regression?  This sounds very serious.  Is it a security concern?

This is definately a security concern.  One scenario, if someone is sitting and
working on a sensitive internal document in composer and then copies a specific
section of the document into an e-mail to send to someone, the person who it is
being sent to will not only get what they are supposed to see, they will also
get copies of every local file linked to in that section.  

This means you are exposing info to the receiver and the internet which was
never intended to go out.  Let's say the document has a link to my encryption
keys, my bank statement or some such thing - whoops!  This seems *very* serious
to me.

Comment 16

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

I just cannot reproduce this bug at all... I tried a dozen times with various
actions (copy/paste, drag/drop, from browser, from composer). And I am using a
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:) Gecko/20040309

Reporter: can you please try to reproduce the bug with a VERY recent build ?
See http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest/

Thanks.

Comment 17

[Robert Shriver Barnes]

(In reply to comment #16)
> Reporter: can you please try to reproduce the bug with a VERY recent build ?
> See http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest/

I downloaded the nightly from 10/03/04:
    Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040310

and I replicated the bug with this version.  I'll attach the resulting e-mail.

Comment 18

[Robert Shriver Barnes]

Attachment: testing local link in 1.7b 20040310 - includes copy of local file

This e-mail was created in the 1.7b 20040310 nightly by typing the test

Here is a link.

Then highlighting the word link, doing control-L and selecting a file on the
local hard drive.

Comment 19

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

I still can't reproduce the bug... Reporter, can you please give us a **detailed**
process we can follow to reproduce the bug from the very beginning?
Please detail EVERYTHING, if you use the mouse tell it, if you use dnd tell it, all
details are important. Thanks.

Example:

1. launch email
2. open a blank composer window
3. open a new html mail composition window
4. switch to composrr window
5. type in some Ps and H1s
6. ....

Comment 20

[Robert Shriver Barnes]

1. Do cntrl-m to create new e-mail.
2. type in to address, tab down to subject typed in "external link in e-mail
test 1.7b 20040310"
3. tab down to message body type in text: Here is a link.
4. Use arrow and shift to highlight the word link.
5. Do cntrl-l to bring up insert link window.
6. Click on choose file with mouse.
7. Choose a file on the local harddrive and choose "Open".
8. I see a link to the local file in the "Link Location" Dialog:
file:///W:/work/Moz_Bugs/Bug%20236178/temp.html
9. Hit OK.
10. Hit send.
11. Receive e-mail and look at source to verify cntrl-u.

Comment 21

[Jonathan D. Spiliotopoulos]

I'm using Thunderbird 0.6 and when I create a link to a local file using the
Insert - Link menu, the file attaches to the email instead of simply the URL. 

Very strange indeed. Is there a workaround?

Comment 22

[Mike Cowperthwaite]

I had been under the impression that a link to a local file was *supposed* to 
attach the file to the message; note that even tho the link is presented (by 
default) as file://.... (which form of link doesn't work at all in mail), the 
href of the link is cid:...  See bug 113435.

This sort of handling is similar to the issue of <img> tags loading the image 
into the message with src="cid:..."

However, the original report -- conversions to a pasted-in TOC, where the href's 
originally consist solely of "#anchorID" -- seems like incorrect behavior to me.

Comment 23

[Jonathan D. Spiliotopoulos]

Normally I'd agree, however, linking to a resource is not the same thing as
embedding an image into an HTML formatted message. When I create a link, be it
local or external, I expect to be creating a link and not an attachment. If I
want to attach a file I'll click the attach button.

All of my users store their email on the same server. There's no reason for a
single file to be recreated for each of the recipients and compound the disk
usage when a true hyperlink would suffice.

JDS

Comment 24

[Mike Cowperthwaite]

I just tried using the workaround described in bug 176416 -- if you select the 
link text, then Insert|Link, you can go into Advanced Edit and add the attribute
"moz-do-not-send" with the value "true" -- in this case, the file will not be 
included as the attachment, and the href will be maintained in its file: form.  
However, that link won't do anything in Mozilla mail: bug 135830.

While the send-a-file:-link might seem a good solution to people sharing files 
on a LAN, it breaks when the file being referenced is on the sender's local hard 
drive, or if the recipient doesn't have access to the LAN.  Plus, there are some 
security/privacy issues with having file: URLs supported under mail.

As I mentioned in bug 241291, there is a workaround:  If all you want to do is 
send the path to the file (because it's on a shared network drive), then don't 
drag the file in, just send the path.  Yes, you'll have to type it in (or paste 
it, if you've got a way of getting the path into the clipboard).

Better still, set up a web server and provide an http: URL instead.  But there's 
no automatic way to get Mozilla to create such links in response to, say, 
drag-and-drop or Insert|File.

See: bug 241572, bug 241573.

Comment 25

[Mike Cowperthwaite]

Bug 220772 is about the attachment of files where a file: URL was used.  This 
bug should either be duped to that one, or repurposed back to its original 
report about the relative '#anchor' href was converting to a file: URL and then 
being subject to the problem of 220772.

Comment 26

[WADA:World Anti-bad-Duping Agency]

Bug 132257 is also discussing on local file link issue on composing (similar but
not same).

Bug 135830, which is already mentioned by Mike, is opposite problem when
received link only mail to local file from external site. (Bug 233108 also has
relation)
See also Bug 84128 for discussion on file link in mail related issues.

Comment 27

[Mike Cowperthwaite]

As noted in comment 25, the problem which (brade) changed this bug to address -- 
"links to local files in Email includes entire file as attachment" -- already 
exists, altho the suggested dupe has itself been duped to bug 132257 (thanks, 
WADA).

The original report here has separate issues from that.  First, in the 
Mozilla-generated TOC, the original href's include only the anchor IDs:  
"#mozTocId919465" or whatever.  When pasted, that link is expanded to the 
fully-qualified form:
  file:///bla.html#anchor
which results in the symptom from 132257.  Similarly, if the source document is 
remote, the href's are expanded to:  http://site.wherever.tld/bla.html#anchor

Composer will do the same (altho the "fully qualified" link will be a relative 
link if the file has already been saved).  And I don't know what other behavior 
would be acceptable -- just pasting a plain '#anchor' link from another document 
would probably be broken in the new document/message; stripping the link 
information silently would doubtless cause complaints.  See the Composer bug 
239489, which might apply to the mail case as well.

(Incidentally:  Paste Without Formatting will give you the text of the TOC 
without the links.  This achieves the Expected Results of the original report.  
Of course, any other formatting would be lost as well.  You can also select the 
text containing the links and choose Tools|Remove Links.)


The second issue is, I think, the unique and fixable part of this bug: given the 
conversion to the fully-qualified href, it is not reasonable to include multiple 
copies of the same file.  If you compose an HTML message with two links to the 
same local file, only one copy of that file is included, and the links are 
converted to the identical cid: address.  Links to two distinct anchors to the 
same file should behave similarly.

I'm updating this bug's summary to focus on that particular issue.

Comment 28

[Mike Cowperthwaite]

(In reply to comment #27)
> the original href's include only the anchor IDs:  
> "#mozTocId919465" or whatever.  When pasted, that link is expanded to the 
> fully-qualified form:
>   file:///bla.html#anchor

See bug 219675 about the problem of mangling anchor links.

Comment 29

[(not reading, please use [e-mail] instead)]

sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.

Comment 30

[Serge Gautherie (:sgautherie)]

Filter on "Nobody_NScomTLD_20080620"

Comment 31

[rphair]

This bug is still manifest in contemporary software, reproducible in Thunderbird 38.7.2 pasting from version 1.8 of BlueGriffon.  Copying HTML source with 37 anchors into the same document results in 37 copies of the file being attached when the message is sent.

As I understand, the current workaround is to add moz-do-not-send="true" to every anchor composed outside of Thunderbird.  For an e-book or thesis with 200 entries in its table of contents, we'd therefore have to do that 200 times... to say nothing of the many internal links that might be scattered through a document.  Whoever has assigned such a low priority to this bug is not taking into account this use case (specifically: using Thunderbird to send e-book content).