From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.12-20 i686; en-US; m18) Gecko/20001203 BuildID: 2000120306 The form data should be mailed, instead a new mail message window pops up with nothing filled out except the to part. Reproducible: Always Steps to Reproduce: 1.goto page with <form action=mailto:user@company.com> 2.hit submit 3.the new mail message window pops up (should just mail the form data) Actual Results: new mail message window pops up Expected Results: the form data should be mailed automatically

reporter, can you please include a testcase or point to a URL where this can be tested. thanks.

See above testcase, 4.x warns about security concerns then submits an email quietly, while Mozilla 2000121908 just brings up an empty, addressed email window.

NS 4.x does this fine. Mozilla fails to deal. Status -> new. os -> all, since this should be xp.

reassigning

22159 the same as 61893 How about hosting a simple cgi on your server as a workaround?

tomcap: there are sites where you can't use cgis or webmasters don't want you to use cgi scripts (mainly IIS systems...) And the problem is that this is no web page bug, this is a Mozilla bug, afaik the specs say that this should be possible!

Hey Gagan - what do you think of this one? :) I think this might take at least a little bit of work on the netlib side too? I'll look in to what 4.x sends so we have something to work with... Reducing priority since this seems like a pretty uncommon thing...

Before submitting the form, I get this in 4.x: The form is being submitted via e-mail. Submitting the form via e-mail will reveal your e-mail address to the recipient, and will send the form data without encrypting it for privacy. You may not want to submit sensitive or private information via this form. You may continue or cancel this submission. [OK] [CANCEL] I could not submit the form succesfully, however, as Nav 4.x kept complaining about "Out of Memory" (plenty of memory free).

For me, it seems that 4.x is simply sending an e-mail with your account from mailnews (which is always included in 4.x anyway) with the form data. (format: name=value - new line for every pair, subject is some default value but action="mailto:example@something.org?subject=anything" can set different subject) I think we could get some problems here because 1) users can use the product without having mailnews installed 2) they can have multiple accounts, and we may not know which address/server pair we should use for sending this mail. I want this to be solved because I currently have to use this thing on pages lying on an IIS server - but I understand it may be more difficult here... Just two ideas for a possible solution: a) we could do a pref panel for the users to select an address and a server to send the message to b) we could ask the user for this information in the popup pollman mentioned in his last comment, showing a pulldown menu if the user has accounts in an existing mailnews installation, showing a textfield if not (both should remember the user's last choice, of course).

*** Bug 71298 has been marked as a duplicate of this bug. ***

*** Bug 22153 has been marked as a duplicate of this bug. ***

OK, i don't think multiple email accounts pose a problem for this bug since we do have a "default" mail profile now. And in the case where a person doesn't have a mail program installed whatever happens with a normal mailto: link then should happen here as well. Now the rewrites needed for the netlib i do see as a problem. It would seem acceptable to me to simply pop up a mail window with the necessay data filled in to the body and then let the user hit submit. That way you don't need a special dialog, and (i think) you can use code that's already available.

http://www.ietf.org/rfc/rfc2368 says Thus, a mail client should never send a message based on a mailto URL without first showing the user the full message that will be sent (including all headers that were specified by the mailto URL), fully decoded, and asking the user for approval to send the message as electronic mail. The mail client should also make it clear that the user is about to send an electronic mail message, since the user may not be aware that this is the result of a mailto URL. A mail client should never send anything without complete disclosure to the user of what is will be sent; it should disclose not only the message destination, but also any headers. Unrecognized headers, or headers with values inconsistent with those the mail client would normally send should be especially suspect. MIME headers (MIME- Version, Content-*) are most likely inappropriate, as are those relating to routing (From, Bcc, Apparently-To, etc.) So maybe (as suggested in the previous comment) Mozilla should bring up a Compose window and let the user look at the message before it goes out.

Hmm, so if what that last comment says is what we want/will end up doing, it should be relatively easy to implement IMO (sorry, I can only suppose 'cause I'm no developer): We only have to open up a mailcompose window like we do on a mailto: link, and display the name=value pairs (one per line) in the text field - the user can/must press the "send" button himself then (as that last comment advises us to do). What about this solution?

*** Bug 83156 has been marked as a duplicate of this bug. ***

*** Bug 73397 has been marked as a duplicate of this bug. ***

*** Bug 87964 has been marked as a duplicate of this bug. ***

*** Bug 89994 has been marked as a duplicate of this bug. ***

*** Bug 92396 has been marked as a duplicate of this bug. ***

*** Bug 93069 has been marked as a duplicate of this bug. ***

This is not as uncommon as it seems: it is the poor man's resolution to sending forms. Not everybody has access to cgi... This bug made my little brother mad :-) It worked fine with 4.x, not having this in mozilla breaks compatibility with 4.x

The fact that we do something different from 4.x isn't the compelling argument here, but what we're doing in Mozilla does seem to be broken. We should send the form data, probably with a confirmation, rather than popping up an empty compose window.

Actually, Like I said earlier, and rfc2368 verifies, We should pop up the compose window, but we should FILL it in. That way the user can hit send and realize... "Oh this form is going to send an email!" If we want a dialog in there somewhere, well so be it. I also agree that this is the poor man's form. I remember using it many a time back in the day. (geez. I sound old) I still recommend it for people who have personal sites where the ISP won't allow them access to CGI. I would argue that this is much more serious than "minor". We lose major functionality here, and there is no workaround. (Unless you View source, find the email address, copy each form element to an email, send to the address.) And what is worse, there is no way to get the data to where it is suppossed to go. Is that Dataloss?? Marking normal since there is no workaround, if anyone disagrees, please post it. Also, since we have a bunch of duplicates marking mostfreq.

The mailto: action for a form is something Netscape invented and popularized starting in version 2.0 Sending the mail silently in 4.x required the UniversalSendMail privilege, something I don't think anyone will miss. Dumping the form values into a compose window would be fine. Special values were recognized (subject, cc, body, etc) that did the obvious thing, but you'd have to ask some of the mailnews guys what they were.

*** Bug 95796 has been marked as a duplicate of this bug. ***

The comment about this technique being a "poor man's form is true" but we (tentonweb) have several clients that are on hosting services that do not allow CGI unless they upgrade their account. These same clients cannot afford that. I have been trying to ween these folks from m$. Most of their customers use some flavor of ie which works. It does work in NN4.77 and Opera 5.12. I would agree that this bug is major as it does impact their businees and it breaks my heart to suggest ie.

Is this a Future bug? I know quite a few buisiness web sites that still use this action=mailto. Since this is 4xp, the severity is at least Major.

Nominating for 1.0

*** Bug 94892 has been marked as a duplicate of this bug. ***

I will be happy to test as soon as a build is ready.

Reassigning to evaughan.

Mozilla .9.2 has been working very well for me on Linux, and has been compatible with everything important on my site - except my mailto action forms. I CAN use CGI, but mailto action is so much simpler and works with my mail system more simply than a CGI would. Plus mailto actions are compatible with Explorer, Netscape, and Opera. At this stage, Mozilla .9.2 behaves improperly like Konqueror 2.1. I view this bug as high-priority because it's breaking documented functionality depended on by people for years. Waiting for Mozilla 1.0 (when we've already waited for a fix since December (9 months now!) seems too long.

*** Bug 100027 has been marked as a duplicate of this bug. ***

There aren't any comments on this bug since the 17th of Sept. Can QA regess against the Netscape commercial builds and determine if this is still a valid bug? If so, and we can get fixes/reviews in the next day or two, please mark as nsbranch+ which will get this on the PDT radar. Else, mark is as nsbranch-. Also, can someone comment in the bug how serious you think this is? PDT is only accepting "stop ship" bugs such as data loss and loss of major functionality.

Besides what is in this bug already, The only thing to say is that many people use the mailto: action to send forms, and on Mozilla, there is NO way to send those forms. On hosting sites that do not allow access to cgi-bin this is really the only way to send data to an email address. As it stands now, hitting submit opens the mail window. To fix this bug, all that needs to be done is to fill the e-mail message with the data in the form. There already is a way to get data into the composition window, so this would presumably just involve calling that function with the formdata. (This is definately a major loss of function, and I would argue dataloss, because there is no way to get the data to the person in question without reading the HTML source.)

As supremely sucky as it is, this big is obviously not "STOP SHIP" for Netscape because they've been happy enough to ship 6.0 and 6.1 with this broken.

The problem still exists. I have had three clients start using IE and one has stayed with NN4.77. My company deals with many clients who cannot afford to be hosted on sites where access to a cgi-bin is allowed, cannot afford "secure transactions" and such. Unfortunatly, I am not skilled enough to assist with code but am eager to test and help in other ways. I do not like losing clients to m$ windoze and have had to listen to the garbage from the "anti-open source" bacteria about how long this problem has taken to resolve. I also have two clients who want to move completely off windoze because of rising costs and they are very concerned about the latest IIS attacks. I feed their hysteria but how can I move them to a new world if the feature they use to transact business is not working?

dveditz: I would would that Netscape's stop ship criteria become more inclusive with each release. I don't think it's right to argue that because it wasn't stop ship last time, it shouldn't be stop ship this time.

I'm glad that there is more interest being shown for this bug . I personally will not recommend anyone use Mozilla, Netscape6x or Konqueror as their main browser because of this bug. I use this feature at work to gather budget data request and on my personal home page (I cannot recommend a browser that will not work with my home page!). I'm going to re-install Netscape6x just to report this bug directly to Netscape.

Absolutely. In my office, I'm the only one using Mozilla, becuase of this bug. Several of our intranet server depends on this, so I'm forced to open old Netscape at least once per day. I agree that this methids sucks big time, but I can't change it. This bug isn't a stop-ship, it's a stop-use ! Example of a timesheet application, which uses 2 buttons to check your identity by (mis) using your mail-address: (I changed hostnames and email-address ofcourse) 1: button which needs to be clicked to send a cookie together with your email-address (ok, that actually a webbug in your mail !) <form ACTION="mailto:some_ipaddres@some_host.bel.alcatel.be" METHOD="POST"> <input TYPE="HIDDEN" NAME="check" VALUE="0.40813158126547932625" > <i>First</i> <input TYPE="SUBMIT" VALUE="Identify"> yourself </form> 2: button to log into the timesheet application, which uses the cookie sent by the 1st button (mail was saved in some file) <form ACTION="http://some_host.bel.alcatel.be/cgi-bin/cgi-ets/makeTS.pl" METHOD="POST"> <input TYPE="HIDDEN" NAME="check" VALUE="0.40813158126547932625" > <input TYPE="HIDDEN" NAME="action" VALUE="getweek_mail" > and <input TYPE="SUBMIT" VALUE="Confirm"> to continue. </form> 3: the application will now check if the cookie in the last form was also present in the file (sent by the 1st button), so it knows your email-address. The bug is that the 1st button open a mailwindow, but the hidden fields are not present in the mail. I prefer to see the window (not like Netscape 4.7, but that's a bug) with all fields inside, so I can check them. Now, they're empty.

