Re: Ajax Back/Forward History problem document state by document.save()

On Sun, 20 Nov 2005, Karl Pongratz wrote:
> 
> Hence I suggested document.save() which saves the altered document to 
> the web browser cache and at the same time gives it a new URI without 
> reloading anything. (The altered document is a web page where a 
> javascript array has been loaded via xmlhttp and from which new content 
> has been created via DOM scripting)

Saving the entire DOM is unfortunately not possible. Several objects that 
can be found in the DOM -- most importantly, plugins -- cannot be cloned.


> I repeat, the URI which is passed as an argument to document.save() 
> serves the purpose to identify the document(resource), the same as 
> traditional resources.

Yeah, one of the suggestions being considered for pushState() is the 
ability to also associate a URI with the state so that it can be 
bookmarked. (I haven't gone through the pushState() feedback yet.)


> In this case it would be possible to bookmark a page or click the web 
> browser reload button and yet the user will get the right document.

Not necessarily. The state can be _extremely_ complicated.

> You suggest pushstate which I don't clearly understand yet, however, the
> following paragraph states:
> "Typically, the history list will consist of only URIs. However, a page can
> add <http://whatwg.org/specs/web-apps/current-work/#pushstate> state objects
> between its entry in the session history and the next ("forward") entry. These
> are then returned to the script
> <http://whatwg.org/specs/web-apps/current-work/#popstate> when the user (or
> script) goes back in the history, thus enabling authors to use the
> "navigation" metaphor even in one-page applications."
> 
> I am not sure about "returned to the script"

It means an event fires and the object is passed to the script that fires 
during the event, so that the script can reconstruct the state.


> I don't really wont any script to be executed when the user navigates 
> through the web browser history.

Script executes in the step forward, it seems logical that script should 
execute in the step back. You can't just remember the DOM: in many cases 
the state is server-side, and going back requires that the server be 
notified and/or that state be fetched from the server again.


> I also want to note that I wanted to propose something simple that 
> solves the emerging Ajax web application web browser history problem, 
> something that is strongly tight to the xmlhttp request object and would 
> be easy to implement by user agent vendors. Solve a big problem with 
> little effort, though I am definitely not sure if document.save() would 
> be easy to implement nor if it is actually the best solution. However, 
> the WebForms and WebApplications draft specification goes far beyond 
> that and will probably require a huge effort to be implemented compared 
> to a single document.save() or similar function.

The pushState() idea would be implementable without any of the rest of the 
draft. If saveDocument() were to be added to a spec, it would surely be a 
spec bigger than just saveDocument(), in much the same way.


On Mon, 21 Nov 2005, Kenny wrote:
> 
> My big concern with both document.save and pushState is security. The 
> pushState method has a recommendation for security, "It is suggested 
> that to avoid letting a page "hijack" the history navigation facilities 
> of a UA by abusing pushState(), the UA provide the user with a way to 
> jump back to the previous page (rather than just going back to the 
> previous state).", but if this is not implemented, malicious developers 
> could take control of the users navigation.

Indeed, if implementors ignore security concerns, then there will be 
security risks.


> The document.save method has the added risk that someone could put
> URI's in the history to pages the user never visited and dose not want
> to visit without them knowing.

I am not sure this is a security risk; could you expand on this?


On Mon, 21 Nov 2005, Karl Pongratz wrote:
> 
> In case that the document DOM must me recreated by the developer it 
> sounds similar to an onload event handler. If I remember correctly Eric 
> Costello mentioned somewhere that such an approach causes timing 
> problems. As more complex the DOM of a document as more problems it 
> probably causes.
> 
> Does pushState() solve this problem?

I'm not sure what the problem to which you refer is.

pushState() doesn't require any more of a change to the DOM on returning 
to that state than it requires when moving away from that state.


On Mon, 21 Nov 2005, L. David Baron wrote:
> 
> I think a better solution than extra user interface is a solution like 
> what popup blocking uses:  pushState (like window.open these days) 
> should only be allowed while handling a user event like a click or a 
> keypress that expresses the user's choice to navigate to a different 
> state (like navigating to a different page).

