IE9 and mailto character limits - html

Im trying to send a pre-populated email using mailto and href however I soon discovered that IE9 has a problem with recognising hrefs longer than 509 character (give or take). Basically, clicking on the link brings up a blank page. I looked for an answer and came across this javascript solution, however it still doesnt work.
Here is the anchor tag:
Sign up
And here is the script:
var sMailto = "mailto:blah#email.com?body=Dear eyecare professional,%0A%0aTo help us schedule your upcoming webinar, please fill out and return the following information:%0A%0A• Name:%0A%0A• Preferred date of webinar* (any Wednesday at 6 pm EST):%0A%0A• City/State (Optional):%0A%0A• Comments/Questions/Feedback:%0A%0AUpon receipt, we will send you a link to an upcoming GoTo Meeting webinar on Macula Risk implementation in your clinic. These webinars are regularly held on Wednesdays at 6 pm EST.%0A%0A* If you would like to request training on any other date or time - please note this in the Comments section and we will do our best to accommodate your request.%0A%0AKind Regards,%0A%0AGerry Bruckheimer";
function doMailto() {
document.location.href= sMailto;
}
The weird thing is that this works in every other browser except stupid IE 9.
UPDATE: If you are experiencing a similar problem to mine, try using window.open(url). I realise its not a perfect solution but it works.

The URL limit for IE9 is actually quite high at between 5120 and 5150 when following a link. Unfortunately a Javascript hack won't help here - the limit will still be in effect. I doubt that's the issue though.
The message you're sending contains some characters that I wouldn't put in a URL, particularly "•". You should URL encode your message before putting it in a link (that last symbol encodes to %e2%80%a2 apparently). You can URL encode it in Javascript or manually encode it with an online tool before pasting it into the <a> tag.
Some browsers are more relaxed than others in handling strange characters in URL (or in code in general).
Hope that helps

Related

Why is URL query string value causing "Can't reach this page" or "This site can't be reached" error?

