Form with mailto: action is wrongly escaping spaces chars

NEW
Unassigned

Status

()

defect
--
trivial
5 years ago
3 years ago

People

(Reporter: xaviermd, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

Reporter

Description

5 years ago
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 (Beta/Release)
Build ID: 20140715214327

Steps to reproduce:

When I use my browser to prepare an e-mail (to thunderbird), if I submit a form with a action="mailto:", all spaces in name="subject" and name"body" are replaced by spaces.
Try it with the attached html file :
Choose a subject with space within, write some sentence in the body, and press “Send”


Actual results:

Spaces in subject and body are replaced by “+” symbols in Thunderbird compose mail

FYI, the exact same behaviour also happens in Chrome !


Expected results:

As i'm using a completely standard form, the spaces must have been properly escaped by the browser when giving the data to the e-mail composer.

Note : this bug is not really useful, but noted as I wrote about contact forms ( http://dascritch.net/post/2014/08/19/Formulaire-de-contact-ou-mailto in French)
Reporter

Comment 1

5 years ago
A view of the bug on my computer.
Confirmed on Firefox 31 stable and 34.0a1 (2014-08-18) on Windows
Status: UNCONFIRMED → NEW
Ever confirmed: true
@Xavier
it's not related to mailto, but forms in general see:
http://www.w3.org/TR/html4/interact/forms.html#h-17.13.4
Reporter

Updated

5 years ago
Severity: normal → trivial

Comment 5

5 years ago
Note that:

 Cc["@mozilla.org/uriloader/external-protocol-service;1"].getService(Ci.nsIExternalProtocolService).loadURI(makeURI("mailto:foo@bar.com?subject=foo+bar"))

in the browser console will produce the same result.

This is all to do with form vs. uri encoding. I don't know why Thunderbird doesn't deal with them - but Mail.app on Mac doesn't either, so it seems to me that in the external protocol handler, we could just replace '+' with "%20" in the query string (plus potentially whatever other quirks form encoding has) and that shouldn't break anything, but would fix this issue (try changing it yourself in the above example)...

The alternative (making form encoding check what scheme it's about to submit to and decide to use different URI encoding for some of them) seems supremely evil, so let's not go there...
Component: Untriaged → File Handling
OS: Linux → All
Product: Firefox → Core
Hardware: x86_64 → All

Updated

3 years ago
Product: Core → Firefox
Version: 31 Branch → unspecified
You need to log in before you can comment on or make changes to this bug.