5.20 KB, text/html
28.70 KB, message/rfc822
892 bytes, text/html
13.19 KB, message/rfc822
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.
Attachment #142734 - Attachment mime type: text/html → message/rfc822
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.
(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.
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.
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."
Severity: major → normal
Status: UNCONFIRMED → NEW
Ever confirmed: true
Created attachment 143474 [details] 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.
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
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??
(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).
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.
Is this a regression? This sounds very serious. Is it a security concern? resummarizing (hopefully this is more accurate given what we now know)
Summary: Cut and Paste of TOC from Browser or Composer to Email includes entire Document → links to local files in Email includes entire Document as attachment
resummerizing - this occurs with *any* local file linked to in the e-mail, not just documents.
Summary: links to local files in Email includes entire Document as attachment → links to local files in Email includes entire file as attachment
I can't reproduce this bug. Getting a more recent nightly to give it another try.
(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.
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.
(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.
Created attachment 143860 [details] 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.
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. ....
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.
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?
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.
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
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.
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.
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.
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.
Summary: links to local files in Email includes entire file as attachment → Multiple links-to-anchors in a local file attaches multiple copies of file
Whiteboard: [see comment 27]
(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.
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: esther → composition
Product: Core → MailNews Core
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).
You need to log in before you can comment on or make changes to this bug.