Unlike window.open(), it is possible to call pushState() without the user 
knowing. If pushState() was called every time the user clicked or pressed 
a key, that could lock the user out of his history just as effectively as 
if the method was called on a timer. (Especially considering that the kind 
of things this is likely to be used with is pages that the user stays at a 
long time, interacting with it.)

I've added a paragraph listing your idea (and others), but I think the 
idea I listed is the only one that will actually guarentee the user is 
safe from evil script.


On Mon, 21 Nov 2005, kenny heaton wrote:
> 
> Back on topic - if pushState was only able to save the current state of 
> the current page, so developers couldn't write something unknown into 
> the users history, and what you suggest was implemented, so a developer 
> could only call pushState in response to user input, it seems to me that 
> it would be safe. But there are still so many issues with bookmarking 
> etc... because there is not a actual URL that points to the page. But 
> allowing developers to write an actual URL into the users history seems 
> to give the developer unwanted control over the user's browser.

Well, you never have a guarentee that the page your bookmark is the page 
you'll go back to. Not sure we can do anything about this. I'm also not 
sure that we need to do anything about it, to be honest.


On Tue, 22 Nov 2005, Sylvain Hellegouarch wrote:
> 
> Not to say we should end up with a new icon button saying "back/forward 
> friendly" like we have "tabless friendly" or "css friendly" but maybe 
> give hints on what should be the expected behavior for an application 
> using Ajax. But then the targets are not only developers but (and in 
> fact mainly) browser vendors.

Yeah. I'm not sure what those hints should be yet, but I agree that we 
should have something that describes best practices.


> > I wonder what everyone thinks of that, or do web developers really 
> > need the ability to save the state of a page into history so the user 
> > can go back to it?
> 
> I must say I don't like the idea at all and it sounds like a huge 
> security/spamming hole as most developers won't do it which could even 
> be worse in terms of usability.

Authors are already trying to control the back/forward buttons (using 
iframes). All that this API does is make it easier to do well.


On Tue, 22 Nov 2005, Anne van Kesteren wrote:
> 
> It saves the DOM.

It doesn't save the DOM. It saves whatever is passed to it.


On Tue, 22 Nov 2005, Laurent wrote:
> 
> I think we shouldn't mix up the two case of the use of a browser : the 
> navigation throw web pages, and the use of a web application. After all, 
> a web application is like any other software : the user do some actions, 
> and he wants to undo/redo its action in this web app.

Right. Except that the distinction between "web page" and "web app" is 
very vague. Is Amazon a Web app or a Web page? Is Google's search engine a 
Web app or a Web page? Is Microsoft's live.com a Web app or a Web page?


> I think that all users actions (so, to summary, all DOM mutation that 
> the developer do) should be stored, not in the browser history, but in 
> the undo/redo stack of the browser. Then the user only need to choice 
> the edit/undo or edit/redo item menu in his browser (or hit CTRL+Z, 
> CTRL+SHIFT+z) to cancel or redo an action, like in any other software. 
> (the browser could display an undo/redo button in the toolbar to improve 
> the accessiblity of this feature)

You may be interested in:

   http://whatwg.org/specs/web-apps/current-work/#undo


> To store actions in the undo/redo stack, the developer should call the 
> *state function. Or better, window object could have such function :
> 
> window.startBatch();
> //here, some DOM modification...
> window.endBatch();
> 
> startBatch() starts a "transaction". All DOM modifications are 
> registered in the transaction. endBatch() store the transaction in the 
> undo/redo stack. (The core of the HTML editor of Mozilla works like 
> this). So the browser can cancel DOM modifications or replay them.

Yeah, this isn't a bad idea. I'm not sure whether we should have an 
.endBatch() notification (as opposed to just implicitly ending it when the 
<script> ends) but it is definitely an idea worth looking at.

I've added a note to this effect in the spec's undo section.


On Tue, 22 Nov 2005, Anthony Ettinger wrote:
> 
> This may be off topic, but is there a way to save a form like a 
> temporary doc when a user is filling it out, incase of browser crash or 
> mispost.

There are some extensions in the Web Forms 2 proposal that might help 
here:

   http://whatwg.org/specs/web-forms/current-work/

But generally it's up to the Web page to handle this at the moment. The 
user agent can also cache form fields so that you don't lose data in case 
the Web server dies on you.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 22 November 2005 22:40:37 UTC