[whatwg] history.back()

On Wed, 27 Jan 2010, Darin Fisher wrote:
> 
> I think that location.hash = 'a' should synchronously add "#a" to the 
> session history, or at least it should appear to the web page that it 
> was added synchronously.
> 
> [...]
>
> That said, I think it would be good for location.hash = 'a' to interrupt 
> the history.back() request.  The net result being that "#a" is appended 
> to session history, and the history.back() request is discarded.
>
> [...]
> 
> I'm trying to treat history,{back,forward,go} as a UI command to the 
> navigator.  Synthesize the user clicking on the corresponding 
> back/forward buttons.  UI actions typically do not get dispatched during 
> JS execution (ignoring window.showModalDialog of course).
>
> [...]
> 
> I agree that we should not change the location without traversing 
> history.
> 
> I'm arguing for making history.{back,forward,go} start out by 
> dispatching a task to then run the history traversal algorithm.  So, 
> history.back() would never change the location synchronously.

I've tried to spec this. There is a high risk of compatibility issues, so 
I would very much welcome feedback from implementors who try to implement 
this.

The main goal of the change here is to make it possible to implement this 
(if not completely sanely, but it's the Web, there's only so much I can 
do) in a situation with each browsing context having its own process, as 
seen to some extent in IE and Chrome, and as is being examined by other 
browser vendors also.


While I was at it I made 'hashchange' and 'popstate' fire completely 
async, and gave 'hashchange' context information to get around the problem 
with it firing async (where it could e.g. fire twice for the same URL, 
because the navigations get processed before it fires).


On Thu, 28 Jan 2010, Olli Pettay wrote:
> On 1/28/10 7:15 AM, Darin Fisher wrote:
> > 
> > That said, I think it would be good for location.hash = 'a' to 
> > interrupt the history.back() request.  The net result being that "#a" 
> > is appended to session history, and the history.back() request is 
> > discarded.
> 
> Really? What if iframe has been navigated lately and something calls 
> history.back() (to load previous page in iframe), but right after that 
> top level page calls location.hash = "foo";

Per spec now, any code along the lines of:

   history.back();
   location.hash = "foo";

...will cause the back() to be a no-op. This is definitely incompatible 
with legacy implementations; the question is whether there are pages 
depending on it.

If we can't do this asynchronously, it's going to really suck for 
multiprocess UAs, so I think it's worth trying to find a solution here, 
even if there is a back-compat risk. In practice I don't think the risk 
is as high as it could be, because interop is pretty poor in this area 
already; in particular, Chrome does things that are quite drastic when 
given code like the above, and Chrome developers aren't aware of having 
received bugs about it.

Again, please send feedback on this. The diff is:

   http://html5.org/tools/web-apps-tracker?from=4631&to=4632

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

Received on Thursday, 28 January 2010 17:32:20 UTC