I agree that this needs more attention. Pulling this in for a branch nomination and clearing out the 1.0 milestone, cc'ing jaime

oops its jaimejr... correcting. sorry for the spam.

this is a feature enchancement not a bug. It will not be simple to do this. We are long past the point of taking changes like this. We choose to ship 6.0 and 6.1 without this. Yes it would be great to get this in at some point but we've had other things to work on.

nsbranch- per mscott's comment.

Bummer information from mscott. The Netscape decision to NOT include a feature that works in NN 4.76 with Nav 6.0 and 6.1 is stunning. What about folks who use this technique for business purposes? Is Netscapes position to say "the heck with them"? The Opera folks can get it to work, the NN4.76 folks got it to work, and it works with IE.

I think it should be made clear that this bug is not a "feature request". While the HTML spec says that procedure for non HTTP protocols is "undefined", every other major browser does support the mailto: protocol. This is a 4.x parity bug, and just because Netscape released 6.0 and 6.1 without it doesn't mean it shouldn't be in 6.2 If that was the case, we wouldn't fix any bugs on the excuse "We've always had that bug so its not important" I admit that this bug may take a while to implement. However, that doesn't mean that it should keep being pushed back because "We didn't really need it before." The fact of the matter is that many businesses and multi-user organizations havn't switched over to NS6.x because of the fact that we are still not at feature-completness with NS4.x (We have more in some areas and less in others) Let this slip for this branch, but I'd say It should be one of the first things looked at for the next.

I imagine there was less of a "stunning" decision not to fix this and more it got lost amongst the thousands of other bugs without anyone to champion it. I know I didn't realize it was broken until quite recently, when it suddenly showed up on the mostfreq list (which I credit that to the fact that the product *finally* became usable enough).

This sounds like a good one to talk about tomorrow. Pls bring it to the PDT.

Any update on this? In case it's not obvious from the comments in this bug, this is preventing some companies, including a daily newspaper that I do contract work for, from upgrading. Many intranets use form action=mailto to exchange mail inhouse. This has already been nominated for nsenterprise. Some of the comments we've seen are from: * duped bug 83156 from the US Military (army.mil) * duped bug 87974 and bug 89994 from Intel (intel.com) * Alcatel.be 2001-09-25 03:35 Those are in addition to the many public company websites that rely on this which are shown in the other duped bugs. With a few exceptions, these are business sites, not personal websites!

Sorry, the first intel.com link should have been bug 87964

Sol/Todd - Thought I'd bring you into this one, for your input.

Pls provide an ETA.

what are the chances this is gonna make the 094 branch?

clearing out the PDT field. This bug is nsBranch-.

This should go to the new form owner

Reassigning to Alex

marking nsenterprise-; will be reevaluated for nsenterprise in future release.

So if it's too difficult to fix this bug (yes, it's a bug, not a missing feature!), could you at least pop up a dialog box saying "This feature is not yet implemented, please use Netscape 4.x or Internet Explorer." Right now Mozilla is *losing data* by not making it clear to the user that the form data does not get submitted. Not implementing some stuff is one thing, but losing data is serious!

Also add to the pop up dialog box that Opera will also work correctly. It is only Nav 6.1 (and Mozilla) that do not work although I have not checked Amaya.

Adding dataloss kw, upping severity to Critical.

*** Bug 105907 has been marked as a duplicate of this bug. ***

Loss of this function means I can only use Netscape 4.78.

before I start doing work on this one: does anyone works already on this bug?

To all folks that complained about the lack of functionality: Which browser sends the mail directly? I don't see any difference between IE, NAV and mozilla assuming that the inputs are named correctly: name="cc" name="subject" name="body" .... everything works in the same way: - all browser are poping the mail composing window with the information added in the corresponding fields (spaces replaced by '+' signs). Particulary to the 'stop use' guys: Can IE do better? How do you set it up to send the mail directly? Do I miss something?

The following browsers send the form directly NN 4.78 (shows posted from Mozilla) Opera 5.12 IE 5.5 (shows posted form IE) The following browsers do not send the form but rather open the "compose" a new email box. Mozilla 0.9.5 (Build 2001101117) Nav 6.1 and 6.2 Sun HotJava 3.0 (unsupported Windows version) I have set up a test form and have included your email address in the mailto: Test case : http://www.wddi.org/daveroeser/pizza.html I have been using the textarea box to write "form from whatever browser" in order to keep track of the tests. Feel free to contact me if I can be of any help.

Dave: No matter what form i try to submit: IE pops up the Outlook Express composer window! I tried that also on your page. (BTW: thx for the testcase). Now i need to know a few things: What OS, which IE ver. and what additional Mail clients are you using? Are you using Outlook? I have IE 5.50 on Win 2000 Pro. (No Office or Outlook installed)

Regardless of if any browsers automatically submit the mail, please don't do that here. See comment 14 and comment 24. We should pop the mail window up, but not submit it. The user should be given the chance to accept what is being sent with their name. If we automatically send mails it can be very bad.... <form action="mailto:someofficial@somewhere.gov"> <input type="hidden" name="haha" value="Death Threat">

Alex, I am unfortunatly using WinME with Outlook. All I have done with each browser is set up the mail account and nothing more. The IE browser is 5.5 without any service applied. No other mail clients but soon switching to Pegasus and Win2000 on one box and I guess I ought to hook my Linux box. I will ask a friend of mine to try this with Lookout Express. Let me know if you are getting spammed with the form and I will remove your name from the form. In response to Chris A. (#68) - The NN 4.78, IE 5.5, and Opera 5.12 all pop up a message box asking the user whether or not to send the form and include the users name and such. What would you propose? I have several clients who are hosted on sites that cannot use CGI or server-side processing. These are not personal sites but small businesses. We (I want to be part of the mozilla team) might need to contact many authors of HTML books which advertise this use of form submission.

Just don't send it. Fill out the mail as if they typed out the information by hand in the email, but let the user click send on their mailform. That's what the RFC 2368 recommends. http://www.faqs.org/rfcs/rfc2368.html

The data shouldn't be posted automatically without notice particulary because of hidden fields. An approach would be a choice for the user in the preferences. That cost us the development of 2 dialogs plus the development of different ways to handle the sending (pop up composer vs. direct). Another problem is the lack of standardization. Does anyone know about a IETF or W3C regulatory document that describes the way of coding the values in the body or header of an email message? AFAIK (and already mentioned in the comments) there are the RFC 2368 and the HTML4.0 spec telling us that for URI ('action') different than HTTP, the agent beahviour is undefined. (or any other docs) Now based on NAV's way to post the data (name=value) we could adopte the same scheme, however we must let the door open for a future standardization (i.e. none of the agents handles attachments yet), that would be a future possible source of quirks. Another concern would be encription for sensitive data.

Re encryption: I don't think this should be a concern right now, because no other client (or at least the majority of browsers) will not do encryption. So if I am dealing with sensitive data, I could not use mailto anyway, because this would lock out (or compromise) many people. Re hidden data: There is no point in popping up a composer window for the form data. The main advantage of mailto as opposed to formless email is (assuming here that I cannot, or do not want to get into the trouble of using CGI) that I get the data in a standard format which I can easily process with scripting tools. So we shouldn't invite people to mess with the internal format of the message. Currently Netscape 4.7x (on Linux/Solaris) pops up a message saying "This form is being submitted via e-mail. Submitting the form via e-mail will reveal your e-mail address ... OK -- Cancel". Suggestion: Simply write the form data that's being submitted as part of this warning message. I assume creating a little display box with a scroll bar won't be that big a deal.

Mozilla currently opens a completely empty compose window. We should at least pass the information into the window, so a user can actually send it, right?

"...creating a little display box with a scroll bar won't be that big a deal." Every new feature includes also the efforts of the quality assurance team, not only the development. * * * If we pass the information in the actual composer window, the user can edit it easily (also by mistake) and this is not what the service provider expects to receive. The ideea of presenting the information in a read-only widget with the option of "Don't show this message again!" plus an option in the preferences "warn me if a form attempts to send information using email..." seems resonable to me.

There should not be a pref or checkbox to allow sites to submit mailto forms without the user's permission.

Why can't we use the mail compose window? Surely we can do some JS magic to make the mail body and the To field read-only, and if a subject is provided by the form, that can be read-only as well. This way, users will be able to CC themselves on the mail and have a copy in their 'sent mail'. They can also save the mail as a draft to send later if their mail server is inaccessible at the time the form is submitted, for example. I don't see a need to introduce a new dialog for this.

1. this shouldn't be prefable, the user should always be prompted and able to cancel. 2. i'd like you to leave the To: field editable. what are the cons of popping up a preflighted message composition followed by a movable dialog asking if it's ok to send the email now (explaining the risk). If users choose not to send now, let them manipulate all the fields and even abandon the email. ... i think i'd like the dialog to mention the url of the form that created the window.

I can also live with that, but insist on read-only fileds in order to defend subsequent bugs like: "user shouldn't be able to change fields when submitting mail from forms". Also at least the first To: should be read-only i think. The ideea of having a pref for sending directly is because NAV did it before and there will be some guys in the future that will wish to have exactly that, so we'll have the disscutions again.

Why shoudln't they be able to change the fields of the message if they want to?

Well, if the users changes the body for example, the service provider may be unable to use the posted information (or what's worster, his data on the server may be corrupted). If the to: field is changed, the data will never reach the destination. I think that leaving the way for additional to:'s, cc:'s, bcc:'s etc. free will provide enough liberty. And after all, why trying to get this feature in, while the user is still able to modify/compose the message by hand? Does not make much sense to me. Then I would recommend the service providers to add a simple mailto: link and the body text to be copy/pasted and do not mess around with forms and stuff. (just an oppinion though, no offense meant...)

From comment 78: > The ideea of having a pref for sending directly is because NAV > did it before and there will be some guys in the future that will > wish to have exactly that There will be some guys that want <layer> or the alt tag displayed as a tooltip. Just because NS 4x did it does not mean it was a good idea. There shouldn't be a pref to do this. I personally always hated it when I had mailto forms sent this way, I never knew what was going on. It is a very real security threat, and we should NOT encourage it. From comment 80: > Well, if the users changes the body for example, the service provider > may be unable to use the posted information (or what's worster, his > data on the server may be corrupted). If the user has a server parsing data, then most likely they can use regular HTTP GET/POST in conjunction with a CGI script. The reason people use <form action="mailto:"> is because they DON'T have a server with CGI access, where they CAN'T use POST or GET scripts to parse data. If there are any scripts that are used to parse data, it will probably be VBScript macros in Outlook or mail filters or something along that line. However, I would say that it is safe to allow data to be manipulated by the user without corrupting any server data. If a form is really used that often where someone can't check each mail that gets sent to them before running a parsing script on it, they probably should consider getting a CGI capable server that can handle it anyway. Personally, I am all for allowing full access to the data, and allowing the user to manipulate it in as if they opened up the mail compose window themselves and typed the form stuff in; however if that is decided against, we really don't need any new dialogs. We should use the mail compose window regardless.

For those that cannot live without and are happy with the composer window poping up with prefilled fields, this javascript apporach will help A LOT:-) BTW: this approach is much more flexible than any fixed implementation we would do in the future. PS: don't forget to use GET and not POST and don't

