28 June 2011

Quick reaction

We have a little corner of the application that's a low-volume, lightweight workflow and e-mail notification system. On demand, the web app assembles an e-mail message containing a summary of the article that the user has written; it then bundles that message into a mailto: URL, attaches the URL to a hidden <a> tag on the page, and simulates a click of the tag's hyperlink. The browser routes the request to the appropriate e-mail client (usually Outlook), the user adds any other desired information to the message, and sends it from the e-mail client.

We found that we had to fudge things a bit so that the various browsers we support don't complain about this indirection. The production JavaScript that was working smoothly up until last week follows. (The method name is a little funky, but I think I had a good reason for it at the time.)

// Open a new window for an e-mail message with the specified properties.
// Arguments:
// subject, body, toAddress: expected to be URI encoded, special characters scrubbed
// mailToLink: DOM object to attach the mailto: link to
CLIENT.Utilities.openEmailBaseWindow = function (subject, body, toAddress, mailtoLink) {
try {
var url = 'mailto:' + toAddress +
'?subject=' + subject +
'&body=' + body;
if (mailtoLink.click) {
//IE path: avoids the 'sending by e-mail' warning
mailtoLink.href = url;
} else {
var form = document.forms['mailto'];
//Firefox path
form.action = url;
} catch (e) {
//write error message to the log; show error to the user;
//drop hints that the browser may not be properly config'd for mailto:

This code uses the presence of the .click() method to detect browser capabilities. But this month's release of Firefox 5, which apparently caught some people unprepared, broke this JavaScript. Firefox 5 now defines a .click() method for anchor tags. So, in the code passage above, Firefox 5 takes the true path on the if statement (commented as the Internet Explorer path). Not a problem in itself, except that in this context, the .click() method doesn't do anything—more specifically, it does not cause the browser to navigate to the new URL.

Our current workaround is to disable the if test and to always use the form submission technique. Using the form, Internet Explorer 8 under Windows 7 produces two separate warning popups, but we can live with this wart: few of our users depend on IE.

No comments: