W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2014

Re: [whatwg] Modifying the URL inside beforeunload event

From: Ian Hickson <ian@hixie.ch>
Date: Fri, 14 Nov 2014 23:39:34 +0000 (UTC)
To: cowwoc <cowwoc@bbs.darktech.org>
Message-ID: <alpine.DEB.2.00.1411142333230.7063@ps20323.dreamhostps.com>
Cc: WHATWG <whatwg@whatwg.org>, Michal Zalewski <lcamtuf@coredump.cx>
On Thu, 13 Nov 2014, cowwoc wrote:
> 
> In any case, the question seems to be whether history.replaceState() 
> should be honored in "beforeunload". Individually, each one is very well 
> defined, but I don't see any discussion of what should happen when the 
> two are used together.

You just follow their algorithms. I don't understand what needs to be 
additionally specified. Can you elaborate?

The beforeunload algorithm is here:

   https://html.spec.whatwg.org/#prompt-to-unload-a-document

You get to step 4, then run script, which calls replaceState's algorithm:

   https://html.spec.whatwg.org/#dom-history-replacestate

The session history entry gets updated. Then you return to beforeunload, 
starting at step 5. Eventually 'salvageable' gets set to false, and much 
later (when running the 'unload' algorithm) the doc gets discarded, 
without affecting the (mutated) session history entry.


> Are you saying that history.replaceState() should succeed or fail in 
> this case?

It should do what is specified. I'm not sure what "succeed" or "fail" 
would mean in this context.


> > If you don't want the tabId to be shared, you shouldn't put it in the 
> > location bar in the first place -- removing it from the history is too 
> > late, because people copy and paste URLs from the location bar while 
> > the page is up. You could replaceState() during page load, but I would 
> > generally much more recommend sessionStorage for this purpose.
> 
> Using sessionStorage alone wouldn't work because the goal of this 
> exercise is to send the server a different authentication token per 
> browser tab. I can store these tokens in the sessionStorage (in fact, I 
> do) but that's not enough because the browser still needs to send the 
> token to the server with each request. I hope this clarifies my dilemma.
> 
> http://stackoverflow.com/a/26901232/14731 explains how my current 
> implementation works. It's very lengthy and ugly so I'm more than happy 
> to entertain alternatives.

Personally the way I build apps these days is to just serve static files 
over HTTP, and do all the dynamic stuff over WebSocket, which would 
sidestep all these issues.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 14 November 2014 23:39:59 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:32 UTC