sorry, forgot to say: don't forget to replace white spaces with &nbsp; when building the body text

actually, there is no limitation about how to format the body of the message. everyone is free to chose his prefered format, however there are some agent limitation since IE, NAV, NS6.x act a little bit different. i.e. the latest mozila breaks lines if <br> is used, NS6.2 not - it displays <br> in the message like IE5.5. nav does not support the sample javascript. a little bit of browser sniffing is required though.

removing critical and set target milestone to future since workaround available.

> latest mozila breaks lines if <br> is used Bug 90728, "mailto: link treats body= as HTML"

sorry, my mistake: the <br> issue depends on the message composing settings, so if someone uses the javascript approach to post forms, he/she should consider that both cases are possible.

> removing critical and set target milestone to future > since workaround available. Are you kidding here? I was under the impression that this bug has been marked critical because Mozilla behaves in a way that may indicate to an unsuspecting user that mailto form data has been submitted when in fact it has not. I have already said so in an earlier report, but let me put it more strongly: This is the worst possible failure that a web browser can possibly cause. If it crashes, there is no problem. I start it up again. But here Mozilla does *everything* up to actually sending the data. Even to an advanced user it is not obvious that the empty compose window spells trouble. The only sure way of getting feedback is if the recepient of the mail is nice enough to complain about an empty email message. THIS BEHAVIOR IS NOT ACCEPTABLE! Also, you seem to be advocating replacing one well-understood security vulnerability (namely sending form data by email) with a whole morrass of security issues (Javascript). I as a user feel much more comfortable submitting a form by mail now and then on a site I trust, than to have javascript enabled, which had a horrible history in terms of security, and which I personally do not suffiently understand to make a judgment. Also, this supposed "existing workaround" is bogus, because knowledge about it will propagate only to people who already have been burned (i.e. who have been setting up a mailto form on their site and started recieving empty emails from people who are stupid enough to use the Mozilla browser) and investigate on Bugzilla. At that point the main damage (and we are talking potential real damage here) has already been done. Do please don't sneak out like a weak student unable to face his homework.

Agreed. No-one in the real world is going to investigate and implement a solution based on Alexandru's attachment here, thus it cannot be labelled as a workaround for the product. It is a major loss of function with dataloss (I don't know many people who could possibly realise that the blank message window does NOT contain any form data), and even worse to rely on customers to fill in the form not knowing how the data should be typed in is a serious hazard. Going back to Critical (per guidelines) and resetting Target Milestone: please re-evaluate. Also suggesting that this is an nsCatFood issue.

Just for comparison, IE6 on Win2KPro: 1. Warns that your email address will be sent, and gives [OK][Cancel] on [OK]: 2. Silently creates a blank email in Outlook with the data as an attachment. This is a long list of [key=value&]* 3. Puts the email in the outbox - so it is sent without any further confirmation. The user doesn't neccessarily know that an email was used to send the form, they don't need to (so long as they know about sending their email address). If there is user concern over what data is sent, maybe a button [View form data] should let users see what is about to be sent. If happy they send, if not they cancel and modify their entries. If desired, this could apply to forms not using mailto: as well. I think that allowing users to modify the submitted data (significantly hidden fields) is a bad idea, as it might end up giving webmasters unreliable/corrupt data that fouls up their CGI, etc. I encountered this bug filling in a form at w3.org :-/ I'd be very surprised if they weren't using CGI or similar to process the results. Surely this needs to be fixed before v1.0...

I would just like to add my 2c: I use galeon and thus use Gnome's mailto: URL handler to actually popup a composer window (which in my case is evolution). I would like to see whatever solution to this bug result in the body= part of mailto filled in. Or to put it another way, the URL:- mailto:somebody@somewhere.com?subject=This is a test&body=field1=some text%0D%0Afield2=more text Should be sent to the mailto handler. Then I get to see what mail is being created and can hit submit if it all looks OK.

Spaces aren't legal in URLs; you need to encode them. Thus, the above example should be: mailto:somebody@somewhere.com?subject=This%20is%20a%20test&body=field1=some%20text%0D%0Afield2=more%20text

Actually, I think the equal signs within the body need to be encoded as well, since they're not being used in the reserved meaning with regard to URL parameters (they're parameters within parameters, in the form data within the body).

I was trying to submit a form at tomshardware (http://www.tomshardware.com/site/chaintech_promo.html) and hit this. I was totally shocked when I found I couldn't submit mailto: forms, and that this has been known FOR OVER A YEAR. (In fact, bug 22153 was duped to this one, and it was reported in Dec of '99). I'm even more amazed that the "workaround" is basically "all website owners should change their mailto forms". Whether you like mailto forms or not, we MUST support them. If someone is worried about security, include an alert like IE. If someone wants to edit the submitted form data - fine, let them file a bug on it (I'd suggest not allowing it directly, though the idea of viewing them is good). It's even worse that the user doesn't realize that they don't work unless they get suspicious about the blank data area in the compose window. Alex writes: >And after all, why trying to get this feature in, while the user is still able >to modify/compose the message by hand? Does not make much sense to me. Then I >would recommend the service providers to add a simple mailto: link and the body >text to be copy/pasted and do not mess around with forms and stuff. The user probably shouldn't be able to modify the message (only view it), however I disagree strongly that as a result all people must stop using traditional mailto: forms. Multiple people here have given examples of corporations that will NOT use Mozilla/NS6 until mailto forms are supported, and others have testified that there are many small-time websites without CGI access. You could also argue that the user should not be able to see the form data, since users can't see normal form data that's submitted. Why require the user be able to see/change a hidden field in a mailto form, when they can't see/change a hidden field in a regular form POST? Adding Trudelle (perhaps he can break the year-long logjam over this). I'd make this P1 Critical dogfood 0.9.8. IMHO

Well, the HTML specs say regarding form actions: "This attribute specifies a form processing agent. User agent behavior for a value other than an HTTP URI is undefined." http://www.w3.org/TR/html4/interact/forms.html Therefore, no behavior or lack of same for mailto: actions can actually be regarded as a "bug". The use of "mailto:" as a form action is not the sort of thing that anybody ought to be encouraging when promoting a standards-compliant web.

HTML4.01 indicates the default ctype(mime type) is"application/x-www-form-urlencoded". Don't youjust have to defile how this is handled when theaction is "mailto" and the method is 'post'?

I get a blank compose window when submitting the Tom's Hardware form using IE6/Outlook Express as well, and Opera crashes when I submit it. Am I missing something here? Does this feature work at all in any of the latest browsers? Could someone please post a list of one or more URLs using mailto form actions that are considered 'important' by large numbers of customers or users (anyone's), and that work correctly in popular competitive browsers? nominating for nsbeta1 to get a decision, please try to include Todd and I when triaging this, since it is really a browser issue.

Trudelle, first off, there are many things that MSIE does that it shouldn't do. If IE6 screws this up, it is a bug there too. It appears to me that this is used mostly by corporations on their company intranets (see comment #50). I've worked for the newspaper media for the past few years, and travelled to a few different newspaper offices. Many of them do use <form action="mailto:HRGuy"> for receiving employee feedback. After testing our intranet with Netscape 6, my IT manager had told me to NOT install Netscape 6 on any of the 300 machines in the building until this bug gets fixed. That or the company would have to pay me or someone else to convert the intranet to use CGIs which really is preferable but not worth it to them though because they already use Netscape 4 which works. "Site development is better spent on the corporate sites than on the internal site. We'll just keep our corporate policy to use NS4 internally." Also, I bet some of the free hosting places don't allow CGIs either and this would be an issue for using mozilla on those sites.

