105907 - form method "post" does not post data but opens messenger with an empty e-mail instead

Status: VERIFIED DUPLICATE of bug 61893

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

Description

[Yuri Robbers]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012
BuildID:    Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012

a webpage that submits a form using method "post"
does not actually post the data, but opens the
messenger with an empty email. Clicking send delivers
(of course) just an empty mail. 

The problem is _not_ in the code of the page, since
all other browsers I tried (netscape 4, lynx, w3m, 
konqueror) work as expected, posting the form data.

The problem does occur with both mozilla 0.9.3 and 0.9.5.

I also reproduced it with a PDF-form (see example at
http://rulbii.leidenuniv.nl/pdfform.pdf)

Here the same holds true: it opens the messenger with an
empty email on mozilla 0.9.5 (I did not test this on
mozilla 0.9.3, since that machine doesn't have the nppdf.so
plugin installed), but it works fine under a number of 
other browsers (I tried several machines too, all linux though).

Reproducible: Always
Steps to Reproduce:
1.open the webpage or pdf-file (the latter requires the nppdf.so plugin)
2.fill in arbitrary data
3.press on submit

Actual Results:  the messenger opens with an empty email message (i.e. it
doesn;t even contain the form data)

Expected Results:  the form data should have been POSTed by email "under the hood"

Comment 1

[Jo Hermans]

There are 2 sides on this bug :

- the fact that a messenger window opens (which N4.* didn't do)
- the fact that the messenger-window is empty ( bug 61893 )

(short answer)
What you're really reporting here, is a actually a HUGE security hole in older
browsers. At this moment, Mozilla doesn't support it (although probably not
intentionally :-), but since it's pretty common practice among older browsers,
it will probably be supported sooner or later. But only the 2nd case, not the
1st one (see below). The real solution is to support proper cgi's on your
webserver, not transporting all kinds of form-data 'under the hood' with a
mailer. Don't forget that the mailto-protocol isn't always available (on
anonymous web-terminals for instance). And passing data to mailto-handler's
isn't defined in any standard anyway (post'ing is HTTP, not SMTP).

(long answer)
You're expecting that this data is passed 'under the hood', without putting up a
messenger-window. I'm strongely opposed to that, because it is this method that
is used to collect email-addresses all over the world. You're forgetting that
this email is marked with your email-address, and that you have no chance to
control what's happening with your data. If it was a real invisible process,
then it would be illegal in many countries (definitely in the European Union).
Netscape 4.7 throws up some kind of warning dialog, but still without showing
you what is being transmitted. I guess they had to do that because of privacy
concerns, maybe because of legal problems in certain countries (France I guess,
maybe the USA too).

I guess that bug 61893 will be fixed some day , and then we'll see that data in
the messenger window, so we can inspect it, and refuse to send the email if
necessary (or send it anonymously). But the window has to appear, no data can be
 passed 'under the hood'.

Personally, I wouldn't want to fix this bug, but for backwards compatibility
(it's used in a *lot* of business intranetsites), I guess we'll have to support
it one way or another. I just hope that we won't have a privacy problem here.
This means that we'll have to be able to inspect the data, or be able to pass
the data anonymously. At the very least we should have a warning with a
'remember decision' policy.

But even then, I would still recommend to implement your webpage the *proper*
way, with a cgi-handler. A huge amount of webbrowsers have no access to
smtp-servers (web-terminals for instance), or are not configured correctly. This
means that these people won't be able to use your webpage. Implementing with a
regular cgi-page (post or get) solves this.

Comment 2

[Boris Zbarsky [:bzbarsky]]

*** This bug has been marked as a duplicate of 61893 ***

Comment 3

[Vladimir Ermakov]

verifying