I work with a legacy ASP.NET web application that has URLs that use query string values to pass information between pages. I ran into an issue with a couple of URLs that contain spaces, numbers, and dashes that I'm trying to understand.
Here's an example of the URL:
http://myserver.com/SelectReport.aspx?Name=My Report&ReportFile=my_financial_report&ReportTitle=My Financial Planning Across A 1-Year Or 2-Year Outlook
The problematic part of the URL is the ReportTitle query string value.
When I click the link in Internet Explorer 11 or Microsoft Edge, I get a Cant' reach this page. It took too long to connect to this website. Error Code: INET_E_CONNECTION_TIMEOUT error. It should be noted that the link works fine if I turn ON compatibility view settings in Internet Explorer 11.
When I click the link in Google Chrome, I get a `This site can't be reached. The connection was reset. ERR_CONNECTION_RESET" error.
If I delete the 2 in 2-Year, the link works. However, if I delete the 1 in 1-Year and leave 2-Year alone, the link does not work. I'd like to know why removing the 2 in 2-Year allows the link to work, but removing the 1 in 1-Year does not. This is true whether I replace spaces with %20 or not. Does anyone know the answer?
I know that I can replace the spaces in the ReportTitle query string value with plus signs (+) and it will work. This is likely the route I will take to fix the issue, but I was hoping to understand the issue better.
Thanks!
This is the continuation of my comments in the original post. I am writing this answer to share the demo example. It may not be a full answer.
There is absolutely no difference when you have spaces, or spaces are replaced by %20 or spaces are replaced by +. Also, I mentioned earlier your URL has valid characters including -.
See the three links below. I suspect it is your application that is dealing with URL encoding, decoding and having issues. It is not a general problem.
With Spaces
<br>
With %20
<br>
With +

HTML mailto subject and body display plus sign(+) instead of space in mail client

It's happening in
- Samsung Galaxy Note3 & 4
- Google Chrome browser V39.XX
I am using a link and when click it's launch the mail client
href="mailto:info#gmail.com?subject=Network%20issue"
result: subject=Network+issue
How to remove the plus(+) sign?
Your original approach should work... The only reason that comes to mind behind it not working is perhaps encodings are being mixed up along the way? Take a look at these threads to get a better idea of what I mean:
mailto special characters
Special characters in UTF8 mailto: subject= link and Outlook
I experimented with the base64 approach that is the answer in the second link but was unable to remedy the issue :-\ I tested this on Gmail, Inbox, and Mailbox - all with the same results as what you are describing above.
Maybe something is getting messed up at the Android layer in terms of how the link is being handed off to the mail client of your choice?
If you're rendering using Javascript, try encoding as a URL using encodeURIComponent
const urlEncoded = encodeURI(mailToLink);
before you pass the URL to the mailTo link. Otherwise encode it in the backend first.
This can be done with email addresses that contain special characters too.

Mailto: Guideline and character limitation

I'm trying to code an application which will allow users to send emails from outlook using the mailto tag. I know with the mailto, there involves limitation of # of characters that may be passed, as well as encoding.
Does anyone know the exact count of characters I can use, and what guidelines to follow when it comes to encoding special characters? What is counted in the max number of characters you can use? Body and Subject or the whole line including mailto syntax?
For example I will have the following:
<a href='mailto:test#gmail.com?subject=Test Mail&body=Line one.%0D%0ALine two.'>Test Link</a>
Would this be 69 characters??
Forgot to mention, supported browser will be IE6.
Any help would be appreciated.
Thanks
As far as I know there is no limit.
The HTML 4 spec says nothing about a limit
Authors may create links that do not lead to another document but
instead cause email to be sent to an email address. When the link is
activated, user agents should cause a mail program to open that
includes the destination email address in the "To:" field.
To cause email to be sent when a link is activated, specify a MAILTO
URL as the value of the href attribute.
http://www.w3.org/TR/WD-html40-970917/struct/links.html#h-13.2.2
However, many sites report a 256 character limit.
You should test to be sure.
You may also find this question and answers illuminating: What is the email subject length limit?
Same problem here, so far no good. IE9 has a limit of around 505 characters per href="...", Chrome 21 is better - around 2000 chars.
Update! According to this guys there is a workaround, and it seems to work for me:
ClientScript.RegisterStartupScript(this.GetType(), "mailto",
"<script type = 'text/javascript'>parent.location='" + longMailtoText +
"'</script>") ;
This will launch the script and open MailClient window as soon as client gets the response. LongMailToText should follow all standard rules, except for length - so far i was able to send over 2000 chars through it.

Is there anything wrong with this Google App Engine url-fetching code that I have here?

When I view the source of the page in my browser (FireFox) (View->Page Source), copy it and paste it into my HTML editor, I view almost the same page (In this example it is www.google.com) as it appears in my browser. But when I get the HTML source through this code (through Googles App Engines)
from google.appengine.api import urlfetch
url = "http://www.google.com/"
result = urlfetch.fetch(url)
if result.status_code == 200:
print result.content
copy it and paste it into my HTML editor, the page then looks quite different. Why is it so? Is there something wrong with the code?
++++++++++++++++++++++++++++++
Follow-up:
By this moment (Sunday, December 13th, 2009, 1:01 PM, GMT, to be precise) I have received two comments-questions (from Aaron and Christian P.) and one answer from Alex Martelli.
Both Aaron and Christian P. are asking about what actually is different between the Fire-Fox-obtained source and Google-App-Engine-obtained source when they are both displayed through the same HTML editor.
Here I have uploaded too screen shots:
One shows the Fire-Fox-obtained source
And the other one shows Google-App-Engine-obtained source
when they are both displayed through “MS Front Page” editor.
One difference, which is quite obvious, is different encoding: In Fire-Fox code everything is displayed in English, while in the Google-App-Engine code I get a lot of various symbols, instead.
Another difference is some additional lines at the top of the page in the Google App Engine code. I think, this is what Alex Martelli was talking about in his answer (“…the fetch-and-print approach is going to have metadata around it as well…”).
One more minor difference is that the box for the Google image is split into several boxes in one code, while it remains whole in the other one.
Alex Martelli suggested that I use this code (if I understood him correctly):
from google.appengine.api import urlfetch
url = "http://www.google.com/"
result = urlfetch.fetch(url)
if result.status_code == 200:
print "content-type: text/plain"
print
I’ve tried it, but in this case nothing is displayed at all.
Thank you all for your responses and, please, continue responding – I really want to see this issue finally resolved.
++++++++++++++++++++++++++++++
Follow-up:
Okay, the issue has been resolved.
I failed to pay my full attention to Alex Martelli's instructions and, therefore, came up with a wrong code. Here is he right one:
from google.appengine.api import urlfetch
url = "http://www.google.com/"
result = urlfetch.fetch(url)
if result.status_code == 200:
print "content-type: text/plain"
print
print result.content
This code displays exactly what is needed - no additional lines at the top of the page.
Well, I still get the strange symbols, but I discovered that it's probably Google's problem. The thing is I am currently in Taiwan, and Google seems to be aware of that and automatically switches from www.google.com (which is in English) to www.google.com.tw (which is in Chinese), but this one, I guess, is already another topic.
Thanks to everyone who has responded here.
You have not explicitly emitted a "content type" header, and an end-of-headers empty line, so the first few lines are probably going to be lost; try adding before the final print something like
print "content-type: text/plain"
print
Beyond this, what you're getting in either case is essentially a big <script> with a little extra HTML around it -- that's all that Firefox is going to give you in the "view source" page, while the fetch-and-print approach is going to have metadata around it as well, e.g., the "doctype" (depending on what HTML editor you're targeting, this may or may not be an issue).

IE8 claims my page has an error, firefox doesn't, and I can't find any error. Help!

This is something of a follow-up question to my question here. You can find the HTML source in a text file here.
When I load that page in IE8, I get the "Done, but with errors on page." message in my status bar. The detail view shows
Expected identifier
sms Line: 147
Code: 0 Char: 67
and I see absolutely no problems anywhere near there. In IE8, the page is still behaving erratically w/r/t the randomly losing focus as mentioned in my other question.
When I load the same exact page in Firefox (using Firebug) the console shows no errors and the page works perfectly. Any thoughts on what's going on here? This is driving me nuts and making me want to give up on even trying to write an IE friendly page.
Edit: Thanks for all the comments! This page is written as a JSP, so I edit in Eclipse. I found an Eclipse warning about the onblur event for the username field. I switched it from
onblur="alert(document.activeElement + ' class:' + document.activeElement.class)"
to
onblur="alert(document.activeElement)"
and that made the bizarre IE page error vanish. I had been trying to give more info (namely, its CSS class) about specifically which element is stealing focus - to my own detriment, apparently, since Javascript was interpreting the '.class' part in the Java(script) sense there is no class property (I should have been using className).
And, no, the page doesn't validate. But the errors were mostly/all ones that just didn't make sense to me, such as
Line 14, Column 41: Attribute "LANGUAGE" is not a valid attribute. Did you mean "language"?
But I'm still stuck trying to figure out why, as I enter text in the username & password fields, focus randomly switches to a div (working on figuring out which div currently).
Edit 2: It's the div between the two "global nav" comments, at the very top of the body. Still no idea why it's happening, though.
The problem appears to be the line
onBlur="alert(document.activeElement + ' class:' + document.activeElement.class)"
when you take off the ".class" it loads without issue. Are you sure ".class" is valid?
Does your HTML validate?
I agree, IE does a terrible job giving developers information about page errors. I only support IE on the principle that users shouldn't have to download twenty-odd browsers to go to their favorite websites. Web developers have a responsibility to make it "just work". Browser developers have a responsibility to communicate with each other and conform to standards.
Run your javascript through JSLint. You probably have a missing semicolon somewhere or a comma at the end of an object property that shouldn't be there. Firefox is more forgiving than IE when it comes to those types of syntax errors.
Edit: The inline js in your page seems to be OK. Check the contents of qm_scripts.js.
When I remove the .class from document.activeElement.class the error goes away.
The real issue is that you need to be able to debug your JS in IE 8, correct? There is a tool for that! :)