This is one of the biggies where the quest for the holy grail of conformance is REDUCING the functionality and commercial usefulness of browsers in general. The large megacorp does not need this feature as they can just throw money at a solution. But the smaller businesses of 25 or less don't have the option of M.I.S. personnel or a dedicated webmaster to keep things like cgi and server side programs maintained. The smaller businesses need cost effective and simple solutions to basic problems like feedback and product info. And the basic spec doesn't prohibit this useful functionality but leave it vague (as it does the rendering of many things). Net 4 and msie 5 had form mailto as useful ties to their mail utility so it is doable. Why not look at providing consumers with what they want and in some cases need first. and then squabble about the w3 definition. Perhaps they may be the ones that are out of step. Or are we wandering away from a client driven market to a government controlled one... scarey i think.

CGI e-mail scripts are a dime a dozen... actually, a dime a dozen would be overpriced, since they're available for free download in many places. It's just a fairly trivial Perl script.

Ah, the ostrich approach ... and an assumption that all page authors have access to server side programming and also a knowledge of perl. try to reference the small business owner. say ten employees and one to handle adverts/promotions/getting new clients and little time to be technophile. And jobbing out the service doesnt work cuz contract workers don't give a damn after they are paid off. so one in business must handle internet responsibilities. Sure this is not environment most techies understand but surely one or two GET IT. There is a need for simple methods for doing things and form submission is one of them. To put it in perspective I do know perl and umpteen other languages and how to do the workaround. My first training was engineering however and there you are taught to listen to the customer. After 25 yrs of teaching i am retired and social commitment is to help small businesses in community to get on line and advertise. but i dont want to have to continue support after basics. these are the targets missed by so many software providers and i suspect even if the progs were there, the learning curve would be too great... What is the hangup with providing a function that is allowed for in specs (just left undefined as how it works) and would be very useful to many. I see vendors shooting themselves in foot here ;-[ ;-[ ;-[

Considering the following points:- 1. The mailto: system is broken, it's insecure, it's not part of the HTML specs and we shouldn't be encouraging broken behaviour on the web. 2. We are (unfortunately) not in the dominant position to be dictating standards for the web - IE is, Mozilla is not. It sucks I know but there isn't anything we can do about it right now. 3. If Mozilla doesn't support something, Mozilla comes across as broken, not the web site using broken methods. Bummer. 4. If Mozilla is broken people won't use it, they will go back to IE (or Netscape 4). Which stops us doing anything about point 2. Big bummer. 5. Supporting mailto: does not mean we break the HTML specs, the HTML specs just say that non URI ACTIONs are not defined. This give us great latitude to support it. So my question is: is Mozilla just trying to be a standards compliant browser (i.e. fulfil the minimum that the HTML specs require) or is it also trying to be the best all-round and most used browser in the world (i.e the *ultimate* standards compliant browser). It is a question of overall goals and, I believe, we need to stop arguing about the why's and wherefore's of the web as a whole and come back to this project: Mozilla and what is best for Mozilla. If the goal is to make Mozilla the best browser, then I believe we need to implement mailto: in some manner and as soon as we can. I'll get off my soapbox now. Damian

The fact that the W3C does not define this is NOT a valid reason for not supporting this. They don't define alot of behaviour that we support, <link rel="shortcut icon"> for one. If the W3C specifically said mailto: URLs in a form action must be ignored, THAT is a valid reason. They don't say that. The fact that CGI scripts are available "a dime a dozen" does not change the fact that many people do not HAVE access to cgi. freeservers or 8m or something like that doesn't allow cgi access, just HTML. Certain domain registrars (DirectNIC for example) allow you to host static HTML pages on their servers for free. But no CGI. Some people would rather not bother with it. These sites are out there. Just because amazon.com can afford a nice web server with CGI enabled, doesn't mean everyone can. "Dime a dozen" scripts do not change the fact that there are many intranet sites that are not on a web server. They just use MS Networking and netbios: \\CompanyIntranet\index.html and have people bookmark that. Corporations (at least the ones I have worked for) will not allow it to be upgraded. It is "just for the employees, don't waste resources on upgrading" Linux installs and converting links to point to a webserver and having the whole building change their bookmarks would be the ideal situation, but for a good deal of companies, this is not going to happen. Employee time is valuable and can be spent doing "better" things. Many tech staffs are overworked as it is and can't handle upgrading. And why should they? "It works in NS4. Why waste time to upgrade to allow our sites to use Mozilla 1.0 of the future when it works just fine in NS4 and IE5 of today?" This bug has enough dupes and votes to warrant fixing it, an engineer has agreed this should be fixed and has accepted the bug, plus there is no VALID reason not to fix it. Valid reasons would be "Fixing this would break our support for foo" or "Foo Spec or Foo RFC specifically says browsers must ignore mailto: in form action" etc. -- none of those reasons pertain here though. Can we stop arguing over whether or not to fix this and just worry about fixing it please?

No, this is not simply a bugfix, it requests a commitment to support a new feature in this browser, something we can't afford to do lightly. Has QA signed up to write a test plan and add this to their testing? Who has committed to fixing the resulting bugs and regressions? Who will document it? Also, implementing this could be a waste of time if MS has dropped support for it in IE 6 and later, as seems to be the case. Has anyone got this to work in IE6? Does anyone seriously think many web sites will continue to use it if it stops working in the dominant browser? Finally, I asked recently for a list of important sites/customers using this, but nobody has listed even one. It is very easy to insist this work be done, and argue for it using vague generalities, but if it is really so important, it should be easy to document exactly why. Otherwise, even if you get it in mozilla, it may not make it into any other distributions.

Yes, I have personnel here that have IE6 and the action="mailto" works for them. I have not recommended either Netscape 6.x or Mozilla for the people in my organization because of this "bug", - and to me it is a bug. I have no access to cgi-bin so must use this function. If the Mozilla development people are not going to fix this then just say so and stop beating around the bush. I really don't care if W3C has endorsed the mailto function or not, we use it, and many others, as evidence by the remarks here, use it. If Mozilla no longer cares what the customer wants then Mozilla, and Netscape will be relegated to ashbin of the Internet. Do what you want but I am tired of waiting for Mozilla to realize the customer is important. Writing to standards for content display is great but to say you will not make the browser compatible with established ways of doing business is unacceptable. The browser should be making it easier for the user to do business the users way, not the browser's. Let's get the focus back on being committed to the customer, not simply to the W3C.

I want to add: my comments, expressed for this bug are mine alone and do not any way reflect the opinion, expressly or implied, of my employers.

Could everyone please stop using all the hyperbole? It doesn't help at all, since we are already spending 100% of our time trying to provide value for users and customers, and simply cannot afford to do everything everyone wants. If you want this work done, please either submit a patch or provide tangible reasons why someone else would want to do it. Having a few people adding long comments to this bug isn't necessarily a compelling reason for Netscape to add or support this feature. Also, could someone please provide the URL to even a single action=mailto form that works with IE6? The ones in this bug don't work for me.

simple html test case, tested on 3 different systems running ie6, ie comes up with 2 warnings but does the job

Netscape's documentation at the following site indicates that theACTION URL in a FORM may be a 'mailto" URL. Now let's fix this paritybug. http://developer.netscape.com/docs/manuals/htmlguid/index.htm?content=tags17.htm

