Web 3.0, 6 Bladed Razors, 7 Minute Abs » Ajax

Emulating onhashchange without setInterval

Zach Leatherman — Thu, 21 Aug 2008 06:00:13 +0000

There is one limitation that all of the major JavaScript browser history management plugins have to hack around: How to tell when there is a change to the location.hash? Sure, you can tell when you’re modifying the hash yourself, but what if the user hits the back/forward button?

YUI’s History component and Really Simple History both use setInterval with an internal variable to compare and find changes. But this isn’t really an optimal solution. As proper front end engineers, we should avoid timeouts as much as possible. Internet Explorer 8 will have an onhashchange event that clients will be able to subscribe to. That will be nice. But surely, a cross browser solution without the use of setInterval exists.

Look, a cross browser solution without the use of setInterval:

On initialization, we load an iframe onto the page that is positioned absolutely at -500px,-500px so the user can’t see it. It is a skeleton page that only needs cross browser code to add an “onscroll” event, and to be able to calculate the scrolled position of the iframe itself. For my example, I use jQuery and the dimensions plugin to accomplish this, but it could easily be trimmed down to only the bare essentials (or ported to a different library).
To add an AJAX history entry into the browser’s history under an assigned hash string, we first add a hashString to the tag of the iframe. Using css to increase the size of the a tag proportional to the iframe’s height, we can guarantee scrolling will happen.
Then, we change the location.hash of the iframe to point to that tag. This will scroll the iframe to the content, and create a new entry in the browser’s history object.

Inside the iframe, we have our onscroll event that fires when the scrolling in the previous step took place. (Minor IE-related workaround: The browser’s history object is changed, but the hash property doesn’t when attempting to read it later. Instead, we find the that matches up with the scrollY/pageOffsetY property inside of the iframe, and retrieve the matching hash from the tag.)

The nice thing about this approach is that you don’t even need a history manager anymore. This little iframe will do all of your dirty work for you. And it will even maintain your history alongside any other iframe browsing on the page.

Advantages:

Can serve as back button support and full AJAX history manager.
Page Weight: the test page and iframe HTML files together weigh in at 2.76 KB. That includes the non-jQuery JavaScript needed to do everything.
Cross browser: Tested in FF3, IE7, IE6, Opera 9.5, (not Safari — see below)

Limitations:

No bookmarking support. We aren’t changing the top hash, we’re changing the iframe hash, so these aren’t bookmarkable.

Sample Example:

Update: Given time for more rigorous testing, it doesn’t look like Safari supports this approach. So, until WebKit fixes #9166, we’ll have to stick to timers in Safari. A more pragmatic programmer than I might hack around this approach by exploiting #19202, but that certainly wouldn’t be a long term solution. I’ve also updated the test page above, at Dean Edwards humble request, to support dynamic client size text size changes.

Don’t Let the Door Hit You Onunload and Onbeforeunload

Zach Leatherman — Wed, 23 Apr 2008 04:51:08 +0000

Many people attempt a last ditch effort to save page state in the browser by using the onunload or onbeforeunload events. This has been studied at great length by Patrick Hunlock, who uses the perhaps now common knowledge of using a Synchronous Ajax call to perform the page state save.

Another use for the onbeforeunload event to allow the user to cancel the action that initiated the user leaving in the first place. Gmail uses this technique when the user is in the middle of writing a draft of an e-mail and attempts to leave the page.

Gmail’s pops up this prompt when the user attempts to leave the page while drafting an email.

Worthy to note, however, is that Opera doesn’t fire the unload event when the browser refreshes the page, or uses the back/forward buttons to browse off of the page (I had no success with the fix posted in the comments on that page). What’s worse, Opera never fires the onbeforeunload event. This creates a serious problem with attempting to save page state prior to a user leaving your page.

Browser support aside, I believe that the onbeforeunload prompt is not an ideal way to protect the user from lost work (or unsaved page state). Humanized has argued, and I agree, that an undo operation is much easier on the end user than a warning message. The strange thing is, Gmail could save the draft in a synchronous Ajax request in the onunload event. They aren’t using the prompt to save Opera users from losing their drafts, since the Opera web browser doesn’t even fire the onbeforeunload event. (Interestingly enough, they are using some sort of browser history management to fire a warning to the user when they press back, or forward, in Opera — but Reload can’t be caught using this method, so your could draft email be lost).

From a User Interface design standpoint, I would recommend just sticking with onunload. You can still perform your synchronous Ajax call in the method to save the state of your page, so that the user can later resume their state or undo the operation. (Except for Back/Forward/Refresh in Opera, until they support a better onunload or any onbeforeunload). The onbeforeunload prompt is an unnecessary evil, and doesn’t do much besides annoy the end user with another warning message and a mouse click.

Cross Domain XHR with Firefox 2

Zach Leatherman — Thu, 30 Aug 2007 23:40:20 +0000

By now know you know that trying to do an XMLHttpRequest (XHR or AJAX) call to a domain that is different from the domain of the hosted JavaScript in Firefox will throw an exception.

Error: uncaught exception: Permission denied to call method XMLHttpRequest.open

If you don’t want a history of the past solutions, page down to see the final solution.

The web has solutions to this problem, but most of them involve changing your JavaScript code, which I thought to be less than ideal. A common solution involves setting the UniversalBrowserRead security property in your JavaScript code [Dion Almaer, of Ajaxian fame]:

netscape.security.PrivilegeManager.enablePrivilege('UniversalBrowserRead');

The problem with that solution (obviously) lies in single browser proprietary JavaScript polluting your code. And you have to set this property inside the scope of any usage (ie: inside your library file that does your AJAX calls and inside your callbacks, etc).

Why can’t it just be as easy as Internet Explorer? They just pop-up a little security dialog asking you if you want to allow this access (which is also what the enablePrivilege function does as well).

Another solution involves setting the capability.policy.default.XMLHttpRequest.open preference inside your prefs.js Firefox preference file [Mike Dirolf]. This worked as desired and allowed the AJAX call, but anytime you attempt to access the resulting XML you received a nice exception as well. It turns out this is the solution we wanted, it’s just incomplete.

The Final Solution

Close Firefox. It will overwrite your changes to the prefs.js file if you have it open.
Optional step: This approach will open up your Firefox security quite a bit, so I’d recommend setting up a separate profile in Firefox to use when testing. It will not pop up a security dialog when a cross-domain AJAX call is made.
Find your prefs.js file. In Windows, it is typically located in the C:\Documents and Settings\{YOUR_USERNAME}\ApplicationData\Mozilla\Firefox\Profiles\{YOUR_TEST_USER_PROFILE_ID}\prefs.js

Open it up and add the following lines:

user_pref("capability.policy.default.XMLHttpRequest.open", "allAccess");
user_pref("capability.policy.default.CDATASection.nodeValue", "allAccess");
user_pref("capability.policy.default.Element.attributes", "allAccess");
user_pref("capability.policy.default.Element.childNodes", "allAccess");
user_pref("capability.policy.default.Element.firstChild", "allAccess");
user_pref("capability.policy.default.Element.getElementsByTagName", "allAccess");
user_pref("capability.policy.default.Element.tagName", "allAccess");
user_pref("capability.policy.default.HTMLCollection.length", "allAccess");
user_pref("capability.policy.default.HTMLCollection.item", "allAccess");
user_pref("capability.policy.default.Text.nodeValue", "allAccess");
user_pref("capability.policy.default.XMLDocument.documentElement", "allAccess");
user_pref("capability.policy.default.XMLDocument.getElementsByTagName", "allAccess");
user_pref("capability.policy.default.XMLHttpRequest.channel", "allAccess");
user_pref("capability.policy.default.XMLHttpRequest.open", "allAccess");
user_pref("capability.policy.default.XMLHttpRequest.responseText", "allAccess");
user_pref("capability.policy.default.XMLHttpRequest.responseXML", "allAccess");
user_pref("capability.policy.default.XMLHttpRequest.send", "allAccess");
user_pref("capability.policy.default.XMLHttpRequest.setRequestHeader", "allAccess");

This code was copied (with the exception of 1 line) from a source repository at [kryogenix.org]
used in jackfield. It wasn’t intended to be used for this purpose, but it works.

If you still get Error: uncaught exception: Permission denied to call method _________ errors, you can add the method to your prefs.js. I would appreciate a comment with any commonly used methods not included above. Thanks.

Update: Because this article is deprecated (applies to an older version of Firefox), I’m updating the blog title in the interest of minimizing the number of disappointed users. Some might think this is a stupid thing to do, since it’s the most popular page on my blog, but I’m more interested in helping people than getting traffic.

Wash your mouth out with SOAP and the YUI Connection Manager

Zach Leatherman — Wed, 09 May 2007 22:56:58 +0000

Now you’ve done it. You watched an R rated movie while your parents weren’t looking and used some of your newfound acquired colorful language in front of them. Your mom goes for the Dial Liquid Soap, she’s going to wash that profanity right out of your dirty little mouth.

Harsh? Maybe, but I couldn’t say the word ‘Bastards’ without feeling Dial on my cleansed taste buds. Maybe I should take legal action against the cinematic classic ‘Hot Shots.’

What are we here for? Not liquid soap, perhaps some profanity. But really, you want to use the SOAP web services protocol with your Yahoo User Interface application, in particular the Connection Manager component. This tutorial assumes you are at least familiar with the examples provided on the Yahoo! UI Library: Connection Manager website.

How is SOAP different than any other AJAX call using the Connection Manager? Well, normally, when you perform an HTTP Post AJAX call, it is passing in a key-value pair string encoded with the normal key=value&key2=value format. But when doing a SOAP call, we want to post an XML SOAP Envelope to the server instead of this key-value pair string. In case you’re reading this article and don’t know what a SOAP Envelope looks like, I’ll post a sample here:

Of course, it is beyond the scope of this article to argue whether a REST or a SOAP format for your Service Oriented Architecture is a better choice. You’re stuck with SOAP, otherwise you wouldn’t have read this far.

So, let’s post our SOAP Envelope using the YUI Connection Manager with the code provided below:

var targetUrl = 'http://www.zachleat.com/postToServer.php'; // this is not a real URL
 
var callback = {
	success: function(o)
	{
		var root = o.responseXML.documentElement; 
		if( root.getElementsByTagName( 'faultstring' ).length > 0 ) // faultstring is a standard SOAP error message format
		{
			var faultstring = root.getElementsByTagName( 'faultstring' )[0].firstChild.nodeValue;
			var detailed = '';
			YAHOO.UP.util.each( root.getElementsByTagName( 'detail' )[0].childNodes, function( j, textNode )
			{
				if( textNode.nodeValue != null ) detailed += textNode.nodeValue;
			} );
			// do something with your error message stored in the faultstring variable, with a more detailed message in the detailed variable
		} else {
			// this is an actual success.
		}
	}, 
	failure: function( o )
	{
		// do something with your failure.
	}
};
 
var message = ';
 
// we need to set our own header.
YAHOO.util.Connect._use_default_post_header = false;
YAHOO.util.Connect.initHeader( 'Content-Type', 'text/xml', false );
var ajaxCall = YAHOO.util.Connect.asyncRequest( 'POST', targetUrl, callback, message);

I hope this code helps some of you bastards.