Closed Bug 176416 Opened 23 years ago Closed 19 years ago

Remote images (referenced as URLs in the message source) always get attached to the message

Categories

(MailNews Core :: Composition, defect)

Product:
MailNews Core
Component:
Composition
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 132257

People

(Reporter: chriz, Assigned: bugzilla)

References

Details

When composing a message which includes an external image, the image is always attached to te message upon sending. Previous builds did not do this; if the image was an external URL, the link was kept intact. Communicator allowed for the NOSAVE parameter in the IMG tag; I couldn't find anything similar in Moz, but up to now I had had no problems. (I frequently send a bulletin which has a logo in the top and a nedstat icon in the bottom. In order to keep the message slim, both images are NOT supposed to be sent along with the message, so each user will download them separately, but now they are getting attached.)
I have couple question? 1)Which build are you using? 2)Which was the last build that wasn't giving you that problem? 3)The url for the image is a file:// or an http:// url? In mozilla, the attribute "moz-do-not-send=true" in the image tag will prevent it to be attached to the message.
Hi Reporter, please have a look to the bug reporting guidelines: http://www.mozilla.org/quality/bug-writing-guidelines.html Please tell us your mozilla-build, steps to reproduce the problem and attatch an example!
*** Bug 187936 has been marked as a duplicate of this bug. ***
Please see the duplicate report which I just entered to reproduce this problem. It should definitely be fixed as it leads to unnecessarily huge HTML emails.
dup of bug 132257?
Bug report 132257 as described refers to network or local links. This bug identifies a similar (same?) problem with remote links (http:// for example). Try inserting the following image into an HTML email using the "add new image" icon: http://www.jynxy.net/temp/29_kita6.gif There is no way to stop Mozilla downloading and attaching the image to your mail rather than leaving it as an external reference. This is a backwards step as compared to Communicator 4.x. May be fixed by the same fix though - would anyone like to comment?
This behavior (always attaching a remote image when it is inserted) can still be reproduced in build 2003010708. However, the solution suggested by Jean-Francois (setting moz-do-not-send=true in the image tag) DOES solve the problem, as it has the same effect as the NOSAVE tag available in Netscape 4.x. The only problem is that this is not intuitive (it involves using the Advaced Edit button in the image tag). A checkbox should be added to the Image dialog box in order to let the user choose wether to attach the file or just leave the reference to the remote URL. As for bug 132257, it seems to me that altough it is a related problem, it originally referred to the "Insert Link" dialog box. Appearently the proposed solution also involves the "Insert Image" dialog, adding the checkbox I mentioned before. Jean-Francois has been working on that report too, so he should decide if it's right to close this report and continue with 132257 only.
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 209173 has been marked as a duplicate of this bug. ***
okay. Firstly, thanks for a workaround. The solution, suggested by Jean-Francois is appropriate for me, but is not very 'logical' isn't it? 2nd; I think I already answered all your additional questions in my post. <1> I use, but that doesn't matter because I have the problem as long as I use Mozilla, the 1.4c - mozilla 1.4 release candidate 1, downloaded Thursday June 12, 2003. <2> I didn't have the problem till the end of the communicator suite (i think it was 4.73, could it be something like that?); and the start of Mozilla & Netscape 6. <3> it is an http:// url of course, otherwise it would be quite logical that the file would be attached.... Think the 'leave image at original location' should only be applicable to ftp:// & http:// prefixes, not with file:/// prefixes. think that is it. I can go on with the moz-do-not-send=true tag, but that I have to write on a poste-it and stick it to my monitor. Think that's not the intention of a mailing program.
*** Bug 226685 has been marked as a duplicate of this bug. ***
*** Bug 208689 has been marked as a duplicate of this bug. ***
In Image properties dialog, there's already the "Don't use alternate text" option, could you add one more option there called "Don't send a copy of the picture, send the reference instead"?
In addition to a "Don't Inline Images" option in each image, it would be really nice to have a "Don't Inline Images" menu checkbox underneath a menu separator at the bottom of Options->Format and a preference that controlled the default behavior in each Account's Composition & Addressing page. Is this done in XUL or C++? I might be able to help out with the coding on this one.. (Perhaps there's a better way to express this behavior than "Don't Inline Images")
In Preferences > Mail & Newsgroups > Composition, maybe an option can be put there too to control the behaviour for all accounts. But the option would be better like "Don't send a copy of an image which starts with http://. (This implies that if the images is from local disks, a copy is sent.)" "Don't inline images" isn't very clear for those who don't understand technical terms like inline.
I don't see the need for more and more options to solve such type of bugs, because it's just a bug: - no other wide spread mail user agent follows behaves like this - increasing the size of the mail message is useless - correct display of inline images by other mail user agents is often very limited or not compatible (Mozilla is a good example where it displays them as attachments and not inline images in many situations, no leading mass mailing system is offering this option) And adding options increases the complexity of the code (and the risk for bugs) and makes Mozilla look more complex, which isn't a way to increase its usage among non technical end users
also extends to http://bugzilla.mozilla.org/show_bug.cgi?id=235704 when it comes to forwarding a pre-existing message
*** Bug 235704 has been marked as a duplicate of this bug. ***
*** Bug 249075 has been marked as a duplicate of this bug. ***
It makes no sense to download an image that's clearly intended to be a link (i.e., it uses img src="http...", then include it as an attachment. Not sure what they were thinking when they added this behavior... Please, please make it so that only images that are clearly intended to be attached (i.e, drag and drop, etc) are attached. I've been looking for HOURS for a workaround for this...
*** Bug 250863 has been marked as a duplicate of this bug. ***
*** Bug 260752 has been marked as a duplicate of this bug. ***
*** Bug 59535 has been marked as a duplicate of this bug. ***
*** Bug 225132 has been marked as a duplicate of this bug. ***
Product: MailNews → Core
Will something ever happen hapen about this one ?
Flags: blocking1.8b2?
Will something ever happen about this one ?
Flags: blocking1.8b2? → blocking1.8b2-
This might possibly be fixed by fixing bug 132257?
*** Bug 314069 has been marked as a duplicate of this bug. ***
Wondering if this will ever get fixed? I recently switched to Thunderbird 1.5 from Outlook Express and am VERY DISAPPOINTED to see that there is not a universal option (as there is Outlook Express) to NOT "Send images with message". It is ludicrous to have to go through each and every image and add moz-do-not-send. There should absolutely be an option so a user can choose whether to send images inline or simply with the URL alone. Until this option is present, I will have to continue to use Outlook Express to send my HTML newsletters... how disappointing... PLEASE FIX THIS!!!
*** Bug 333329 has been marked as a duplicate of this bug. ***
*** Bug 335236 has been marked as a duplicate of this bug. ***
I think that this bug can now be marked as a dupe of the bug 132257. The "local" part of its summary was just a view of the problem, which happens too with remote files.
Would making it a duplicate ease the fix ? That's the only real question. Are we still discussing if this is a bug or a feature ? Or just waiting (4 years !) for a fix to happen ?
*** This bug has been marked as a duplicate of 132257 ***
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
This should be converted to a request for a interface feature. I'd like to see it in the Tools -> Options -> Composition -> General dialog. It could be a checkbox that defaults to true as: [x] Embed images referenced by URL in outgoing email If we un-check it, the image is not sent out embedded in the message, only the URL.
The solution I've discovered is to add the moz-do-not-send attribute tag to each of your images in the original html before you paste it into the new Moz message. Works perfectly. The only thing it doesn't do is include the background image.
Well, if you have read comment #1, you would have to discover all that yourself :p
Sorry, typo error, I meant you *wouldn't* have to discover all that by yourself
If I had found this forum before having to find it out all by myself, then perhaps that would be the case.
Well, this isn't a forum, it's a bug-tracking system; discussion is discouraged, and Teng-Fong should have known better. :) FYI, for background images, I believe you can set moz-do-not-send on the <body> tag. And, per the dupe, with TB 2.0 or SM 1.1, each of the Insert Image and Insert Link dialogs has a checkbox to control this, so it's unnecessary to enter the keyword manually. However, the default is always to attach.
I have never tried to use moz-do-not-send in body element. But assuming this works, it would also be nice to have the corresponding GUI option in body/page properties dialog.
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.