OK, yes. I highly agree that discussion of "why someone should fix this bug" should be taken to the newsgroups if the comments do not help actually get the bug fixed. We all hate the spam, and so I've decided to provide some things that should answer certain developers' questions. 1. a quote from RFC1867 ---------------------- 5.6 Allow form ACTION to be "mailto:" Independent of this proposal, it would be very useful for HTML interpreting user agents to allow a ACTION in a form to be a "mailto:" URL. This seems like a good idea, with or without this proposal. Similarly, the ACTION for a HTML form which is received via mail should probably default to the "reply-to:" of the message. These two proposals would allow HTML forms to be served via HTTP servers but sent back via mail, or, alternatively, allow HTML forms to be sent by mail, filled out by HTML-aware mail recipients, and the results mailed back. -------------------------------------------- 2.About the list of "important sites/customers" using action=mailto in their forms, I think we can list a few right off the bat. -The US Army (as expressed in comment #105) -We can probably assume other sectors of the government as well (Someone from the Fermi National Accelerator is on the CC list? The reporter is from a sector of the Austrailian government) -If we go by the CC list (assuming non-netscape people have a vested interest) we can see Intel and Cisco as well. -Alcatel (from comment #41) -Many free (and many not free) web presence providers do not allow access to CGI, or the CGIs provided are not feature complete (Many do not allow FILE inputs) -- A list of the sites with this problem: Yahoo Geocities (limited form CGIs), Tripod Pages (only sends email to account address), Trentonweb.com (comment #27), -A slew of others I'm not going to rattle off... search for "form action=mailto" if you want to see a bunch of pages using it. 3. We also have the issue of many educational institutions and "HTML Help" pages teaching this method of form submission as a valid and useful technique. From a simple search I found the Universities of Arizona, Exeter, Texas, Aubern, and Emory, About.com, HTMLhelp.com, MSDN, NS DevCenter, Tripod Help, AOL Help, and well, the list is pretty much endless again. 4. And finally, if we're looking at whether this is a "Stop Ship" bug, I'd say that it is 4xp which has been a pretty good determinant of the "feature-completeness" Mozila has been striving for. Also, from my understanding we already have the backend in place for most of this bug. If we follow RFC 2368, all we have to do is open a compose window with the data filled in. Let the user hit submit, and let the user fiddle with whatever they want. If we want to lock down the window, or pop up a dialog, or do anything else, we can open seperate bugs. A minimal fix just involves us doing the same thing we do on a mailto: link. So thats about it. Sorry about the length, but I wanted to make sure I got in everything. I do think that discussion on this bug should be moved to the newsgroups unless it helps the bug get fixed, and as such have added NO SPAM to the whiteboard. I personally would miss this feature if it remained in its broken state... IMHO we should at least prevent the empty mail window from coming up if we aren't going to do a minimal fix.

Okay, how about discussing this on n.p.m.browser? Mike, if you'd care to post your last comment, I'll reply there.

I've started a thread on netscape.public.mozilla.browser entitled "Form 'mailto' action no longer works" as per your request.

setting milestone to 1.1.

Sorry but reassignment of bug unacceptable. Feature that worked in Netscape 4.7* and not in Mozilla is not progress! Defecting to the opposition until this bug fixed.

nominating for nsbeta1

Marking nsbeta1-.

It seems that everytime I develop a site I've got to mess about for ages getting what looked good and worked well in IE to at least look and work passably in NS. I wasn't expecting any problems with a mailto action on a form, knowing it to be a pretty basic HTML standard - so what's the deal? I downloaded NS6.2 just now, and it still isn't fixed, as I'm sure you know. This bug was raised over a year ago - any chance you could make it a little higher priority than it is? Sorry for the rant, but this came at a very bad time.....

Re comment 117: "mailto" actions on forms is not "standard"; in fact, the standards say that the action is undefined for anything other than "http" URLs. In fact, other browsers often have trouble properly handling "mailto" form actions, especially when they're configured to launch an external mail application instead of a built in mail program. Thus, the web authoring newsgroups are full of messages advising web authors to avoid the use of "mailto" forms.

just hit this bug on a site myself... although various arguments about standards have been thrown around, it appears that nobody has yet mentioned yet that although the HTML 4 spec says that the handling for non-HTTP protocols is undefined, the w3c's HTML 3.2 spec does say that mailto: should be handled. http://www.w3.org/TR/REC-html32#form action: This specifies a URL which is either used to post forms via email, e.g. action="mailto:foo@bar.com", or used to invoke a server-side forms handler via HTTP, e.g. action="http://www.acme.com/cgi-bin/register.pl"

*** Bug 134772 has been marked as a duplicate of this bug. ***

My two eurocents about this bug : (a) no, this is not a low priority bug at all from a browser user perspective ! (b) many web sites rely on that (c) many individual web authors use the mailto: form submission because it is far easier than writing a CGI, and many because they just cannot host CGIs... if you block this kind of usage, they will not adopt our product (d) common practice on the web makes it very important (e) we fixed so minor issues in comparison with that between 20001203 (reporting date) and today... Furthermore, not fixing this bug is a very visible problem, that a lot of users and authors will easily discover => bad public image, bad comments. bad, bad

OK, I have gotten most of this done. We are submitting mailto: forms by bringing up the mailnews window and inserting the form data. The only problem is, mailnews is killing the line breaks when we do so. I have fixed one bug related to that in the patch, but it is still happening. This is because the msg composer comes up in HTML mode, not text mode, and inserts the text I give it as though it were HTML. ( http://lxr.mozilla.org/seamonkey/source/editor/composer/src/nsEditorShell.cpp#2172 ) So I need a way to explicitly tell it to open in text mode. The quickest option here is to add another potential parameter on the URL line that can specify that. I do not believe putting <BR>'s into the window would be good, as the window probably *could* come up as text depending on the user's setting and then we'd send completely incorrect data. There is another way of going about this which would be better (which hwaara would like). That is to pass POST data to the composer window. bbaetz tells me that if the channel implements nsIUploadableChannel, then we can pass it that data. This is the approach I will use. The reason this approach will be better is, then POST with text/plain will work when it is sent to the server as well. Uniformity is a wonderful thing. NOTE TO SELF: change \r\n to \n, from the code we have determined we don't need both.

Comment on attachment 21044 [details] Testcase, change the action of the form to a valid target email Testcase is invalid. Does not have enctype="text/plain".

Comment on attachment 62973 [details] simple mailto test with subject, without enctype Again, enctype="text/plain" needed.

Taking.

The fact that Mozilla treats the "body" part of mailto: links as HTML is bug 90728. It's a security bug and a standards-compliance bug, so it would be great if you could fix it instead of working around it.

All known problems worked out. It turns out there is a force-plain-text parameter already in the URI which works beautifully for our purposes. New since last patch: - enctype=text/plain now POSTs to http servers in the same way as IE. (Tested) - we were urlencoding the values sent to mail when it only wants escaping--most noticeable when sending spaces as + instead of %20, they come out as +. - added subject to message same as NS4.x/IE do

So the way mailto submit works with this patch is, when you submit any form with action=mailto:..., method=post and enctype=text/plain, it will pop up a mail/news window to the recipient of the mailto with all the data in the body of the mail. The user must then click Send to send the mail. Implementation Difference 1: IE and NS 4.x do not let the user see the data that is being sent out. See bug 136084 for my solution to this "problem." We should let the user see the data but not edit it. This is too big a task to get done right now, however (IMO). Implementation Difference 2: we don't do text/plain encoding (mailto submission) when method=get and enctype=text/plain. method=get only works with urlencoded, ever. As much as I'd like this not to be the case, since obviously if you went to the trouble to change your enctype you'd like it to be *encoded* in that enctype, the HTML spec explicitly talks about this and thus breaking it should be a separate bug. (I will consider doing it but not without input and discussion.) http://www.w3.org/TR/html401/interact/forms.html#h-17.13.3.4 Everything else seems the same, from testing. And we have text/plain submission to servers now too :) (I have tested this by looking at the data that comes across from IE and Mozilla; aside from the order of the headers--ours is more like the POST data stream--everything is textually the same.) Soliciting r=/sr=, nominating for nsbeta1, and All That Jazz. This seems important enough to me as an end-user that we should get it in to 1.0. And the risk is pretty low; except for the "don't strip newlines in the body param of a mailto URL" fix it explicitly only affects mailto form submissions.

What a pleasure to discuss a so important bug over IRC with John a friday night, european time, and discover a patch ready for review the monday morning when you arrive at the office ! John, you *rule* !

Comment on attachment 78136 [details] [diff] [review] Patch For |escapedBody|, please use a nsXPIDLCString. Other than that, the patch looks great! r=hwaara, FWIW, although I would prefer if you can get someone else to also do a more official r= of this code.

Nice work!! Though I don't like having encoding handler do specialhandling for mailto links. Ideally the mailto url-handler should handle the post-data stream (and if neccesary do the body=... url creation). However i've been told that that is a lot of work, and since this bug would be a real nice to have fixed for 1.0 i think we can live with this "hack". + NS_IMETHOD AcceptsFiles(PRBool* aAcceptsFiles) + { *aAcceptsFiles = PR_FALSE; return NS_OK; } It would be really cool if <input type="file"> added attachements to the mail, but that's defenetly a separate bug. + mBody.Append(aName); + mBody.Append(PRUnichar('=')); + mBody.Append(aValue); + mBody.Append(NS_LITERAL_STRING(CRLF)); I *think* mBody.Append(aName + NS_LITERAL_STRING("=") + aValue + NS_LITERAL_STRING(CRLF)); is potentially faster. + nsresult rv = aURI->GetPath(path); + NS_ENSURE_SUCCESS(rv, rv); + // Chop off old query string (bug 25330, 57333) + // Only do this for GET not POST (bug 41585) + PRInt32 queryStart = path.FindChar('?'); could you QI to nsIURL and use SetQuery instead? + path += NS_LITERAL_CSTRING("?subject=Form%20Post%20From%20Mozilla&" + "force-plain-text=Y&body=") + + NS_ConvertUCS2toUTF8(mBody) + + nsDependentCString(escapedBody); doesn't this append the body twice?? I think you should have some security-person have a look at the "UniversalSendMail" check removal, but they look ok to me since we open the mail-window before sending. The nsSmtpUrl.cpp change is outside my area of expertize, though hwaaras r= might cover that? other then that, r=sicking

Jean-Francois should look at the smtp url change, I think, since it's in his module.

Fixes reviewers' comments, and deals with subject correctly--before we were lopping off everything after the ? in mailto:a@b.com?subject=blah&cc=blah. Now we leave it there and just append to it. We search for a subject first, though, and iff there is no subject we append subject="Form Post Data From Mozilla". It was decided that it was OK to send this in English since it is the server, not the client, that cares most about the language in the subject in this case.

Kaie, could you take a look at this from a security point of view? Since the data will be no different than that sent in a form post, the only issue is that the email will get sent to the server in the From field, which is the same level of problem as a mailto link. The user gets a standard compose window and has to click Send to get the mail sent to the server. He can see all the data, and knows it is a mail. Relevant here is the fact that I'm not checking the pref anymore (which isn't used anywhere else and was sorta broken here). I believe the pref was somewhat useful in NS4.x because that did not let you see the data before you sent it.

1.) Question: We have a scriptable UI. Could a hacker ever find a way using JavaScript, to automatically trigger the send command in the opening message window? 2.) I think the UniversalSendMail privilege is a nice safeguard for security administrators. The idea seems to have been, to forbid usage of that feature at all. I think it does not hurt to leave that option in, does it? 3.) Whenever data is sent over an unsecure channel, people expect a warning to show up (unless they disabled). User's might not be aware of the fact that the data in the email will not be sent securely. Can we assume that people know, that email is insecure? If we can assume that they know, and the trick described in 1.) is not possible, then your approach is sufficient. If we fear, users do not know, or if we fear that trick might be doable, I think we should show a warning to user, before we allow the message window to open. That message would be similar to what is shown, when you submit a form over http, and the user should be allowed to cancel. 4.) If we decide that the additional warning should be shown, then, as a separate issue (in a separate bug), I suggest we should discuss, whether we should even show this warning for simple mailto links, in some scenarios. Imagine a dynamic page, that includes data in a mailto link, that will be sent as a subject. That dynamic data can either be static data, or data a user has previously submitted. Previosuly submitted data is no problem, if the user is surfing over http. The sent data must have gone over http already, and sending it by email does not make it worse. But what if the user is currently surfing over https? The mailto link could contain dynamic data that was submitted over https, and will now be sent in the clear in the email. I'm not sure if we need to protect user's against this risk. 5.) I suggest the subject of the sent message should not be "form post from Mozilla". Either it should dynamically include the name of the application, or it should avoid that name at all.

This patch doesn't open up some kind of security hole that lets hackers use XUL windows, why would you think that? The behaviour is exactly the same as when clicking on a mailto: link, AFAICS, except that this time the user clicks a "Submit" button. Really, I don't think there's anything on that level to worry about here.

