Closed Bug 61893 Opened 24 years ago Closed 22 years ago

Form data not being mailed when using mailto: in form action attribute (eg <form action=mailto:user@company.com>) [form sub]

Categories

(Core :: DOM: Core & HTML, defect, P3)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.1alpha

People

(Reporter: stefang, Assigned: john)

References

Details

(Keywords: dataloss, testcase, Whiteboard: [FIX]NO SPAM PLEASE [adt2 RTM] [ETA 07/24])

Attachments

(9 files, 6 obsolete files)

workaround for the inpatient
895 bytes, text/html
Details
Testcase
505 bytes, text/html
Details
Patch v1.1
10.43 KB, patch
john
: review+
dveditz
: superreview+
asa
: approval+
Details | Diff | Splinter Review
Suggestion
15.36 KB, image/gif
Details
Fix typo on image
15.33 KB, image/gif
Details
Revised Proposal :-)
55.78 KB, image/gif
Details
Existing Warning
6.13 KB, image/png
Details
Branch Mailto: body newline patch
837 bytes, patch
doronr
: review+
doronr
: superreview+
Details | Diff | Splinter Review
ascii data
2.36 KB, text/plain
Details 
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.
Component: Browser-General → Form Submission
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.
Assignee: asa → rods
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: 4xp, testcase
OS: Linux → All
QA Contact: doronr → vladimire
reassigning
Assignee: rods → pollmann
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...
Severity: normal → minor
Status: NEW → ASSIGNED
Hardware: PC → All
Target Milestone: --- → Future
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.
Severity: minor → normal
Keywords: 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.
Keywords: nsBranch
*** 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.
Severity: normal → major
*** Bug 94892 has been marked as a duplicate of this bug. ***
Keywords: mostfreq
Target Milestone: Future → mozilla1.0
I will be happy to test as soon as a build is ready.
Assignee: pollmann → evaughan
Status: ASSIGNED → NEW
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
Target Milestone: mozilla1.0 → mozilla0.9.5
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.
Keywords: nsbranch → nsbranch-
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.
Whiteboard: PDT
Pls provide an ETA.
Whiteboard: PDT → [PDT] [ETA ?]
what are the chances this is gonna make the 094 branch?
Whiteboard: [PDT] [ETA ?] → [PDT] [Need ETA]
clearing out the PDT field. This bug is nsBranch-.
Whiteboard: [PDT] [Need ETA]
This should go to the new form owner
Assignee: evaughan → kmcclusk
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Reassigning to Alex
Assignee: kmcclusk → alexsavulov
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Summary: Form data not being mailed when using mailto: in form action attribute (eg <form action=mailto:user@company.com>) → Form data not being mailed when using mailto: in form action attribute (eg <form action=mailto:user@company.com>) [form sub]
Blocks: 103889
marking nsenterprise-; will be reevaluated for nsenterprise in future release.
Keywords: nsenterprise-
Keywords: nsenterprise
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.
Severity: major → critical
Keywords: dataloss
*** Bug 105907 has been marked as a duplicate of this bug. ***
Blocks: 107067
Keywords: nsbranch-
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.
Severity: critical → normal
Target Milestone: mozilla0.9.7 → Future
>  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.
Severity: normal → critical
Keywords: mozilla0.9.7, nsCatFood
Target Milestone: Future → ---
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
Keywords: mozilla0.9.6, mozilla0.9.7 → mozilla0.9.8, nsdogfood
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.
Whiteboard: NO SPAM PLEASE
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.
Target Milestone: --- → mozilla1.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.
No longer blocks: 107067
nominating for nsbeta1
Keywords: nsbeta1
Marking nsbeta1-.
Keywords: nsbeta1 → 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.....
Keywords: mozilla0.9.8
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
Blocks: 135980
Attached patch 80% patch (obsolete) — — Splinter Review 
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".
Attachment #21044 - Attachment is obsolete: true
Comment on attachment 62973 [details]
simple mailto test with subject, without enctype

Again, enctype="text/plain" needed.
Attachment #62973 - Attachment is obsolete: true
Attached file Testcase — 

    
    

    
  
Taking.
Assignee: alexsavulov → jkeiser

    
    

    
  
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.

    
  
Blocks: 90728

    
  
Blocks: 136084

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Patch (obsolete)
        — 
          — Splinter Review
      

    


  
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

        Attachment #78078 -
        Attachment is obsolete: true

    
    

    
  
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.
Status: NEW → ASSIGNED
Keywords: nsbeta1- → nsbeta1

    
    

    
  
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.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Patch v1.1
        — 
          — Splinter Review
      

    


  
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)

    
  
Whiteboard: NO SPAM PLEASE → [FIX]NO SPAM PLEASE

    
    

    
  
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.

    
  
Blocks: 136906

    
    

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

    
  
Blocks: 147904

    
    

    
  
*** 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?

    
    

    
  

      
      
      
      

        Attached image
          
        Screenshot (obsolete)
        — 
      

    


  
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.

    
    

    
  

      
      
      
      

        Attached image
          
        Suggestion
        — 
      

    


  
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).

    
    

    
  

      
      
      
      

        Attached image
          
        Fix typo on image
        — 
      

    


  

    
    

    
  
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.

    
    

    
  

      
      
      
      

        Attached image
          
        Revised Proposal :-)
        — 
      

    


  
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.

    
    

    
  

      
      
      
      

        Attached image
          
        Existing Warning
        — 
      

    


  
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?
Keywords: mozilla1.0

    
    

    
  
nsbeta1-
Keywords: nsbeta1 → 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?

    
  

        Attachment #78225 -
        Attachment is obsolete: true

    
    

    
  
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").

    
  

        Attachment #86025 -
        Attachment is obsolete: true

    
    

    
  
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)

        Attachment #78136 -
        Flags: superreview+

        Attachment #78136 -
        Flags: review+

    
    

    
  
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).

        Attachment #78225 -
        Attachment is obsolete: false

        Attachment #78225 -
        Flags: review+

    
  

        Attachment #78136 -
        Attachment is obsolete: true

    
    

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

sr=dveditz

        Attachment #78225 -
        Flags: superreview+

    
  
Keywords: approval

    
    

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

a=asa (on behalf of drivers) for checkin to the 1.1 trunk.

        Attachment #78225 -
        Flags: approval+

    
    

    
  
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!
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED

    
  
Blocks: 157228

    
    

    
  
*** 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

Status: RESOLVED → VERIFIED

    
    

    
  
nominating for 1.0.1
Keywords: nsbeta1- → adt1.0.1, 
          
            nsbeta1

    
  
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [FIX]NO SPAM PLEASE → [FIX]NO SPAM PLEASE [adt2 RTM] [ETA 07/24]

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Branch Newline Patch (obsolete)
        — 
          — Splinter Review
      

    


  
This is the newline portion of the patch for branch.

    
    

    
  


  
new patch for branch

        Attachment #92640 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 92652 [details] [diff] [review]
Branch Mailto: body newline patch

transfering r/sr since its part of the original patch.

        Attachment #92652 -
        Flags: superreview+

        Attachment #92652 -
        Flags: review+

    
    

    
  
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

    
  
Blocks: 159399

    
    

    
  
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.
Keywords: adt1.0.1 → adt1.0.1-

    
    

    
  
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

    
    

    
  

      
      
      
      

        Attached file
          
        ascii data
        — 
      

    


  

    
    

    
  
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).
Blocks: 178413
Component: HTML: Form Submission → DOM: Core & HTML

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: