Closed Bug 532576 Opened 15 years ago Closed 12 years ago

No way to set moz-do-not-send default value

Categories

(Thunderbird :: Message Compose Window, defect)

x86
Windows Vista
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: lschutte07, Unassigned)

Details

(Keywords: testcase, Whiteboard: [closeme 2012-03-25])

Attachments

(12 files)

User-Agent:       Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; WOW64; Trident/4.0; hc; GTB6.3; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.30729; OfficeLiveConnector.1.3; OfficeLivePatch.0.0; .NET CLR 3.0.30729)
Build Identifier: 2.0.0.23

The current default behavior of Mozilla of not including images by default in composed or forwarded email is EXTREMELY annoying, since it implies the need for a tremendous amount of extra work to compose or forward emails containing images. Since most email in this day and age is multimedia with images, the ability to set a default value of this attribute that matches a user's desires is urgently needed.

Reproducible: Always

Steps to Reproduce:
1. Insert image in am email
2. Send email
3. Image is not included in the sent email
Actual Results:  
Image is not received by email recipient.  Recipient has no way to access the image that was intended to be transmitted by the sender.

Expected Results:  
Images included in email should be transmitted by default, without requiring a lot of extra work to set an "Advanced" option individually for every image.  

If software wants to make image transmission optional, then provide user with a way to control the default value of the attribute moz-do-not-send.

By the way, the format that Mozilla uses to "attach" images to forwarded emails does not work (at all).  Since the attachment is sent as a link of the form xxx@yyy.zzz, other software interprets that link as an email address and opens the compose message window with that as the address of the recipient.
This works perfectly for me with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091130 Thunderbird/3.0. Some filtering might be happening during the transmition.

Could you :

 1) compose an email the way you usually do
 2) send it.
 3) got to your send folder and select that email
 4) save it in .eml format using file -> save
 5) come back on this page and use the adda attachment link
 6) ask the recipient to save the email in .eml and send it to you
 7) come back here and use the same link to attach the email the way it was received on the other end