> This patch doesn't open up some kind of security hole that lets hackers use XUL > windows, why would you think that? The behaviour is exactly the same as when > clicking on a mailto: link, AFAICS, except that this time the user clicks a > "Submit" button. Really, I don't think there's anything on that level to worry > about here. Fine with me, as I said, if you agree that this is not possible, and that people are aware of the fact that email is insecure, I don't see a need for an additional warning, and in that case, my statements in 3.) and 4.) can be ignored.

here are my observations: - mailto: will work if enctype="text/plain". both IE (on win9x/winME) and NAV will post (NAV will create an attachment) without the enctype attribute. - on win2000 and XP, IE brings up the mail composer window of the chosen mail program and does not fill in the form name=value pairs. the folk that planned to use this feature in the future will have to educate their visitors to jump on mozilla/netscape. I somehow have the feeling that MS didn't wanted to have this feature working on the NT based systems in order not to compromise their often prised security (that should be so much better than on win95/98/me :-). I'm just wondering why is this working on 95/98/me. (MS ways to do things are a mistery). However, although i don't advocate against the feature (but i'm also not a fan of it), I recommend to analyse this commercial aspect while making decisions about the security aspects of the patch. If somehow something happens, it will create a precedence and will make us look bad comparing to IE. if we can live with this then: r= alexsavulov (excluding the nsSmtpUrl.cpp part and security)

>> - on win2000 and XP, IE brings up the mail composer window of the chosen mail program and does not fill in the form name=value pairs << This is not exactly true. I have several users in my group who use the forms I created (all with <form action=mailto enctype=text/plain>), each of these users is on a Win2000 system with either IE5.5 or IE6 and Outlook as a mail program. Each of of them have the exact same experience as users on NT with IE5.5 or IE6 and Outlook, that is to say, the form emails with no problems and no compose window popping up. To say Win2000 and IE brings up a compose window is not always true.

1.) Question: We have a scriptable UI. Could a hacker ever find a way using JavaScript, to automatically trigger the send command in the opening message window? Question for the mailnews guys. This problem exists for the mailto: URL as well (JS could trigger such a URL) and this should not make it any *worse*, however, so I suggest it be dealt with in mailnews if there is a problem. 2.) I think the UniversalSendMail privilege is a nice safeguard for security administrators. The idea seems to have been, to forbid usage of that feature at all. I think it does not hurt to leave that option in, does it? It's an extra pref, and not really useful. It's never done anything useful before and it's only used in forms. If we want to enable it, IMO, we need to enable it for everything. mailto links included. I am willing to put it back in now, but only if there is some strong need for it. We have too many prefs as it is. 3.) Whenever data is sent over an unsecure channel, people expect a warning to show up (unless they disabled). User's might not be aware of the fact that the data in the email will not be sent securely. Can we assume that people know, that email is insecure? If we can assume that they know, and the trick described in 1.) is not possible, then your approach is sufficient. I personally think we can assume they know. If we can't we need to put some warning for mailto: links as well. If this is a problem, again, it is general and has nothing to do with this patch. 4.) If we decide that the additional warning should be shown, then, as a separate issue (in a separate bug), I suggest we should discuss, whether we should even show this warning for simple mailto links, in some scenarios. I do not think it is an issue. People know when they are sending data to someone that that person will get that data. If it is an issue, I believe it will be better handled when we do mailto links. Perhaps as a popup the first time you send mail ("The person you are sending mail to will learn your email.") 5.) I suggest the subject of the sent message should not be "form post from Mozilla". Either it should dynamically include the name of the application, or it should avoid that name at all. Sure, I'll change that before I go to sr. I hear there's a place we can get the browser name. Please note that 4.x said "Form post from Mozilla" too, not that that excuses the behavior.

Mr. John Womack: please tell us what version of Outlook are you using. I tested this with 6 win2000 machines (one of that has Outlook setup) and the result is the same on all: IE pops up a warning dialog and if answered afirmatively is poping up an empty mail composing window where the values are not pasted. Also XP/IE6.0/OE6.0 does the same. So if you could provide us information about: - OS build # and service pack - Outlook version - IE version (complete) and cipher strength (key length) Thanx!

BTW: i appologies, didn't analysed in detail what NAV does when the enctype="text/plain" is not specified. I discovered that there is actually no attachment but the following will be recieved: ..... Content-type: application/x-www-form-urlencoded Content-length: 90 Message-ID: <XXXXXXXXXXX@XXXXX.XXXX.com> cc=cc%40cc.cc&subject=Insert+subject+...&ody=Insert+here+your+text+to+send+...&thesub=Send (mozilla's messenger displays that as an attachment)

1) Other mailto URLs do not incorporate user data that has been entered into a form, so this is a distinct new case. If there were way to exploit this, form submission via mailto would be much more effective at getting the desired information than asking users to send it in an email. I'm sure the security folks won't settle for just a reassurance that this is not possible, or that it is "no worse", but also understand why. 3) There is no expectation that clicking on a mailto link should produce a warning, but many people have an expectation that form data they submit *is* secure, unless they get a warning that it is not, or explicitly prevent such warnings. Very few users know how insecure email is, and nobody is going to know at the time they submit that the form will attempt to send the data by email. Also, the main problem with this method of form submission still exists. Users expect that clicking the submit button will send their data, but in this case it does not. Should they be advised that this is a two-step submission, and that they will need to send the resulting message in order to submit the form? Finally, will any of this work at all if they are using a third-party MUA, and have not installed or configured the mail component? What happens in the embedding case?

1) Sending the form data via mailto is easy with JavaScript and a mailto URL. This is not a new case at all. Just loop over the elements and you have an exact simulation of mailto submission. 2) mailto form submission is *not* easier to exploit than normal form submission; quite the opposite. A user can see *exactly what he is sending* and who he is sending it to with mailto form submission. He does not have that luxury with form submit. Same number of clicks, too (one of which--the Send click--you cannot disable). 3) If security wants to us to pop up *another* dialog to warn the user that the form is being submitted via email, and make the submission a 3-click process instead of 2-click like form submit, we'll do that. 4) I don't think it's too much to ask the user, when presented with a mail window, to realize he needs to click Send to send the mail. I will CC a UI guy or two and ask their opinion. In a conversation timeless seemed to think this method of submission was fine. 5) If and when mailto URLs work with other agents, this will work with other agents. That's an orthogonal problem. Embedding as well. If embedding doesn't have our mail client and mailto URLs are not supported (which I am not going to bother checking because it's irrelevant) the embedded submit will just fail, exactly the way it did before (I have tested this). Nobody's build is going to get any worse because of this. For embedders and people who want to be able to submit mailto forms without email, we can file a different bug to move the smtp protocol implementation to netwerk and use that, if you like--in fact, I think it's a great idea. But that shouldn't hold up this implementation for being in the next version of Netscape.

If submitting a mailto: form produces an "insecure form submission" dialog, it should be the same dialog that appears when submitting a form over http (or very similar). It should only appear if the user has not unchecked "Warn me when I..." in an http-form-submit dialog, and vice versa.

Jesse: that's a good point. If the security guys *do* want that dialog, we can probably do it in the same place we pop up the form sub dialog for http and https POST. We could also include any text the UI guys would want, and the dialog could go away if the user didn't want to see it anymore. I still think it's a completely unnecessary click (normal form sub has 2 clicks in the *worst* case) but we'll see what people say. I have asked a couple of UI guys to comment.

1) The example you cite is fundamentally different, in that clicking a mailto link does not lead the user to think she is submitting a form. 2) I don't know what you are arguing with. I just said that if it was exploitable, it would be more effective than just using a mailto URL. 3) Fine. cc'ing doc so that we can be clear on how this differs from regular form submission. 4) There are already two UI Designers cc'd on this bug. cc'ing UE lead for input on this. 5) Do other MUAs support bodies in the mailto syntax? I worry about adding a feature that may fail in most typical cases. cc marketing for input on whether this is wanted in the next Netscape release.

R=ducarroz for the smtp change.

In answer to Alex Savulov

In answer to Alex Savulov - see response inline >Mr. John Womack: > >please tell us what version of Outlook are you using. I tested this with 6 >win2000 machines (one of that has Outlook setup) and the result is the same on >all: IE pops up a warning dialog and if answered afirmatively is poping up an >empty mail composing window where the values are not pasted. Also >XP/IE6.0/OE6.0 >does the same. So if you could provide us information about: >- OS build # and service pack WINDOWS 2000 - 5.00.2195 SP1 >- Outlook version OUTLOOK 2000 SR-1 (9.0.0.3821) >- IE version (complete) and cipher strength (key length) IE 6.0 2600.0000 cypherkey: 128bit update version:0

Status update: - Code Review: We have code-level r=alexsavulov for form changes. - fabian, sicking and and glazou have *also* looked at it and had their comments addressed. - Mail/News: We have r=ducarroz for mailnews changes. - UI: Lori Kaplan said it sounded fine (email) but passed it Jennifer Glick to look at. - Security: Kai Engert said it all seemed fine (asked on IRC), waiting on Mitch Stoltz to OK.

Jennifer and I have reviewed only the email launching behavior of this bug. It seems like behavior that users will understand and know how to interact with. We didn't look into any potential security risks or the underlying issues that create the situation.

Securitywise, this seems OK to me. I'm not a UI designer, but I think that making the user take a deliberate, well-understood action (like clicking Send in a mail compose window) is much more effective than a dialog, which many users will impatiently ignore. Clicking Send makes the user responsible for the sending. I don't believe this is any less secure than what we have currently - Javascript can already activate a mailto: link to an address of the script's choosing at any time and without user interaction - this is essentially the same thing, and I don't see a security problem as long as the user has to click Send.

