Mailto url encoding issue iOS 14.6

Hi there,

Since I upgraded to iOS 14.6 I have noticed that mailto urls no longer format line breaks correctly in default iOS mail application

eg: mailto:john@xxcom?subject=test&body=name%0D%0Aemail

Result in iOS 14.6 mail app (body)

name<BR>email

Result in previous iOS versions mail app (body)

name

email

Is there any work around or solution to this issue?

Post not yet marked as solved Up vote post of Murielle Down vote post of Murielle
13k views
  • I have the same problem, any workaround so far?

  • i also have the same problem , is there any update for this issue ?

  • I also noticed the same issue in my app :(

Answers

It's a Safari bug. Works fine WebViews.

  • It's a bug in the ios mail app... other mail apps work fine

  • I see the bug happening in Safari and WKWeView. I think it is in iOS Mail app.

Add a Comment

Seems to be a bug in iOS 14.6 Mail app. Versions before and other apps are working fine. I've tested it with native apps and websites. Almost every mail in the internet looks like this right now in iOS 14.6

Support for rich content, such as HTML, has been removed for mailto links from iOS 14.6+. Please see the following support document for further information on security fixes made in iOS 14.6: https://support.apple.com/en-us/HT212528

  • How are newlines considered rich content? Is there a way to create a line break? Because '%0D%0A' is just the url encoded form of '\r\n'. Even worse is the email app converted what is not rich content INTO "rich content" (by transforming the url encoded line breaks into text based <BR>).

  • I agree with devshorts and I'm having the same problem.

    My \n are being interpolated into <BR> in the iOS mail app on all mailto links and my company's clients are complaining. I don't think \n and \r could ever be considered rich text... this seems more like a bug?

  • From the link @Frameworks Engineer gave:

    Impact: Processing a maliciously crafted mail message may lead to unexpected memory modification or application termination

    Please sit around the table and discuss how url encoded carriage returns are malicious. Consider allowing the handful of encoded characters.

We have the same problem. Do you know if there is a workaround other than installing another email app as Outlook?

I ended up using MFMailComposeViewController to display the email interface within the app

https://developer.apple.com/documentation/messageui/mfmailcomposeviewcontroller

If you have a requirement to support multiple mail clients you can follow the second most popular response from this thread https://stackoverflow.com/questions/25981422/how-to-open-mail-app-from-swift

Hope this helps

  • this works for me tested on ios 14.6 and 14.7 thanks

  • Is there a Cordova solution?

Add a Comment

I'm also looking for a workaround, but would be better if iOS 14.6+ could fix this since it doesn't respect the RFC standards as mentioned by @micaball

This bug or "feature" is still present in iOS 14.7 beta 3.

  • This behavior is not compliant and it seems to be a bug. Any progress? do you know if there is a workaround on iPhone mail app?

Add a Comment

This behavior is not compliant and it seems to be a bug. Any progress? do you know if there is a workaround on iPhone mail app?

Still exists in iOS 14.7 beta 4

Bug or no bug?

Its totally killing my Oracle-based approval workflows for submitting digital time cards via email and for managers' accounting/purchasing approvals.

Post not yet marked as solved Up vote reply of SIMR Down vote reply of SIMR
  • Still an issue for me too. I've got {mailto} links embedded within some GIS applications to generate work orders with pre-formatted email bodies. It goes without saying that the "pre-formatting" is no longer working. Users aren't happy.

    I'm going to try and download Outlook on my iOS device and see if I can set it as the default mail app. I've got my fingers crossed that the mailto links will automatically open in Outlook instead of mail.

Add a Comment

The problem still persists on iOS 14.7 Beta #5 (July 8 2021). 

My company's Oracle Approval email workflows are broken. Executives and managers approve time cards, purchases, etc via iOS Mail.app. The original message is HTML. When the "Approve/Deny" button is tapped, the reply message body is no longer HTML - it is formatted as plain text, and thus it shows the raw tags - which completely breaks Oracle. 

Our purchasing, Accounting, and Executive teams are not happy campers... 

This issue started for us in iOS 14.6 and continues in 14.7 thus far. We are considering replacing Apple Mail with MS Outlook for iOS managed devices if this continues. 

Does anyone have an open support case with Apple that I can cross-reference?

Post not yet marked as solved Up vote reply of SIMR Down vote reply of SIMR
  • Update July 13 2021:

    iOS 14.7 RC 1 (released July 13) fails (displays raw tags in reply body.)

    iOS 15 Dev Beta 2 fails (displays raw tags in reply body.)

Add a Comment

Dear Apple. Either update following documentation (remove conformance to RFC2368) https://developer.apple.com/library/archive/featuredarticles/iPhoneURLScheme_Reference/MailLinks/MailLinks.html#//apple_ref/doc/uid/TP40007899-CH4-SW1 or fix this annoying bug.

  • Hahaaha a clear paradox 😅

Add a Comment

As a temporary fix, I added a <html>%0D%0A at the start of the body portion of the email and a %0D%0A%</html> at the end. Unfortunately, the tags show as text in the body, but everything is on its own line.

...body=<html>%0D%0ALine1%0D%0ALine2%0D%0ALine3%0D%0A</html> shows up as:

<html>

Line1

Line2

Line3

</html>

I don't like the <html> and </html> showing up, but at least the body is once again readable.

  • Excellent workaround. I moved the opening to the end and it seems to work the same.

    ...body=Line1%0D%0ALine2%0D%0ALine3%0D%0A<html>%20</html>

  • Thanks so much for this temporary fix! It may have a couple clumsy tags, but at least it's readable. You totally helped our small business with this. :)

Add a Comment

I submitted a report on this via Feedback Assistant yesterday. It got closed fairly fast:

  • Recent Similar Reports: Less than 10
  • Resolution: Investigation Complete - Works as currently designed

Very frustrating. But maybe it would help if everyone affected could submit their own feedback ticket and bump up that "recent similar reports" count until someone at Apple decides to take a second look.

  • Yes good idea. What was the title and text of your ticket so we can post something similar ?

  • (Thanks to the poor formatting options for forum comments, I'll need to respond to this this in a top-level answer, below.)

Add a Comment

Here's what I submitted via Feedback Assistant:

  • Title: mailto URL scheme no longer supports line breaks
  • Area: Mail
  • Type: Incorrect/Unexpected Behavior

Mail 14.6 no longer supports mailto URLs containing the “%0D%0A” character sequence to specify a line break in the message body. Instead of a line break, this sequence gets converted to literal text “<BR>” in the message body. For apps that use specific formatting in mailto-generated messages to drive back-end business logic, this is a disastrous regression.

This bug is in the Apple Mail app, not in the OS handling of mailto URLs. If you change your default mail app to (for example) Outlook or Gmail, then the “%0D%0A” sequence is still handled correctly.

This affects a lot of apps. Please see this Apple Developer Forum thread for discussion of the impact: https://developer.apple.com/forums/thread/681023

In that forum thread, note the response from “Frameworks Engineer ” who seems to fundamentally misunderstand the issue. Please ensure that this issue is understood as breakage of previously correct behavior. “Support for rich content…has been removed” does not explain the new behavior that inserts the unexpected text “<BR>” into the specified message.

Add a Comment

How can Apple make such blunders the credibility is going down the drain and I am not sure anyone from apple development watching this thread it has been more than a couple of months and no fix yet, this is pretty bad with Apple this is impacting multiple processes we have for different applications.