Re: [whatwg] Modifying the URL inside beforeunload event

On 13/11/2014 12:21 AM, Ian Hickson wrote:
> (pushing this to the top of the queue by request)
>
> On Sun, 2 Nov 2014, cowwoc wrote:
>> I would like to
>> bring https://code.google.com/p/chromium/issues/detail?id=428583 to your
>> attention. Quoting comment #9:
>>
>> I believe this is a corner case that is not adequately described. I was
>> imagining adding a clause somewhere around step 8
>> inhttps://html.spec.whatwg.org/multipage/browsers.html#unloading-documents:beforeunloadevent
>> <http://html.spec.whatwg.org/multipage/browsers.html#unloading-documents:beforeunloadevent>.
>> Specifically, clarifying what the behavior should be if an event handler
>> modifies the url.
>>
>> I believe I have a legitimate use-case (described in comment #9) for
>> needing to change the URL in "beforeunload". I am open to alternatives
>> that allow me to achieve the same end-result, but I have not found any
>> good solutions to date.
> I don't really understand what's unclear here. Can you elaborate? As far
> as I can tell this is one of the better defined interactions, since the
> unload algorithm and the pushState algorithm are pretty specific.
Hi Ian,

I wish I could invite the chromium committer (from comment #9) to join 
this conversation. Unfortunately I am unable to look up his email 
address (I fill out the captcha but the system still refuses to divulge 
the email address). 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.

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

> Generally speaking, though, for your use case you should just use
> sessionStorage rather than cookies. That's what sessionStorage is for.
>
> 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.

Thanks,
Gili

Received on Thursday, 13 November 2014 05:49:50 UTC