I've thought about this a little more, and I've changed my mind. From the user's point of view, submitting a mailto: form is just like submitting a form to a cgi over an unencrypted connection, with one addition: the mail message also reveals the user's mail address. So, for consistency, rather than pop up a mail compose window, we should present a warning that's identical to the usual insecure-form-submit warning, with the addition of something like "Submitting this form will reveal your email address to the recipient." I'm worried that while, as I said above, any user understands the general implications of hitting Send, they may not understand that their data could be observed in transit (something we specifically warn them of when doing other types of form submissions). So I think we should use a deliberate warning rather than a mail compose window. On the other hand, if we present a dialog with a 'don't warn me again' box, and the user clicks the box, from then on any webpage can steal the user's emaila ddress silently just by silently submitting (via JS) a mailto form. That could be very bad. So maybe we need to remove the "don't warn me again" box in the case of mailto forms, or else present both the dialog and the compose window - but that's starting to get hairy from the usability point of view. So I guess I'm a bit torn here about what to do.

In addition, something else comes to my mind. If we do not show a warning first, a user might be really confused, if he/she has never yet used email with Mozilla, submits a form, and sees the wizard to create a new email account.

Mitchell and others See comment #14 for the RFC that says we really should show the message before sending it. In Nav4.x and other browsers, you would get a dialog that would essentially warn you that the form was going to make your email address visible. If we propogate an email message, I think that that should definately be enough of a signal that "This isn't a normal form" I manage a network at my company that is operated by probably the perfect example of "confused end users"... they tend to ignore dialogs they do not understand, but would definately get the idea that submitting this form was "just like sending an email". in fact, they'd just think that the website filled in the email for them automatically. Warning a user that sending an email reveals his or her email address is simply overkill. We don't do that when they send normal emails, and for all intents and purposes, this feature is simply a webpage filling out an email for you. If we go the route of making a dialog, we definately should not have an option to "never show again", because in Nav4 that was what the UniversalSendMail security preference was for. That would definately be a security flaw. Security-wise, I cannnot imagine filling a message compose window to be a vulnerability in any way shape or form... The user must press send, and the user should know the facts behind sending that email.

Silly question: What if the user has the prefs set up to sign/encrypt all mails? Don't we want to avoid signing the mail, since that would presumably upset scripts which parse the results? What did ns4 do?

We need to notify the user that the means of submission is insecure, and we certainly can't send email on the user's behalf, they must execute Send. Typical users may not be aware of the extent to which their email is insecure, it is more like a postcard that is wide open to view, and leaves several copies of itself along the way, any of which could persist for a long time. This is not expected in a form submission. This still needs a QA test plan, including coverage of all of the cases where Mail is not integrated, or not used.

I personally think these warnings people want should be attached to all mailto: links. The "security problems" people are talking about are not new. It is just as insecure when you click a mailto link. The user's email still gets sent. If he doesn't understand it in the case of a form submit, I don't see why he's going to understand it when he clicks a mailto link (for example, with a body in it). And JavaScript *can* be used to simulate a mailto form submission perfectly, in every detail (except that the form submission is not sent to listeners who could pop up a warning dialog). I'm will file a bug on this. Regardless, we're going to make form submission with mailto show a message since people want it there (patch forthcoming when I have a moment). Probably we'll make it such that people in this new bug can piggyback on it. QA test plan is a fine idea. I have already tested with and without mailnews installed. I do not know what other cases exist. Peter, do you know offhand who I need to talk to to get that done?

Problems with JS imitating a form submission are a separate issue, and do belong in a separate bug report. This *is* a form submission, and as a result carries security expectations set by our products for many years. As to the test plan, I would assume that the QA contact for this bug would be a start. Other cases are embedding, and where mail is installed but not used.

*** Bug 145665 has been marked as a duplicate of this bug. ***

*** Bug 147982 has been marked as a duplicate of this bug. ***

Here is The Plan in all its glory, could mailnews guys and UI people please comment? (I am coding this as we speak.) 1. Add a parameter to the mailto: URL format, "form-submission-warning," which acts like "force-plain-text" and indicates to the Compose window that it needs to show a warning. This parameter is necessary to avoid making layout depend on mailnews directly. 2. Add a red label on the Compose window itself just above the message edit box, explaining what is going on and the security risks. This gives people the warning, tells them the instructions of what to do, explains what is going on, *and* solves the problem of Too Many Clicks. timeless came up with the solution and I am quite enamored with it. Comments, UI and mailnews people?

Here is a screenshot of the mail window with the label.

If we ever add the ability to open mailto: links in another application, then I think that we should probably not add that extra part of the URL and open a dialog box instead.

Er, I don't like that big red box at all. No other application does that, it just seems silly to do that.

#167: I think Eudora 5.1 does it too.

I thing showing an alert on top of the compose window would be more elegant, you couls also add a "don't show me again" check box.

Shouldn't that say "eveal your email address" instead of just "reveal your email"

Heh, you post a screenshot and everybody becomes a critic. Perhaps I have not explained the tradeoffs here. I have had some positive responses and some negative, as with any UI change, but I have good reasons for doing it this way and I haven't heard a lot of good reasons for a dialog except netdemon's. - with an alert, it would be three clicks to submit (many people do not turn off dialogs for some Godforsaken reason) which is not the case with any other submit type - the user does not have to do anything with the window but click send, so it doesn't *matter* that we're taking up a teensy bit of space. netdemon: point is very well taken. When we do that we should have a dialog. ducarroz: an alert adds that extra click. Are you sure you want that? I take your suggestions with more weight since you're the email guy. If we have to add a click into the process, I would prefer we add a dialog before mailnews, the way netdemon is suggesting--but I would prefer we don't add the click at all. johnlar: duly noted, good idea. Note to all: if you post a "I don't like this" then please post an alternative with some reasons why it's better if it's not obvious. There are people who like it and people who don't.

It was just a suggestion. My concern is that the big red warning text in the comose window is not very nice and take too much space. Maybe you can change that for a Yellow Warning Triangle (like we use in alert) and a line or 2 of text next too it in normal color! Anyway, jglick is the person who should have the final word on the UI proposal.

That is a good idea (the yellow warning image). I will let jglick comment (I sent her an email this weekend) before I make any other changes.

