Hacker News Reader

Comment by Mahn | Hacker News Reader

IMHO, no modern JS developer should ever need to create a blocking alert or prompt; the reason the native alert or prompt functions block is because, well, they are not designed for what the web is today.

View on HN

Just out of curiosity, if you had a web app like Gmail, and your user accidentally went to close their browser window with an unsaved email half done, how would you plan on warning them without blocking events?

Save it in drafts and notify them when they come back.

So Facebook and Twitter should also save drafts of posts you were going to make? What if latency is non-trivial, or connection is lost? Do I also want to send ajax posts for drafts every second to ensure that as little as possible is lost? A lot of this is mitigated by a very simple

  confirm("Are you sure you want to leave?");

Twitter actually does save drafts in localStorage.

Yeah but for all the times when I really do want to leave, now I have to annoyingly click "Yes" in a dialog I didn't expect in the first place.

I like the localStorage solution for drafts much better.

You use the onbeforeunload event, which doesn't block the event thread. (EDIT: actually it does, just not while JS code is executing, unlike alert().)

In fact, the HTML5 spec permits browsers to disregard the normal blocking behavior of alert()/confirm()/prompt() (making them no-ops) while this event is being handled: https://developer.mozilla.org/en-US/docs/DOM/window.onbefore... the dialog box is open

I managed to break that link somehow and can no longer edit it, here's the correct one: https://developer.mozilla.org/en-US/docs/DOM/window.onbefore...

Reply on news.ycombinator.com