Re: [whatwg] Modifying the URL inside beforeunload event

On 14/11/2014 6:39 PM, Ian Hickson wrote:
> 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.

I appreciate your patience. Bare with me a little longer. I understood 
everything you wrote below up until the last sentence: "the doc gets 
discarded, without affecting the (mutated) session history entry." I 
think you meant that the mutated session history entry gets kept, but to 
be certain I understood you correctly I'll rephrase the question:

 1. Say we have two pages: OLD and NEW.
 2. OLD contains a link to NEW.
 3. I start off on OLD and click on the link.
 4. The above logic runs ("beforeunload" event handler changes the URL
    using history.replaceState() from OLD to CHANGED)
 5. The browser navigates to the NEW page.
 6. Now... when the user examines the URL associated with the
    back-button, should he see OLD or CHANGED?

Based on what you wrote above, I think the user should see CHANGED. Did 
I understand you correctly?

> 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.

You mean you have a single-paged application and rewrite the underlying 
page asynchronously? How do you deal with needing to load different 
Javascript files per page? I guess you could simply load all the JS 
files all your pages would ever need, but I assume you do something a 
little more sophisticated.

Thanks,
Gili

Received on Saturday, 15 November 2014 01:09:28 UTC