Whoa there. John, this is a *Navigator bug*, and the UI of Mozilla mail/news is completely off-topic. With respect, jglick, ducarroz, etc shouldn't be involved in this bug at all. Consider: mail/news isn't installed, you have set up Mozilla to handle mailto: bugs using Eudora, and you click on one of these links. What happens? Are you going to try and hack Eudora's UI too? ... Didn't think so. I recommend just creating a composition window (in the user's chosen mailer) with the fields pre-filled. The idea that the user needs any further clue that their e-mail address will be revealed is, quite frankly, daft. If they need an alert to warn them of that here, then they'll need the same alert every time they Reply to a message from an unknown sender in the mailer itself.

After reading this whole bug, I would agree with mpt that this is a decision the nav team should probably make. I will offer my impressions/suggestions though. Some things that I took note of while reading this bug that I thing are very relevant in coming up with a solution (which is illustated in the above attachment): 1. Most users won't know or care that this type of form submission is diffent than any other type of submission. So, yes, we should let them know that this situation is different and insecure, but still attempt to make the experience similar to other form submission. Comment #155 states this very nicely. Opening a Compose window may confuse some users. "I just wanted to submit a form. Why am I getting a mail window?". 2. The data doesn't really need to be editable, in fact, it may cause problems if average users can edit the data. But, some users really want to be able to see what will be submitted and verify it before sending it. 3. No "don't warn me again" checkbox since this is something users should be made aware of each time. Is it possible to show a warning dialog, which explains the potential risks, allows them to Submit or Cancel, and also provides a link to the data that will be sent? The link could open a viewer/nav window (no mail app installed necessary)? (Alternately, the dialog could expand to show a non-editable scrollable text area of the data).

To fulfill the mailto RFC quoted in comment #14 and referred to elsewhere, it would seem to be necessary to present the complete message to the user in the manner in which they are accustomed to sending. I'm not sure that the submit dialog in the previous comment is sufficient to fully inform users, since it doesn't present the message, just offers a link to it. I'm also concerned that many people would just hit the Submit button without reading the rather dense text, and never realize that the web site is sending email in their name. Finally, I don't think Navigator should get into the business of constructing, formatting and displaying rfc822 messages, let alone sending them and dealing with any errors. IMO, to do this right requires notifying the user, then handing off the message to their default MUA, as other folks have pointed out earlier. It will take extra clicks, and introduce more failure points, but that is the tradeoff for having a "poor man's form" rather than no form at all.

You mean just use the form submission warning dialog? Since so many people seem hell-bent on this, I'll go ahead and do it. And it *does* make sense to do it if we ever decide to support other MUAs. Shouldn't be terribly hard either. While jglick's proposal is exactly what I'd *like* to do, there are so many technical hurdles in between us and it that it's really not worth it to do it, especially for mailto form submit.

> ... if we ever decide to support other MUAs Yes, this will happen.

OK, given the recent comments, I'd suggest that Jean-Francois's suggestion of the alert appearing on top of the open Message Compose window might be the best way to go. User gets an alert that explains why Message Compose has opened (with content that may not look familar to them, subject=subject, hi=hival, etc.) and what to do to send or cancel. Doesn't add additional text to the message window that may either not be noticed or has to be sorta scarry looking ;-) to ensure that it is noticed. Yes, its an extra click, but hopefully this situation isn't that common? Thoughts?

I agree with jglick. In addition, it would be nice to have a "don't show this warning again" checkbox. It would also be nice to have UI for toggling the preference.

A popover over the MUA does not fulfill the requirement that we be MUA-agnostic. It can only happen if we have knowledge of when the mail/news window appears. We have an alternative though--we should do what Trudelle proposed. We should use the existing form submission warnings (with text altered, of course). Advantages of that over current proposals: - it is MUA-agnostic - it is familiar to users from other form submissions - it allows the user to specify that she does not want to see the warning again - it is easier for me to do and requires a *lot* fewer new codepaths (we wouldn't even have to touch mailnews) This attachment is a screenshot of the existing warning. The wording would have to change, but all the elements could remain--the checkbox, the OK, the Cancel. This is what I would like to implement today. The text I want to use is the existing warning except modified with some of jglick's ideas (though I will send the text to Jatin for approval, and I may change the existing warnings to use some of this better wording): "This form must be submitted via email. This information, <B>including your email address,</B> will be sent to the recipient without encryption. You may not want to submit sensitive or private information via this form. Are you sure you want me to continue sending this information? (X) Alert me whenever I submit information via email." Please to be commenting. I would like to implement this this afternoon if there are no objections.

> Are you sure you want me to continue sending this information? > > (X) Alert me whenever I submit information via email." "me" / "I" in those two lines is very confusing and IMHO used incorrectly for it doesn't mean the same all the time in that sentences. What about that modification: Are you sure you want to continue sending this information? (X) Alert me whenever information is submitted via email."

it might also be a good idea to notify the user that his/her email program will handle the rest of the submission. This could be accomplished by changing the last line to read: "Are you sure you want to create a new message with this information?" because technically, we are not doing the actual data submission...

Good point Mike. John: I don't think there is any *requirement* that we be MUA-agnostic; smoother integration with our own MUA would be desirable, but simpler/easier implementation is the right choice for now.

I agree the dialog isn't a bad thing since it can be dismissed, but a couple things I want to mention: - The visual flag on the UI of mailnews still, IMHO, should be there. Is there any other way besides URI that this warning information can be transmitted to mailnews? Via an API maybe? If multiple users use the same mail account (such as a father and son), the son might dismiss the message and not tell his father about it. - If someone uses Mailnews and then clicks "Don't show this again", and afterwards switch their default mail handler, should the dialog be shown again?

1.1a is passed. Retarget?

nsbeta1-

I agree with mpt's comment 174 and stand by my comment 146. This feature does not require any new dialogs. Showing the message compose window with the fields pre-filled with the information the user just entered is sufficient explanation of what's going on. Showing the message compose window is also a sufficient warning that the user's e-mail address will be revealed. The existing dialog for insecure form submission works in this case, and it's better to use the same dialog so that the user doesn't have to uncheck "alert me whenever" in two dialogs with the same purpose.

OK, it turns out that reusing the code for the insecure form submit dialog probably works, but requires you to actually have NSS installed. Is this acceptable?

that sounds like a bug, which you don't have to worry about (although you could file it)

Is the same thing true for the (non-mailto) insecure form submit dialog? Does that require NSS/PSM to be installed? If so, then I'm OK with this patch. John and I discussed this and I'm OK with it, securitywise. http://bugzilla.mozilla.org/attachment.cgi?id=78136 is the one we'll be checking in, right?

OK, we're going with the earlier patch because if NSS is installed, it shows the insecure form submit dialog and that's good enough. Status: - Code Review: We have code-level r=alexsavulov for form changes. - fabian, sicking and and glazou have *also* looked at it and had their comments addressed. - Mail/News: We have r=ducarroz for mailnews changes. - UI: Jesse Ruderman wants it to happen this way, and Jennifer Glick says a dialog before the mailnews window comes up sounds fine. - Security: Mitch Stoltz has just given the OK. Now we just need sr=. For the sr, the patch we will be doing is http://bugzilla.mozilla.org/attachment.cgi?id=78136&action=view ("Patch").

Filed bug 154723 on the "NSS required for insecure dialog" thing.

Comment on attachment 78136 [details] [diff] [review] Patch sr=dveditz (and flagging as reviewed)

Comment on attachment 78136 [details] [diff] [review] Patch >+ path += NS_LITERAL_CSTRING("?subject=Form%20Post%20From%20Mozilla&" >+ "force-plain-text=Y&body=") + >+ NS_ConvertUCS2toUTF8(mBody) + >+ nsDependentCString(escapedBody); I do wonder why you're including two copies of the body. Is mBody leftover from an earlier version? Or is it important to include an escaped and non-escaped version of the data for some reason?

Comment on attachment 78225 [details] [diff] [review] Patch v1.1 Ack! You're right, I got my head all backwards. 1.1 is the patch to do. It is in fact the patch that we got r=alexsavulov on for form changes, and the UI approvals and mail approvals did not change between 1.0 and 1.1 (it was all perf changes except the body thing).

Comment on attachment 78225 [details] [diff] [review] Patch v1.1 sr=dveditz

Comment on attachment 78225 [details] [diff] [review] Patch v1.1 a=asa (on behalf of drivers) for checkin to the 1.1 trunk.

Will this patch be landed in 1.0 branch ?

It's in the trunk. Given that 1.0 is already out I would guess this new feature is not going into branch, but that's up to drivers. File bugs on this as new bugs (but check the dependent bugs here first). Make them block this bug if you like. woohoo!

*** Bug 157228 has been marked as a duplicate of this bug. ***

Verifying on build 2002-07-12-08-trunk on win 98 build 2002-07-15-09-trunk on Linux Red Hat

nominating for 1.0.1

This is the newline portion of the patch for branch.

new patch for branch

Comment on attachment 92652 [details] [diff] [review] Branch Mailto: body newline patch transfering r/sr since its part of the original patch.

Sorry but I am not able to receive submitted data from a form using Mozilla 1.1b on MacOS 9.2.2.

Louis we need more info. First, try the testcase http://bugzilla.mozilla.org/attachment.cgi?id=78079&action=view if its not working, please let us know. If it does work, but you have a specific website or html code that is not working, please provide a link or attachment. Thank you.

Your test case works fine!! Here is my HTML code that does not work with Mozilla - but works with Netscape 4.79. <form METHOD=POST ACTION="MAILTO:giannone@ipp-garching.mpg.de"> <table CELLSPACING="10" BORDER="10" WIDTH="400" CELLPADDING="10" HEIGHT="5" ALIGN="CENTER"> <tr> <th>Shot number?</th><td><input TYPE=TEXT NAME="shot" SIZE = 30 ALIGN="LEFT"></td> </tr> <tr> <th>Start time?</th><td><input TYPE=TEXT NAME="tist" SIZE = 30 ALIGN="LEFT"></td> </tr> <tr> <th>Finish time?</th><td><input TYPE=TEXT NAME="tifi" SIZE = 30 ALIGN="LEFT"></td> </tr> <tr> <th>Number of profiles (<=71) </th><td><input TYPE=TEXT NAME="numb" SIZE="30" ALIGN="LEFT"></td> </tr> </table> <p> <input type=radio name=wireless value=one checked>Abel inversion or </p> <p><input type=radio name=wireless value=two>2-D tomography ( but not supported at the moment)? </p> <p>Return e-mail address? <input TYPE=TEXT NAME="add" SIZE = 50 ALIGN="LEFT" VALUE=giannone@ipp.mpg.de > </p> <p><input TYPE="SUBMIT" NAME="Submit" VALUE="Submit" SRC="http://www.rzg.mpg.de/~giannone/" ALIGN="LEFT"></p> </form> <b

Louis: it doesn't work for the same reason that the earlier testcases in this bug don't work - the default encoding is not possible for mailto:, so you need to specify text/plain encoding with your form tag: <form METHOD=POST ACTION="MAILTO:giannone@ipp-garching.mpg.de" enctype="text/plain"> that should make it work.

Works now as promised! Thanks

do we have an evangelism bug about the fact that mailto submission only works with text/plain ? If not, could someone with knowledge of the relevent RFCs etc file one with reasons as to why we implemented it that way (versus 4.x)

IE doesn't implement it. I considered 4.x's implementation to be a fluke, but perhaps not. File a bug if you want it, it wouldn't be hard.

I take that back--doing it *right*--so that future encodings work automatically--might be hard. But just getting it to work would not be hard.

I am slightly confused what our situation is then... The archived documentation I read makes no mention of a specific encoding type for mailto: form submission. It does however list restrictions for other methods of submission. I also can't seem to find text/plain mentioned anywhere as a normal enctype. I only looked briefly though so I might have missed it. The question I had was for an explanation as to why we chose to only implement text/plain (and why we mandate its presence instead of assuming it). If we have a reason -- it being mentioned in a standard or something -- we should file an evangelism bug to act as the repository of the various dups we will get saying "it doesn't work" If we don't have a reason -- or it was just easier to force text/plain -- then I will be happy to file a real bug against the product for other enctypes inclusion. (url-encoded seems to be an important one -- it being the standard default)

The reason was, this isn't really mentioned in any specs, IE requires text/plain, and most tutorials on the Internet show text/plain. As I've said, feel free to file a bug on this--it would be a net gain to fix it.

bug 159786 filed about supporting more than just text/plain

adt1.0.1- per the ADT. let's get it in the next release.

Even though text/plain should work, this one does not: <form method="post" enctype="text/plain" action="mailto:my@email.address?subject=I: Newsletter Subscription" onSubmit="return confirm('Subscription has been sent')> Why doesn't this one work even though it should? Tried on Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021009

I think onsubmit has to return true for the action to proceed.

Does anybody know if this was fixed in the 1.0.x branch? Just tested with latest nightly ("Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.2) Gecko/20021023") an I still get an empty "Compose: " Window with Testcase #125. This doesn't happen with 1.1/1.2b!

I have tested Moz 1.2b Build 2002101612 using the testcase in #66 and I still get the new compose window. The form submission works in Opera 6.03 and the windoze browser. It also works in NN 4.79

form submission only works in msie 6 if you use their office express mailer... info is not fed to external mailers very well . complete failure feeding pegasus except for heading field... but this is not mozilla issue just pointer that evil empire is still in control of their lackeys

In response to JR post #225 - The topic of this being a mozilla problem or not has been discussed in this thread. Right or wrong both NN and ie supported email form submission. Opera supports it. You are probably correct that the key is having the m$ email program installed. Regardless, I have a shed-load of customers that use this technique and have used it for years. I am fairly certain that all these customers are using m$ office or at least have lookout xpres installed. So, that may explain why they are successful. When this problem (and I consider it a problem) was encountered by two of my customers they decided to keep NN as their browser of choice. With neither Moz or NAV supporting this feature then they will not move to Moz or Nav. These customers use email form submission for their internal work (they use email form submission between departments scattered throughout the area).