Where did I put the Ajax?

March 9, 2006 1:27 PM

Why do browsers store the original DOM in the browser history instead of caching the most recent version?

I'll admit up front that I haven't done much research into the question myself even though it is one I have been interested in for some time.

Anyway, based in large part on the tangential discussion in this AskMe thread, I am curious to know if there is something spec-wise that prohibits storing the latest DOM in the history cache. The current behavior of reverting to the original, page-load DOM when going back through the browser history poses some prickly issues when doing AJAX-like DHTML gimcrackery. If there is nothing prohibiting this, is it not more intuitive to bring the user back to their most recent state? After all, browsers remember information relating to the viewport and input fields—why should the DOM receive such a bad rap? Should I start lobbying at Mozilla?

posted by Fezboy! to computers & internet (12 comments total)

I think they cache at the page level, not at the level inside the document. So if the document changes while loaded, it's not saved. It'd be wise to include DOM changes in history, but that leads into another trap: Is there a pitched argument somewhere about whether the history should include changes in the current document, or whether there should be a separate browse history for that?
posted by mikeh at 1:33 PM on March 9, 2006

It's because they cache the HTML document, not the DOM.
posted by chrismear at 2:17 PM on March 9, 2006

Then I guess my refined question is, is there something in some W3C-esque spec that suggests caching the HTML instead of the DOM? If not, is there something in the history of browser development that would suggest caching the HTML code instead of the DOM representation (other than there not being a DOM in the dark ages of the Web)? Is it inertia that keeps us on the same track or are there sound technical reasons for avoiding caching the DOM? Where are these issued being discussed in a formal-ish setting? Does the discussion involve individuals who have some standing with the decision-making aparatus or is it just a bunch of schmoes like myself who are interested for 'academic' reasons?

I am trying to avoid the heavy hand of thread moderation, but thought I could clarify what it was that made me ask the question. Thanks for participating so far. I am gaining some perspective on the issue which will facilitate further research.
posted by Fezboy! at 2:32 PM on March 9, 2006

I think the DOM changes too often for this to be feasible. Rewriting the cache on every DOM change would slow everything down too much, and DOM changes are already too slow because of updating the display. Saving form input only requires a cache rewrite on submit, and it can be done while the browser is waiting for a server response, so it's not a noticable lag.
posted by scottreynen at 3:27 PM on March 9, 2006

Firefox 1.5 caches the modified DOM for the last 5 or so pages per tab (depending on available memory).

Previous versions of Firefox just cache the HTML and then rebuild the DOM on navigation, but that's slow, so they introduced the "bfcache" to make page navigation instantaneous in most cases.

The pageshow and pagehide events were introduced specifically to deal with this, because load and unload no longer get fired when the user navigates using the Back and Forward buttons.

Occasionally you'll run into pages that look weird when you hit the back button because of this -- typically you'll see a DHTML menu being displayed when it should've gotten hidden. I've never run into anything that wasn't harmless, though.
posted by nmiell at 3:41 PM on March 9, 2006

Also, Mozilla describes this Firefox behavior here.
posted by nmiell at 3:43 PM on March 9, 2006

Interesting. I knew that DOM caching was added in Firefox 1.5, but I wasn't seeing it actually working in AJAX apps. For instance, here is an edit-in-place CSS/AJAX example. If you click on the text, it modifes the DOM to include a text input box. Yet in FF 1.5, if you click onto another page (in your bookmarks) and then click back, the DOM is reverted to the original. Not cached at all.

nmiell's link helps explain why, in part. It says FF doesn't cache if "the page uses an unload handler". Well, a lot of AJAX sites, including the one above, use the prototype.js script to handle the AJAX basics. And that script includes an unload handler to "prevent memory leaks in IE". So presumably that's why it isn't being cached in this case.

To the original question of where this stuff is discussed: Bugzilla, for Firefox at least. But it's generally unsatisfying... what you think would be an obvious fix invariably either violates some obscure standard or will break critical existing pages that have worked since Netscape 1.0.
posted by smackfu at 4:06 PM on March 9, 2006

If you do want to see the current dom on any page try something like this MODI V2.
posted by grex at 4:07 PM on March 9, 2006

I think the DOM changes too often for this to be feasible. Rewriting the cache on every DOM change would slow everything down too much, and DOM changes are already too slow because of updating the display.

I was thinking the same thing, but you actually only need to update the cache when the user navigates away from the page, so it shouldn't be that bad.
posted by smackfu at 4:08 PM on March 9, 2006

I was thinking the same thing, but you actually only need to update the cache when the user navigates away from the page, so it shouldn't be that bad.

The DOM isn't a property of the browser, it is a property of the page and is created anew for each page displayed. As such, there's nothing preventing you from just keeping the DOM around when the user navigates away from the page.

There is no cache to update, because the cache is just caching existing DOM trees.
posted by nmiell at 8:40 PM on March 9, 2006

You're starting to get into one of the weird avenues of programming in the new, more interactive style.

I'd imagine that the reason that DOM caching hasn't been addressed is that it's not clear what problems that would really fix, at least in most cases.

It seems like it'd work ok for basic kinda webpages with a little ajaxy flash thrown in, but if you're a programmer who is really worried about persisting a user's state, you shouldn't really rely on the browser cache -- you'd wanna setup a session on the server side and restore it if people return to the page. Relying on browsers for all kinds of state information... well, that's when things can get dicey.

You can kinda think of it as analogous to asking "why doesn't a flash applet's state get cached?" I guess it could... but 99% of the time it doesn't matter and for the other 1%, clever programmers know how to work around it.
posted by ph00dz at 9:04 PM on March 9, 2006

nmiell has the best reason so far. The sticky point is "how do the load/unload handlers work?"

When a user navigates (or wants to navigate) away from a page the page's javascript context needs to be frozen. I can't operate in the background. Traditionally, the unload event allows a programmer to catch the transition and cleanup. But if the context is frozen and the page is removed from history, the unload handler would be called way to late for any sensible user interaction.

Also greatly complicating matters are the large number of AJAX/AJAXy pages that render 90% of the content dynamically using inline Javascript and load events. What happens when a user hits the back button? For your app it may make sense to unfreeze the context and continue on, but for others it may make sense to start from scratch (ie: a news montage would want to fetch the latest content).

There is no easy solution for load/unload handlers, preserving DOM, and freezing the javascript context. Mozilla has taken a route that would cause the least number of sites to break, and I think they have the right strategy.

The ball's in your court. There is no reason I can think of for why you shouldn't use load/unload handlers to save your own state. Do some AJAXy things on unload to store the state on the server, and then have load check real quick before redrawing the page.
posted by sbutler at 10:31 PM on March 9, 2006