That AJAX pitfall in the quest for interaction
back
Next article:
AJAX calls from popups do not work on Firefox
view
I have had a lot of feedback lately from people who stumbled on to an old article
I wrote regarding the drag and drop problem when using
Scriptaculous with AJAX on Internet Explorer. They were thanking me for saving them time
and effort in tracking down the problem, which is a good thing because it took me three days to
get to the bottom of it, and there is no point for others to go through the same
painful experience.
The purpose of this article is simply a slight elaboration on the original theme, that
in my continuing quest in Ruby on Rails and Scriptaculous, I have discovered that the
above problem is not confined to Internet Explorer only, but in Firefox, and possibly
all other browsers too.
For an experiment, let's say you have a <div> element foo, which is
refreshed dynamically by an AJAX method called update_foo():
<div id='foo'>
<%= render :partial => 'report' %>
<%= inplace_editor_field 'form','field' %>
|
</div>
<%= link_to_remote 'Update foo', :update => 'foo', :url => {
:action => 'update_foo'
} %>
|
|
You can get Firefox to crash most spectacularly in the above scenario once the AJAX call
is made. This is due to the fact that each time the foo element is refreshed, it will
re-define the block of script in pink, and this in turn causes new inline editor element
to be created on the fly and on top of the existing DOM. In fact, you can get it to crash
quite reliably with just about any bit of creative Javascript in the pink block.
All it takes to get it to work is to move the Javascript block outside of the section
which will be dynamically refreshed by an AJAX:
<div id='foo'>
<%= render :partial => 'report' %>
</div>
<%= link_to_remote 'Update foo', :update => 'foo', :url => {
:action => 'update_foo'
} %>
|
<%= inplace_editor_field 'form','field' %>
|
|
So the moral of the story is, when you dynamically refresh portions of the
screen using AJAX, you have to take extreme care to ensure new elements injected
into the target element do not in any way upset the overall structure of the page (i.e.
its document object model, or DOM). There
is massive potential for memory leaks with AJAX, as most supporting Javascript
libraries latch on to the onunload event of your page to free up allocated
resources, and this event is never fired in AJAX calls. You therefore run the risk
of piling on top of the DOM until it implodes. At best, the error is reported
in some cryptic fashion (as in Internet Explorer), at worst, the browser just
crashes without any chance for you to do a post mortem (as in Firefox).
I have found that AJAX rendering is best suited for small independent stateless
form elements, or static html text. It is not suitable for dynamic html elements, and
it can not be used to upload binary data (like an image or a PDF). These factors
influence the design decisions you will have to make when architecting the
web page and its interaction with the end users.
back
Next article:
AJAX calls from popups do not work on Firefox
view
|
