Re: [whatwg] Modifying the URL inside beforeunload event

On Fri, Nov 14, 2014 at 6:04 PM, Ian Hickson <ian@hixie.ch> wrote:

> On Fri, 14 Nov 2014, cowwoc wrote:
> >
> > 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?
>
> Unless I'm missing something, I'm pretty sure it should be CHANGED. I see
> no reason why it would make a difference whether the replaceState() call
> happens before or during the beforeunload handler; in either case, the
> history traversal hasn't happened yet.
>

I'm the chromium engineer who declined the bug originally, sorry for being
late to the discussion.  I agree that the url being CHANGED is probably the
most logical result. However, all of the browsers I tested (chromium,
webkit, gecko, an older IE) showed OLD, though gecko showed CHANGED if
steps 5 and 6 are repeated.

I'm fine with this interpretation and changing the chromium behavior, but
it's not the consensus implementation right now.
~Nate


>
>
> > > 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?
>
> More or less. Google Calendar is an example of the kind of app I mean
> (though obviously that's not one I've written myself!).
>
>
> > How do you deal with needing to load different Javascript files per
> > page?
>
> You either load it all asynchronously, or you load it on-demand. Depends
> on your precise setup. Generally speaking I find that most of the logic
> ends up on the server; there's just not that much to do purely on the
> client side. Obviously that depends on how sophisticated the app is. If
> it's a game with crazy visuals, there's comparatively more client-side
> code. Similarly, if you have a rich-text editor with offline capabilities,
> there's obviously much more client-side code.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

Received on Tuesday, 9 December 2014 23:07:55 UTC