Ones and Zeros: For The Love of God, Montressor!

For The Love of God, Montressor!

July 03, 2004	Computers and Software
Surfin' Safari tells us of the great interactive content they're implementing in Safari 2.0 which will implement the selection property and other items for Dashboard widgets. One thing I really hate about using a web-based content system (and web based mail) is that if I navigate away from a page (or close it), it doesn't warn me that I am about to lose unsubmitted content. This feature hit word processors in the early 1980s but since browsers are display apps, it's not part of the metaphor. But they're not just apps that display data anymore. So here, before I am bricked up behind the wall of this browser editing window, I enter my plea: Oh, please let these improvements mean that we'll get a dirty bit for forms. And let them port the behavior backwards through a user preference and a default dialog to warn me if I've done something to navigate away from an unsubmitted changed form. I don't want to lose any more webtomail, gmail, or Movabletype posts because I didn't get warned that closing a closed tab or minimized browser window would silently throw out my work. For the love of God, Montressor! Yes, for the love of God.
.:Posted by Michael on July 3, 2004 4:37 PM:.

You should be able to do it via JavaScript. on page load, set formChanged to FALSE, and for all elements, add onChange="formChanged=true". For , onSubmit="formChanged=false"; And as the last bit, for the tag, add: onUnload="if (formChanged && !confirm('Are you sure you wanna lose this precious input?')) return false;".

Disclaimer: not tested in real life, but should give you the general idea.

.:Posted by tfr ( total) on July 3, 2004 5:47 PM:.

Oops, not-so-unexpectedly it cut the HTML tags in the previous comment. the onSubmit event should be for the FORM tag, ofcourse, and the onUnload event for BODY.

.:Posted by tfr ( total) on July 3, 2004 5:49 PM:.

The problem with the above-mentioned JavaScript solution is that you can't reliably prevent the page from unloading (returning false doesn't do it). This is by design, since you can imagine what more shady websites would do with the ability to prevent you from closing the window or navigating elsewhere.

So in the example given, the user will see the confirm popup, but the page will unload regardless of what their selection is.

Now in IE for Windows, you can use the onbeforeunload event to achieve this, but this doesn't work in any other browsers to my knowledge.

I think the original suggestion to have something like this be managed by the browser (not the webpage being visited) makes a lot of sense.

.:Posted by Jonathan ( total) on July 3, 2004 8:30 PM:.

Just a side note. I used to use that phrase from the Cask for keyboard validation (I type about 120 WPM, and type certain phrases to get the "feel" of a new keyboard). At one time, it was my favorite short story :) Was weird seeing it in type again, elsewhere than one of my shell windows.

.:Posted by Doccus ( total) on July 4, 2004 7:40 PM:.

Would definitely be cool to have the browser handle this. But in the meantime, the good news is that onbeforeunload is supported in the recent 1.7 release of the Mozilla browser...
http://www.mozilla.org/releases/mozilla1.7/README.html#new

That takes us a step closer to being able to use that approach (happily, most non-IE browsers already do a fairly reliable job of restoring unsubmitted form content when you click the back button)...

Speaking of Mozilla, I'm hoping that the new contenteditable features planned for Safari 2.0 will work alongside the designmode feature supported by Mozilla's Midas. Midas finally brought us a cross-platform way to do WYSIWYG editing in forms. Would be nice if that method also works in Safari rather than having to choose between supporting either Mozilla or Safari, or coming up with a more complex way to support both...

.:Posted by Josh Clark ( total) on July 5, 2004 7:21 AM:.