Re: close the browser

On 24 Jun 2014 at 20:09, Stuart Dallas <stuart@3ft9.com> wrote: > On 24 June 2014 19:53, Tim Streater <tim@clothears.org.uk> wrote: > >> On 24 Jun 2014 at 17:43, Stuart Dallas <stuart@3ft9.com> wrote: >> >>> I'm yet to hear of a legitimate reason to want some PHP to execute when >>> a user closes the browser, so chances are there's a better way to achieve >>> what he actually wants. >> >> I use that in my app. If the user has been typing into an editing window, >> and then closes the browser window, they will expect that what they typed >> will show up again when they restart the app. I use the onbeforeunload >> event in the browser to handle this, along with a (rare) synchronous ajax >> request to run a PHP termination script. >> > > That's certainly a solution to that problem. In the past I've used > onbeforeunload to check if the user has edited anything and display a > confirmation dialog, but never to make a request to the server. I'm > struggling to identify why, but doing that just doesn't sit right with me. > It may be because I've heard that the event is not reliably thrown by all > browsers in all situations as a result of various spammy behaviour by dodgy > sites in the past. That view may well be out of date now. Have you seen any > problems like that? Well in my case I control which browser is used as I launch it for the user. As this app is mainly for OS X I'm using Safari. Safari behaves thus: if you have an onbeforeunload handler, but exit it without executing a return, the dialog box does not appear (which suits just fine). However I'm now minded to wonder whether that's just a quirk of Safari, and as I'll want to be using Chrome for the Win7 version, I should perhaps test that. @Jim: I want to protect the user in the same way that something like Word does, although that is based on periodic saves. As it is, only a crash of Safari will stop me saving the actual state - and there's other stuff to save too, such as window position and size (not implemented yet). As I see it, if a text editor like TextWrangler can restore state (including edits) after a restart under pretty much all circumstances, why shouldn't I aspire to do the same. As a user of the app, it's what *I* would expect to happen. -- Cheers -- Tim