Closed Bug 178413 Opened 22 years ago Closed 20 years ago

Mailto url does not work in POST mode

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: oliviervigneron, Assigned: bugzilla)

References

(Depends on 1 open bug)

Details

Attachments

(1 file)

Testcase (with 4096 bytes in the body)
4.30 KB, text/html
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826

If you use a mailto URL using POST method (for exemple when you need to open a
compose window with a long text in the body, it simply does not work).
Warning: if you put a small size for the body parameter, some browser (IE...)
will try to use GET method instead, which works.)

HTML code to use:

<html>
<head>
<title>Send to local mail system</title>
</head>

<body>
Sending to local mail system.
<br>

<form name="formulaire" action="mailto:" method="POST" >

<input type="hidden" name="body" value="{VERY LONG DATAS TO PUT HERE}">



</form>
<script language="javascript">

document.formulaire.submit();

</script>

</body>



Reproducible: Always

Steps to Reproduce:
1.use HTML above
2.
3.

Actual Results:  
Mozilla compose window opens, but empty

Expected Results:  
Body should be filled with the parameter in the form, sent via POST method.
Using a recent Mozilla build on Mac OSX, we display the following in the message
body:
body=%7BVERY+LONG+DATAS+TO+PUT+HERE%7D

IE 5.5 on Win2K show an empty message body!
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Depends on: 61893, 79128
1. it looks to me that it should not encode with plus-for-space.

HTML 4.0 specifies that application/x-www-form-urlencoded should be used for
submitting forms just to http URLs, not for mailto URLs.
  http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.13.3.4

So while application/x-www-form-urlencoded specifies substituting plus-for-space 
  http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.13.4.1
normal URL encoding (used by mailto) does not (rfc 1738 sec 2.2).

Therefore, I suggest this bug does *not* depend on bug 79128 (which I believe is
invalid)

2. Note that the corresponding mailto url works (no "body=", no %20 encodings),
so the problem appears to be not in handling mailto in general, but in handling
forms.

<html>
<body>
<a
href="mailto:?subject=Form%20Post%20from%20Mozilla&body={VERY%20LONG%20DATAS%20TO%20PUT%20HERE}">
Click to Open email</a>
</body>
</html>


Maybe the form-submission handler for 'mailto' is not constructing the right
mailto url.  If so, I suggest this bug can be recategorized under
Browser/Form-Submission.

I hope this helps.

The encoding used is not the issue of this bug.  At any rate, you should read
further into the stuff about www-form-urlencoded.  "For any other value of
action or method, behavior is unspecified."  This means "implement it however
you want."  If someone specifies they want a www-form-urlencoded message, that's
what they are going to get (and www-form-urlencoded is the default).  If you
want normal mailto encoding, specify enctype="text/plain".

This bug is about form sub not working at all when you do POST, which I have not
verified or thought about what we should do.

OV, you know you can add enctype="text/plain" to that URL and it will probably work?
Component: Composition → Form Submission
Product: MailNews → Browser
Effectively, in Windows XP SP1, if not all other OSs, FireFox will not open
either my default email client or Outlook Express (not my default client). Also,
it will not submit the form through any internal mailing API (it shouldn't be
able to either, there's no place to configure a destination SMTP server as far
as i can tell)

As a side comment: Intenet Explorer, on at least one test case (
http://www.davidbrin.com/questionnaire.html ) will open an Outlook Express
window with the appropriate email address already loaded. But the form content
is not included!!!

Anyways, in the end they both fail to send the data.
Verified the presence of enctype DOES NOT FIX the problem.
I'm sorry about the mad posting spree...
After some further testing on the same form:
http://www.davidbrin.com/questionnaire.html I noticed it does actually work as
long as only a few random items are filled out. After a certain unchecked amount
(more than around 10 items however) the page will stop creating the submission
email.
I verified the source code and this is not the intended page behaviour.
This worksforme in a current SeaMonkey build (and in fact bug 159786 checked in
explicit code to handle this case).

As John said, the behavior described in comment 1 is correct given the markup here.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
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: