sorted by: recent | see :
popular
Content Tagged with Gotchas + ie
Rocky Shoals of Ajax Development
A year ago, I started a list of Ajax Mistakes that grew and eventually moved to a collaborative page, where other people could post or edit what they saw as issues in Ajax development.
That list focuses on basic application design mistakes when working with Ajax, such as breaking the back button and using GET and POST requests improperly.
But the specifics of Ajax development are equally perilous to basic application design. The siren’s call of the XMLHTTPRequest object can lead many brave scripters to a demise on the rocky shoals of browser limitations and bugs.
So in the interests of charting out these limitations and bugs, I’ve started another list devoted to these limitations, quirks, and bugs. It’s separated into 3 parts: Basic Browsers, IE, and Firefox.
Again, this post will live on in a collaborative wiki page for future updates.
Basic Browser quirks and limitations
- XMLHttpRequest can’t access remote servers. For some odd reason, although there are ways in javascript to send and receive data to remote servers, such as through script or iframe elements, XMLHTTPRequest cannot have a remote server as a target. This is a basic cross browser security rule that may not be immediately obvious to the newcomer to Ajax development.
- Multiple Ajax Requests are not fired in order. IE, breaking from a long tradition of ignoring independent standards, chooses to follow the HTTP 1.1 RFC 2616 to the letter, which means that IE may only have two XMLHTTPRequests open at a time; after which IE will retain an internal queue of requests which will be serviced in no particular order. Even if the requests are fired in order, the nature of the internet dictates that they will not be received in order, so never write code that assumes xmlhttprequests will be sent in a particular order.
- Firefox also has a similar albeit more liberal limitation in the number of simultaneous xmlhttprequests that may be open; however In Firefox 1.5, the developer may modify the priority of the internal request queue.
- Asynchronous XMLHTTPRequests responses will arrive in no particular order. As implied by the word Asynchronous, XMLHTTPRequest responses may arrive at any time in an unpredictable order that is ignorant of developer intent, happily executing callbacks in the random order in which they eventually wind up on the client.
- XMLHTTPRequest does not requires the use of XML. While Ajax is aptly named when it comes to asynchronous execution, it is poorly named when it comes to XML. The XMLHTTPRequest object has a useful method called responseText that delivers the straight text of the response, be it XML, JSON or just simple unadorned text. Using JSON or simple text can be much faster, easier, and more concise than XML.
- Ajax uses UTF-8. Normal forms are sent using the encoding of the parent page. Thus a SJIS encoded page will default to sending form content encoded in SJIS. Ajax submitted forms on the other hand will be sent as UTF-8. If for some strange reason, UTF-8 is not the character set of choice for the server, this will require a solution such as the server recognizing and translating UTF-8 responses to a desired character encoding.
- Ajax requests are url encoded. A bug relating to this can currently be seen on Digg.com. Submit a comment to digg, and then edit the comment to include a unicode character. The updated comment, sent via Ajax will be added to the database as the url encoded string: resulting in an odd looking url encoded comment.
- XMLHTTPRequest cannot transmit files. In a javascript heavy application, a developer might need to include the ability to send files without completely refreshing the page. XMLHTTPRequest however does not include this ability. Instead, a hidden iframe can be used to send the file, and Javascript can simply inspect the iframe. Ajax techniques can further complement this, for example the open source project Uber-Uploader can show a progress bar while uploading a file.
Firefox quirks or bugs
- Synchronous XMLHTTPRequests lock up Firefox. The XMLHTTPRequest method provides a third argument, which defines whether the Ajax requests are submitted synchronously or asynchronously. (xmlhttprequest.open(‘GET’, ‘http://www.mozilla.org/’, false);) On Firefox, setting this value to false will submit the xmlhttprequest synchronously and lock up the entire browser.
IE quirks or bugs
- XMLHTTPRequest Objects are not reused in IE. Unless the abort method is used, XMLHTTPRequest objects in IE won’t function after the first use, unlike in other browsers such as Firefox. A solution to this is to create a new XMLHTTPRequest object for each connection, although some fear this causes memory leaks, there seems to be no conclusive proof of this, as long as the known closures memory leak issue is avoided, as detailed in the next gotcha.
- IE doesn’t use cached images when Javascript inserts HTML with images. This is a general Javascript behavior, but with Ajax heavy applications that insert a lot of HTML snippets, this can lead to a lot of unnecessary image redownloading. The way to solve this is to send all images with proper Cache-Control, ETag, and Last-Modified headers. IE will request images with a ‘If-Modified-Since’ header and the server should send back a 304 header which will tell IE not to redownload the image, and use its cached image.
- Closures with circular references in IE cause memory leaks. It’s common in Ajax to use closures, however in IE if a closure has a circular reference, it will cause IE to start leaking memory. In Javascript it’s easy to create closures with circular references, so care should be taken to avoid memory leaks.
- Avoiding aggressive caching in IE – even with proper ‘no-cache’ headers, IE caches get requests – this can be solved by changing the get request query string with every request.
- IE corrupts gzipped javascript files. Although this is a more general issue with IE’s handling of gzipped content, in Ajax applications where there is a lot of Javascript, developers may be tempted to gzip their javascript to allow for faster page loading and lowered bandwidth consumption. However IE has a known bug where it cuts off downloads in mid-file, corrupting the javascript file.
- IE doesn’t cache gzipped Javascript files. Adding to IE’s poor handling of gzipped content is IE’s lack of support for simultaneous gzip and ETag cache headers. Again, this is wider scope than simply Javascript, but it means that even if IE didn’t corrupt the gzipped javascript, it wouldn’t cache it anyways.
I sometimes make mistakes, or overlook things. If you know of something that I’ve overlooked or have found something that I’m wrong about in this post, please contribute your knowledge directly to the wiki page for this list.