Thank you
Version: unspecified → 2.0
Problem 2 - Step 1 of test. This is a "Save As" while the test message was  being composed.  The "Save As" appears to cause other problems to occur later. Step 1 "Save As" follows (1) rebooting PC, (2) starting Thunderbird, (3) clicking "Write" button for a new message, and (4) entering some explanatory text and inserting one image with default attribute values (except for attributes like file name that appear in the Insert Image dialog box.
To show you the properties of the first image inserted into the partly composed message.  Snapshot during the insert image dialog.
Snapshot taken during the insert image process for the second image in the test message.
Comment on attachment 416016 [details]
Problem 2: Image2 properties shown to user while inserting

Note that the preview image is accessible in this snapshot.  Image location is invalid after a "Save As" of the message during composition.
Since the second image did not appear in the test message (only a place-holder box appeared), if a user double clicks on the image to return to the image properties, this is what Thunderbird now shows for properties.  Notice that the image locator is invalid, and that the image is no longer accessible for preview.  To see how the message being composed appears to the user at this point, before sending, open the next attachment in Firefox.  I have done that and the reproduction of the message appears correctly there.
This is the test message ready to send. Note that the 1st image appears correctly, and the second image is only a place holder due to the changes that occur for message insertion after a message being composed has been saved in html format.
Notice that neither image is displayed now. The first image is no longer displayed because Thunderbird defaulted the moz-do-not-send attribute to true. While that may be what some users desire, a user should be able to control the default value of that attribute.  For my purposes, I would default it to the opposite value "false" and always send the image if the image is inserted into a message. The second image is not displayed because the src attribute generated by Thunderbird contains errors.  For one thing, no http server exists to serve the image; also, no path to any server is specified.
Notice that the first image appears in the Sent email, but not in the received email.  This is due to the default setting of the moz-do-not-send attribute, which defaults to "true".  Thunderbird then does not include the image in the email, per design.  Notice that the second image does not appear in the Sent email, because of the file location errors generated by Thunderbird. In addition, it's moz-do-not-send attribute defaults to "true", so it will not appear to the recipient.
That's all for the second problem that was discovered while recreating the original problem.  Now I need to reboot and get back to recreating the original problem, so that I can attach those results here a little later tonight.
Conditions for this snap:  (1) PC rebooted, (2) Thunderbird started, (3) Write button clicked to compose message, (4) text entered, (5) image inserted with default attributes (except for image location tab of course), (6) more text inserted, (7) second image inserted with its default value for moz-do-not-send attribute manually changed from true to false, (8) more text added.  This snapshot was taken just before clicking the Send icon.
Note that the first image and any place holder for it has disappeared, due to its default moz-do-not-send setting.  The second image with that attribute manually altered appears correctly to the recipient.
First image with default attribute does not appear here. It is not sent. Second image with altered attribute does appear and was sent.
I believe that this matches the message body from the Sent folder.
For the last paragraph of the original bug report, let me add the explanation that I was talking about the "References" that Thunderbird adds at the beginning of the message following the other message headers.  These appear to be clickable links, but when double clicked are interpreted as email addresses and do not retrieve any attachment or image file.
(In reply to comment #6)
> Created an attachment (id=416020) [details]
> Problem 2: Return to the image2 properties after insertion completed
> Since the second image did not appear in the test message (only a place-holder
> box appeared), if a user double clicks on the image to return to the image
> properties, this is what Thunderbird now shows for properties.  Notice that the
> image locator is invalid, and that the image is no longer accessible for
> preview.  To see how the message being composed appears to the user at this
> point, before sending, open the next attachment in Firefox.  I have done that
> and the reproduction of the message appears correctly there.
 The word "correctly" in the last line means that the message image as shown by Firefox from the html file matches exactly what the user sees in Thunderbird while composing the message; it does ~~not~~ mean that the message appears as it should appear to the user at this point.  In particular, one of the images is not appearing as it should appear.
Keywords: testcase
can you reproduce this on current version ??
Whiteboard: [closeme 2012-03-25]
Yes, I can reproduce it in 10.0.2.  After inserting an image (photo or graphic) into an email, the Advanced button "Do not Send" attribute defaults to ~~true~~ for the image, and so the image is not sent in the email.  In order to send the image successfully, in the image dialog it is neccessary to click the Advanced button and manually change the Do Not Send attribute to false.  That is a Royal Pain in the Butt to do for every image you ever place into an email, since the process must be repeated per image.
P.S. When I repeated the process a second time in 10.0.2, Mozilla remembered my previous setting for the Alternate Text and for the Do-Not-Send attribute.  To see if this persists, I closed Mozilla and reopened it.  

This time, when inserting an image, the Do-Not-Send attribute did not appear at all under the HTML attributes, and was not in the attributes drop-down list either.  However, unchecking the checkbox for Attach Image to Message brought the Do-Not-Send attribute back into the HTML tab attibute list with a value of true.  Checking the Attach Image to Message checkbox caused the HTML Do-Not-Send attribute to change to false.  So now the attribute is tied to the Attach to Message check box, which is reasonable.

We might quibble a bit about the text beside the Attach Image to Message checkbox, which I consider to be unclearly stated.  For example, I do not want to send the image as an attachment -- I want to send it embedded in the message -- therefore I might be tempted to uncheck the Attach Image to Message box, since I do not want an attachment.  I think clearer wording would be something like "Include Image in Message", since that is what the check box really seems to control.

In summary, I would say that the new behavior of the Image Properties Dialog fixes the original problem -- now the default is to include the inserted image in the sent message.  There is still no way for the user to determine which of the two actions "Attach" or "Don't Attach" that the user would prefer as the default when an image is inserted. (Or if there is such a default option, I have not found it [I have not gone looking either]).  Thank you for making the Image Properties default work as one would expect (except for the clarity of the Attach Image to Message checkbox text, which awaits clarification).
(In reply to Larry Schutte from comment #20)
> In summary, I would say that the new behavior of the Image Properties Dialog
> fixes the original problem -- now the default is to include the inserted
> image in the sent message.

I'm going to say that this qualifies the bug as "fixed"...
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: