1055950 - Form with mailto: action is wrongly escaping spaces chars

Status: NEW

(Firefox :: File Handling, defect)

Description

[Xavier Mouton-Dubosc]

Attachment: 1408-FormulaireDeContact-Form-Action-Mailto-Bug.html

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)

Comment 1

[Xavier Mouton-Dubosc]

Attachment: 1408-FormulaireDeContact-Form-Action-Mailto-Firefox31.png

A view of the bug on my computer.

Comment 2

[Antoine Turmel [:GeekShadow]]

Confirmed on Firefox 31 stable and 34.0a1 (2014-08-18) on Windows

Comment 3

[Antoine Turmel [:GeekShadow]]

@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

Comment 4

[Antoine Turmel [:GeekShadow]]

and: http://www.w3.org/TR/html5/forms.html#url-encoded-form-data

Comment 5

[:Gijs (he/him)]

Note that:

 Cc["@mozilla.org/uriloader/external-protocol-service;1"].getService(Ci.nsIExternalProtocolService).loadURI(makeURI("mailto:[e-mail]?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...