Havoc Pennington Reporter
	Description • 24 years ago

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.14-5.0smp i686; en-US; m17)
Gecko/20000808
BuildID:    M17

I frequently type a long message into a form, then (being an
Emacs user) type Alt-Q to justify the paragraphs, and Mozilla
exits without asking for confirmation. This is a long-standing
gripe with Communicator I've heard many people (Emacs users anyway)
mention.

Suggested solution is to ask for confirmation on exit if a form
has been modified but not submitted. It's quite frustrating to lose
data in this way, and unexpected since most apps do ask for confirmation
if you have unsaved changes.

	Matthew T (active 1999-2002)
	Comment 1 • 24 years ago

Yes! I was meaning to submit this myself. I see this regularly at the cafe, where 
users compose a message in their Webmail account, then accidentally close the 
window and lose it.

Even Cooler would be to do what any other app does -- prompt to save the page. 
Something like `Do you want to save changes you made to this page, for use next 
time you visit?'  ( Don't Save )   ( Cancel ) (( Save ))

	leger
	Comment 2 • 24 years ago

Reassigning from bdonohoe to hangas

	hangas
	Comment 3 • 24 years ago

Sending to German for confirmation (pun intended).  Please return to me if this 
should be fixed.

	german
	Comment 4 • 24 years ago

this would be great idea for improvement for the next round. returning to you, paul

	Zach Lipton [:zach]
	Comment 5 • 24 years ago

Chaning the qa contact on these bugs to me. MPT will be moving to the 
owner of this component shortly. I would like to thank him for all his hard 
work as he moves roles in mozilla.org...Yada, Yada, Yada...

	Asa Dotzler [:asa]
	Comment 6 • 24 years ago

updating to new owner. sorry for the spam.

	Matthew T (active 1999-2002)
	Comment 7 • 24 years ago

Enough bouncing around. It's a good idea. Do it.

Show the following alert whenever the user tries to close a browser window, and 
a <textarea>, <input type="text">, or <input type="file"> in the page shown in 
that browser window has been modified by the user since the last time the page 
was displayed in the window.

+--------------------------------------------+
|::::::::::::::::::::::::::::::::::::::::::::|
+--------------------------------------------+
|  .   Are you sure you want to close this   |
| /!\  window? You will lose all information |
| """  you have entered in the page.         |
|                                            |
|                                            |
|                      ( Cancel ) ((  OK  )) |
+--------------------------------------------+

This warning should not be shown in any of the following circumstances:
*   if only controls other than text fields or textareas were modified;
*   if the fields were only modified by scripts, not by the user;
*   if the user submits a form, then clicks Back, then tries to close the
    window without making further changes to the form.

	rods (gone)
	Comment 8 • 24 years ago

Bill, maybe you will know who should own this

	Bill Law
	Comment 9 • 24 years ago

I'll take it.  It's a browser/session-history thing.

What about other things that cause form input to be lost?  If you go to another
page (follow a link, enter a URL, etc.) then close the window, should there be a
prompt then, too?

	Matthew T (active 1999-2002)
	Comment 10 • 24 years ago

No. One reason would be that the user, when confronted with the alert, would be 
thinking `information? what information? I haven't entered any information on 
this page', and they'd be right.

	Bill Law
	Comment 11 • 24 years ago

One counter reason would be that the user, after composing the sequel to War and
Peace and then going to www.merriam-webster.com to check on the spelling of the
very last word (and pressing Ctrl-Q accidentally there), when *not* confronted
with the dialog, would be thinking: 'shit; now I have to type all 821 pages over
again,' and they'd be right.

I'd prefer you offer a reason that didn't appear to be based solely on a
conflict with the wording you happened to choose for your proposed alert.  If we
changed the wording, in that scenario, to: "Are you sure you want to close this
window? You will lose all information you have entered in an earlier page" then
your reason seems pretty silly and I'm still left with the question I posed.

I'm not saying you're not right.  Just that the one reason you gave isn't too
convincing.

	Matthew T (active 1999-2002)
	Comment 12 • 24 years ago

If I composed the sequel to /War and Peace/ in a browser window, I sure 
wouldn't use the *same window* to go to an online dictionary site before 
returning to my message. I don't trust Mozilla's cache *that* much! I'd use a 
new window instead.

	Bill Law
	Comment 13 • 23 years ago

I find your logic even less convincing with its repetition.

	Matthew T (active 1999-2002)
	Comment 14 • 23 years ago

I see no repetition. What exactly do you want? If someone starts filling out a 
bug in Bugzilla, and then realizes that it's not a bug after all, and continues 
browsing in that window for another few hours, then closes the window, do you 
want a confirmation alert still to be shown in that case? I certainly don't.

(The originally reported problem happened again at work last night. A woman 
spent 40 minutes composing a message in Hotmail, and then `the window 
disappeared'. She must have typed Control+W instead of Shift+W, I guess. 
Understandably, she was extremely angry.)

	Bill Law
	Comment 15 • 23 years ago

>I'd prefer you offer a reason that didn't appear to be based solely on a
>conflict with the wording you happened to choose for your proposed alert.

That's all I asked for; that's all I wanted.  Your second "reason:" that you'd
have chosen a different app or written a different book, was equally unconvincing.

As to your other question: No, I don't probably want an alert in that case.  But
maybe I would if it was only 1 hour; or at lunch time, or when I had to step out
to a staff meeting.  I would always want it if I had, for example, just happened
to click on a link in an email message a few minutes ago, and Mozilla decided to
open the link in the same browser window where I was composing a real bug.

Obviously, one never *really* wanted the alert in *any* case where one ends up
electing the "throw away my changes" option.  Perhaps that's the price one has
to pay in order to get the alert when one does want it.  And unless we make it a
user pref, that might be the price one user has to pay in order for another user
to get the alert when they want it.

Here's another example that you might find easier to relate to than my previous
one: My wife was complaining the other day because her carefully crafted
mail.yahoo.com email msg was lost when she accidentally closed the window.  In
her case, it happened that she had previously clicked on the "check spelling"
button (about 2 seconds earlier).

The point is that the consequence is identical in these two cases (your example
and mine).  I'm not convinced that the decision to only show the alert in the
one case is so cut and dried.  Although I do appreciate you going to the trouble
to try to explain it to me.

Perhaps there's another, less extreme, solution:

 o "expire" the pending form input after n minutes
 o alert if form input is pending on pages from the current site
 o alert if form input is pending on one of the preceding n pages
 o something more clever that we haven't thought of yet.

As I stated previously: I am not saying you're wrong.  I just am not so firmly
convinced and if you are indeed correct, then you shouldn't have to resort to
such shoddy logic to make your case.

	Bill Law
	Comment 16 • 23 years ago

Setting target milestone.

	Matthew T (active 1999-2002)
	Comment 17 • 23 years ago

Bill, please don't accuse me of trying to use logic. :-) I don't know where the
cutoff point is, and I think we can only find it by trial and error. As we
expand the range of situations where a confirmation alert is used, we reduce the
probability that the alert will be useful on average, so we get closer to the
point where the alert is more annoying than useful in general.

So, the first step is to put up an alert if text was changed in the current
page. Then, if that works well, we can extend it so that the alert comes up if
text was changed and not submitted in pages >2 away from the current page in the
session history (that should catch your wife's spell-checker case). Then if the
feature is still more useful than annoying, maybe we can extend it further to
pages which were edited in the last hour or whatever. Sound good?

The only risk I can think of here (apart from the deliberate risk of being too
annoying) is that people will extend their expectation of the alert protecting
them, in cases where it does appear, to cases where it does not.

	Peter Trudelle
	Comment 18 • 23 years ago

changing severity to critical (data loss), clearing target, adding nsbeta1
keyword for triage team evaluation. cc lori for Nav UE input.

	Bill Law
	Comment 19 • 23 years ago

Setting target milestone to Future.  This "bug" has been present in all browser 
since day 1 (as best I can tell) and is still present in all browsers still 
(again, as best I can tell).

	Keith Lea
	Comment 20 • 22 years ago

interestingly enough, I lost some data while using the Bugzilla Helper to report
four bugs in a row. after clicking "Open Bugzilla Entry Form" on the Helper I
forgot to click into that window to click "Commit", continuing on by writing out
my next bug in the Helper. will this be solved as well? does loading a new page
count as leaving the page? just a thought.

	Dominik Stadler
	Comment 21 • 22 years ago

As far as I understand from the comments, this bug only deals with confirmation
questions when a form was edited. 

This is one place where it is annoying to loose data, but I would like to have a
confirmation question everytime I close Mozilla. It is very annoying to have
many tabs open and then loose them all by just accidentially clicking CTRL-Q or
"File-Exit". Should I open a new bug for this? There must already be a bug, but
I couldn't find any...

	Jonas Jørgensen
	Comment 22 • 22 years ago

Dominik: Bug 52821.

	John Levon
	Comment 23 • 22 years ago

*** Bug 150768 has been marked as a duplicate of this bug. ***

	Julien Pierre
	Comment 24 • 22 years ago

I think this is a much-needed feature.
Obviously a lot of people differ on what the criteria should be for the
confirmation.

I think it should be configurable. At the very least, the confirmation for
closing edited/forms should be a global on/off browser preference.

As far as comment #15 and the links issue, I think Mozilla should never reuse a
browser window that has an edited form when clicking on a link from an e-mail. I
think it's much less intrusive to open a brand new window or tab in this case
than bring up a confirmation dialog.

As far as the time issue discussed in comments #14 and #15, I don't think the
time the form was entered should be considered in whether the warning gets shown
or not. It's the loss of data we are concerned with.

In the case where the user has typed a long form and then browsed in the same
window, then closes the window, I don't think a warning should be displayed at
the time of closing the window either. However, a warning should definitely be
displayed at the time the unsubmitted edited form is no longer going to be
displayed to the user : ie. when the user clicks on a link somewhere on the
page, or selects a bookmark in that window, after having entered data in the form.

If we want to do some sort of conditional warning, it might be useful to
evaluate the amount of data submitted (bytes of text, number of check boxes,
radio buttons, etc), and have a configurable setting on when to display the
warning (greater than a certain amount of form data).

Another parameter that could be taken into account on when or not to display the
warning, and configurable, would be a threshold on the amount of time the user
spent filling the form. We would display the warning only above a certain
configurable input time, eg. 5 minutes. We can't compute it exactly, because we
don't know for sure what the user is doing when idling - whether he is thinking
hard about his next input, or whether he is away, but we can approximate input
time with a clever algorithm.  This would require keeping timestamps for each
form modification (each keystroke, checkbox, etc). Any modification would cause
us to count the previous 30s as being part of input time.

	Keith Lea
	Comment 25 • 22 years ago

how about, instead of a warning, a little notice above the tab bar, below the
links bar, with some sort of "attention" icon, that simply says "This window has
been opened because a form was being edited in another window." I think that'd
be less obtrusive but equally as effective. (the box would go away after
significant activity on the newly opened webpage.)

also, maybe a message could be displayed in the form window, too.

	John Levon
	Comment 26 • 22 years ago

*** Bug 158899 has been marked as a duplicate of this bug. ***

	John Keiser (jkeiser)
	Comment 27 • 22 years ago

Taking, I have a patch coming up.

	John Keiser (jkeiser)
	Comment 28 • 22 years ago

This patch checks textareas to see if they have changed from default:
1. Checks all tabs when the big red X is clicked to close the window
   - when one and only one tab has a textarea that has changed, focuses the tab
and textarea and asks for confirmation of close window
   - when multiple tabs have textareas that have changed, simply asks for
confirmation of close window
2. Checks a tab when the X to close a tab is pressed
   - when a textarea in the tab has changed, focuses textarea and asks for
confirmation of close tab

Step (1) needs to check File > Close and File > Exit as well before this patch
will be complete--at this point it should be fairly trivial once I learn the
part of XUL that will let me do that.

	John Keiser (jkeiser)
	Comment 29 • 22 years ago

Also need to catch Close Tab.

	Vidar Haarr (not reading bugmail)
	Comment 30 • 22 years ago

/Great/ work, John !
Nominating for various things..

	Håkan Waara
	Comment 31 • 22 years ago

John - looks good, but could you please make it obey comment 7? It should be
simple to just replace "window" with "tab" or so depending on the situation. If
you have any concerns, please check with a UI God.

	John Keiser (jkeiser)
	Comment 32 • 22 years ago

It does that already.  That is why there are three statements.

	John Keiser (jkeiser)
	Comment 33 • 22 years ago

As to the rest of comment 7, it's only doing textareas because this feature
would get really annoying on search pages if it did input type=text; and I got
these new texts from mpt, who authored comment 7 :)

	Håkan Waara
	Comment 34 • 22 years ago

Sounds fine to me then.

	John Keiser (jkeiser)
	Comment 35 • 22 years ago

OK, this guy is fully tested and ready for review.

For window close functions I have verified that it brings up the dialog (and
that OK and Cancel work) when the textarea in the tab is changed, and when
appropriate verified that the proper tab gets focused (when there are multiple
tabs but only one tab with a problem; if multiple tabs have problems no tab is
focused):

File > Close
File > Close Window
"X" on top of window
File > Exit
CTRL+Q

For tab close functions I have verified that it brings up the dialog (and that
OK and Cancel work) when the textarea in the tab is changed, and when
appropriate verified that the proper tab is focused (such as right-click >
Close on unfocused tab):

File > Close Tab
"X" on tab bar
Right-click on tab > Close Tab
Right-click on tab > Close Other Tabs
CTRL+W

Finally, I have verified that window.close() does *not* cause this to come up,
even when the textarea is changed.

NOTE: Close Other Tabs, because of the way it works, may open multiple
confirmation dialogs if multiple tabs have problems--it checks each one in
order and then closes it.

This patch makes things flexible enough that other people can add other
conditions easily to the browser close--such as the bug where people want a
warning if multiple tabs are open.

	John Keiser (jkeiser)
	Comment 36 • 22 years ago

Fixed indentation and a stray bracket that does not appear to have adversely
affected execution of the function it was in.

	John Keiser (jkeiser)
	Comment 37 • 22 years ago

Oops, sorry law, forgot to CC you when I took the bug.

	Vidar Haarr (not reading bugmail)
	Comment 38 • 22 years ago

Comment on attachment 93096 [details] [diff] [review]
Patch v1.0.1

Nice ! now, I'm not a reviewer, but I just went through it, and it seems fine
to me, for how much it's worth :)

Just some small nits:

Shouldn't the functions be named checkAndRemove[Current]Tab() ? I know that it
sounds like the function will remove the tab nevertheless, but with
'checkRemove[Current]Tab(),it sounds like it's just going to check whether to
remove it or not, and return a boolean value.

This will also prompt the user if he visits a site that has
'typemachine'-textareas.. if you know what I mean, but I guess nothing can be
done to prevent that..

Just my 2 NKR ;)

	John Keiser (jkeiser)
	Comment 39 • 22 years ago

checkXXX() is a fairly common pattern in my and others' code, which generally
means "do XXX if you need to do it".  As for typemachines, I presume you mean
textareas modified by JavaScript.

I see very little that could prevent that without adding machinery to determine
exactly *who* changed the textarea--and that sounds to me like diminishing
returns.  We'll see if bugs on it come up and fix it if clamor gets great.

	John Keiser (jkeiser)
	Comment 40 • 22 years ago

Implement law's good idea--don't throw this dialog up if someone just edited a
few characters.  50 seemed like a nice round number.  In this sentence, 50
characters get up to the "if" in the first sentence.

	John Keiser (jkeiser)
	Comment 41 • 22 years ago

It turns out in a page with \r\n's in the textarea, this patch would bring up
the dialog.  This is because of bug 161207.  I have worked around it with
defaultValue.replace(/\r/g,"") in the comparison.

	Bill Law
	Comment 42 • 22 years ago

Comment on attachment 94087 [details] [diff] [review]
Patch v1.0.2

r=law

	Bill Law
	Comment 43 • 22 years ago

Comment on attachment 94087 [details] [diff] [review]
Patch v1.0.2

editted the wrong attachment

	Bill Law
	Comment 44 • 22 years ago

Comment on attachment 94105 [details] [diff] [review]
Patch v1.0.3

r=law

	David Hyatt
	Comment 45 • 22 years ago

sr=hyatt.  Have you tested this to make sure it doesn't impact close
performance? (I don't expect anything rigorous, just some informal tests of a
few common pages like Hotmail or something).

Also make sure this is ok with the UI people at Netscape.  If not, obviously it
can still go into Mozilla, but they deserve a heads-up so they can fork if
necessary.

	Jonas Jørgensen
	Comment 46 • 22 years ago

*** Bug 143266 has been marked as a duplicate of this bug. ***

	Mark Kolmar
	Comment 47 • 22 years ago

I want to propose user preferences for whether to confirm on window close, tab
close, and/or app close.  I was able to add confirmation for all 3, crudely:

function Startup()
[...]
window.tryToClose = function() { return window.confirm("Do you really want to
quit?"); }

function BrowserCloseTabOrWindow()
[...]
      if (window.confirm("Are you sure you want to close the tab?")) {
browser.removeCurrentTab(); }
//    browser.removeCurrentTab();

function BrowserCloseWindow() 
[...]
  if (window.confirm("Are you sure you want to close the window?")) {
window.close(); }
// window.close();

Should be straightforward to allow preferences, and either ask for confirmation
like this, or go ahead and quit/close.  The tests for whether a user changed a
form could be in addition to these preferences, even a preference itself.

	John Keiser (jkeiser)
	Comment 48 • 22 years ago

So file a bug :)  I'm not interested in adding prefs.

	John Keiser (jkeiser)
	Comment 49 • 22 years ago

(Not only that, but your request is really a separate bug and deserves a
separate debate and implementation.)

	Jatin Billimoria
	Comment 50 • 22 years ago

My suggested wording:

tabhasformdatatitle=Warning: Unsent Form Data

tabhasformdatawin=You are about to close a window containing form data that will
be lost. Are you sure you want to close this window?

tabhasformdatatab=You are about to close a tab containing form data that will be
lost. Are you sure you want to close this tab?

tabhasformdatatabs=One or more of the tabs you are about to close contain form
data that will be lost. Are you sure you want to close these tabs?

	Stephen Ostermiller
	Comment 51 • 22 years ago

I just lost a lot of work when I hit ctrl-w instead of ctrl-v (they are right
next to each other on my dvorak keyboard).  This should have the dataloss keyword.

	John Keiser (jkeiser)
	Comment 52 • 22 years ago

Jatin: what user understands the phrase "form data"?  I think we're getting too
technical for an end user (I think in many places we already *are* too technical
for end users).  What if we reworked them like this:

tabhasformdatatitle=Warning: Unsent Text
tabhasformdatawin=You are about to close a window where you wrote a lot of text.
This text will be lost if you continue. Are you sure you want to close this window?
tabhasformdatatab=You are about to close a tab where you wrote a lot of text.
This text will be lost if you continue.  Are you sure you want to close this tab?
tabhasformdatatabs=You are about to close a window with several tabs in which
you wrote a lot of text. This text will be lost if you continue. Are you sure
you want to close this window?

	Jatin Billimoria
	Comment 53 • 22 years ago

How about this instead?

tabhasformdatatitle=Warning: Unsent Text
tabhasformdatawin=You are about to close a window in which you typed text.
This text will be lost if you continue. Are you sure you want to close this window?
tabhasformdatatab=You are about to close a tab in which you typed text.
This text will be lost if you continue.  Are you sure you want to close this tab?
tabhasformdatatabs=You are about to close a window with several tabs in which
you typed text. This text will be lost if you continue. Are you sure
you want to close this window?

	John Keiser (jkeiser)
	Comment 54 • 22 years ago

Works for me :)

jag, I hear you had questions?  Patch v1.0.3 is the one (I'll make jatin's
wording changes before checkin).  Ask away.

	Jonas Jørgensen
	Comment 55 • 22 years ago

OK and Cancel are bad button labels. Could you please use "Close window" and
"Don't close window" instead?

http://mpt.phrasewise.com/stories/storyReader$4

	jag (Peter Annema)
	Comment 56 • 22 years ago

jkeiser: yeah, well, not so much questions as comments.

I don't think "50 chars in a textarea" is a good measure of "form has been
edited sufficiently". What about e.g. a credit card form or an address form? No
textareas in there, yet worthy of showing a dialog if filled out, methinks. Why
not just go with "modified in any way" (I was told you can ask that of a form)?
That should make it a lot easier for the user to understand when this kicks in.

I also don't like the names |checkRemoveTab| and |checkRemoveAllTabsBut|. I've
read your explanation above, but I'm not aware of this convention and personally
don't like it. Most (if not all) |checkFoo| functions I've found in a quick grep
of mozilla/xpfe are pure "return a bool with no side effects" functions, just
the way they should be. I think it would be perfectly okay to keep the name
"removeTab" and just return false if the tab may not be removed. Or throw an
exception, if you want to be dramatic.

I don't really like stuffing all these methods into <tabbrowser>, <tabbrowser>
should be about managing tabs with <browser>s in them, the policies should be up
to the app embedding <tabbrowser>. To facilitate this, hewitt and I came up with
the following:

- make removeTab dispatch a "removingtab" event to which navigator can listen.
This listener would check whether it's okay (more about this below), and call
preventDefault if not. |removeTab| would only remove the tab if preventDefault
wasn't called, and could (if there's a need) return true or false to signal
whether or not it did. That should take care of removeTab and removeAllTabsBut.

- when closing a window or quitting Mozilla, removeTab isn't called (as you
know, just explaining to those who don't), so instead call a function (not on
tabbrowser) which iterates over all tabs, checks whether it's okay (more about
this below), and returns true/false (I think both onclose and tryToClose work
that way). In other words, move OKToCloseAllTabs out of <tabbrowser>. In the
case that the user says it's not okay you could even focus the first tab that
has a modified form.

Now about this "check whether it's okay". It would be nice if the form(s) check
could live somewhere where embedders (that includes us) have easy access to this
functionality instead of having to copy the js code and duplicating it in C++
(or Objective C or whatever). Then if we detect one (or more) form(s) has/have
changed, in our case from JS, we show a dialog explaining what's going on and
allowing the user to continue or abort.

	Vaclav Dvorak
	Comment 57 • 22 years ago

I agree with jag on that the trigger should be "form modified in any way". I
don't see why the checking should be limited to text input (as originally
suggested by mpt in comment 7), or even only to textarea's. Have you ever filled
out a survey with _lots_ of radio buttons/check boxes? I know I have. And
picking an arbitrary number of minimum changes/time before we consider the work
worthy of preservation seems like a very ad-hoc approach. It would be confusing
to the user: "last time I did this I got an alert, now I didn't - what's wrong
or different"?

I also think that thought should be given to triggering this not only on closing
the window/tab, but also to any kind of leaving the page, such as clicking a
link. After all, we don't guarantee that the user can get back, do we? So it's
just as destructive as closing the window, and it may or may not be intentional
just as well (for example, the page may have defined some accesskey's for some
links, overriding our Alt+Letter hotkeys, perhaps without the user's knowledge).

I appreciate mpt's worry about too many alerts, though (although I totally
disagree with him about bug 39057 - sorry, had to mention it). There should
certainly be a check whether it was really the _user_ who modified the form, not
a script. I've seen pages where a script displays the time in a text input
field, updating it every second.

Unfortunately, this isn't as easy as noting the existence of keyboard/mouse
input in a bool for each form control. Imagine an input field, followed by
"links" with onClick="javascript: self.form.field='value'". In that case, the
form's content may be modified by the user's action, although the action doesn't
concern any of the form controls. This could be caught by checking for a change
of data during handling of any onClick and other relevant events... That seems
like too much work and overhead, though - I guess it's not so important. I take
this last paragraph back. ;-)

	John Keiser (jkeiser)
	Comment 58 • 22 years ago

Of course it's ad-hoc.  You want to avoid alerts on things like search engines,
for example.  But that can be dealt with in another bug if this ever gets fixed.

It's going to be a while before I can rewrite the patch with jag's changes. 
Others who are interested are welcome.

	Jesse Ruderman
	Comment 59 • 22 years ago

"One or more of the tabs you are about to close contain form data that will be
lost" is unnecessary.  It would make more sense to show one dialog for each tab
whose closing needs confirmation.  That would be similar to what happens when
you shut down Windows and have unsaved information in several open windows.

	Prognathous
	Comment 60 • 22 years ago

> It's going to be a while before I can rewrite the patch with jag's changes.

So why not implement the current patch? it is still much better than the 
current dataloss situation. The rest of the changes can be added later on.

Prog.

	Boris Zbarsky [:bzbarsky]
	Comment 61 • 22 years ago

Because jag is the maintainer of the code, and finds the current patch unacceptable?

	Daniel Wang
	Comment 62 • 22 years ago

*** Bug 182595 has been marked as a duplicate of this bug. ***

	Martijn Korse
	Comment 63 • 22 years ago

I have been reading this thread and also bug 68215 with great interest. As 
other people in bug 68215 , i'm also faced with the problem of building an 
interface for a database and being restricted to use IE because it supports the 
window.unbeforeunload event and mozilla does not. And, at the moment, that 
prevents a whole company from switching from Windows to Linux! The interface i 
created deals with very large forms which can take about 30 mins to fill in, so 
you can understand why this is of vital importance. 

So, just a check on textareas and the x-marker are not gonna do it for me (and 
a lot of other people). Clicking on links and information in input fields are 
just as important (even more important in my case)

Wouldn't it be possible to create something that would distinguish between 
these modes:
1. no checking at all
2.
a) check only textareas
b) check all input fields (textrea, input, select)
3. trigger an alert on
a) leaving a page with ctrl+q, x-marker, etc
b) leaving a page in anyway possible

and then possibly create the option:
O Don't check for changes by default, but with the exception of these domains:
...............
O Always check for changes by default, but with the exception of these domains:
...............

Of course this function should NOT be triggered when a form is being submitted.

If that's too hard to implement, or too complicated, or too confusing for 
mozilla users i suggest we drop this bug all together and go with 68215 and let 
the designer of the site decide whether he wants to alert his visitors with an 
unbeforeunload or not (but of course, with an option in the prefs to switch off 
such alerts to prevent abuse of this functionality)

	Hixie (not reading bugmail)
	Comment 64 • 21 years ago

*** Bug 228159 has been marked as a duplicate of this bug. ***

	Prognathous
	Comment 65 • 19 years ago

Tweaking the summary to make this bug easier to find.

Prog.

	u88484
	Comment 66 • 19 years ago

can this be landed now? probably bitrotten but maybe someone can take a look to
see if we can still use this code or tweak a little to make it work again if
indeed is bitrotten.

	Vidar Haarr (not reading bugmail)
	Comment 67 • 19 years ago

I figured I'd take a stab at this from a different angle.

The check for form changes is only made if you close the window or use the
context menu "Close other tabs". It checks for a textarea or for >1 text
inputfields with changes and if it finds it, it focuses that tab and element,
and prompts with the standard "are you sure you want to close these tabs"
prompt, not mentioning forms at all.

I find this way superior to checking for form changes on all tab closes,
because if I close 1 tab explicitly, I'm sure to be pretty certain of what's in
it - while if I close the entire window or all tabs except one, I'm usually in
a situation where I have tons of tabs open and a reminder could be useful.

Please note that in my local tree, I have also removed the focus scroll
suppression in
<http://lxr.mozilla.org/seamonkey/source/toolkit/content/widgets/tabbrowser.xml#728>,
so that when a tab is focused, it scrolls to the element with the focus
automatically. This change isn't very good for "global" adoption, because it
will scroll even when you change tabs manually.

Anyway .. I'll request review from mconnor here on the general idea. If he
likes it, maybe we can evolve the patch to a usable state.

	Olur
	Comment 68 • 19 years ago

Argh... I wanted to write a comment but as I had finished my comment I realised 
that most of the stuff here is pretty old. Therefore I opened an extra window 
to double check that this bug really haven't been fixed. Sure enough, my edited 
test-hotmail window closes instantly without confirmation. Unfortunately I 
somehow managed to press the mousebutton twice when closing the hotmail window 
resulting in my also closing the window in which I had written but not 
submitted the comment on this very bug. 

I dont have the energy to write the whole comment again, I'll just say that 
there should be a confirmation prompt whenever leaving a page with edited data 
on it, wether you leave by link, reload or close window. Also these prompts 
have to have the "dont show this again" on them or hords of übergeeks will 
instantly (and successfully) go to action and make sure this necessary feature 
will not be implemented. The preferences part of the discussion about this bug 
is therefore an integral part of the bug and NOT a separate bug.

Thank you 

	Chris Jones
	Comment 69 • 19 years ago

*** Bug 314597 has been marked as a duplicate of this bug. ***

	Jesse Ruderman
	Comment 70 • 19 years ago

*** Bug 321443 has been marked as a duplicate of this bug. ***

	Peter
	Comment 71 • 19 years ago

I agree with comment #57. Checks should not only be made on text fields, but on any form field (except hidden of course), as explained in that comment.
I also agree that the warning should come even if the current tab is the one containing the form. Take for example an unexperienced user why by accident double-clicks the tab-close icon. If the second click closes a form page, that page would be active at the time of closing.

The Javascript issue is indeed a bit complex. Don't know if it is easy to check whether a form has been editted by the user or by a script. Also, some websites use radiobuttons combined with onChange to load a different page. (As a mimic for tabs: the radiobuttons indicate the tab displayed.) This would mean the alert should not be displayed when the page is unloaded using JavaScript.

	Jo Hermans
	Comment 72 • 18 years ago

*** Bug 339168 has been marked as a duplicate of this bug. ***

	bugzilla
	Comment 73 • 18 years ago

This is still a stupid bug that should never have existed.  And it's been YEARS.

This applies also to ^W, which Unix users can use to erase words in Firefox text boxes, and then we try it on Windows, and...

DO NOT DESTROY DATA WITHOUT CONFIRMATION.

Lemme say it again:

DO NOT DESTROY DATA WITHOUT CONFIRMATION.

Which part of this is hard?  We already know how to put up a confirmation dialogue when a window is about to be closed.  DO IT!!!!!!!

	Håkan Waara
	Comment 74 • 18 years ago

bug 347191 is now filed for Camino on this. (bug 252646 seems to be the Firefox-specific bug.)

Whenever a patch comes up here, I would prefer that the hard work is done in Core, and provided to embeddors via some interface (unlike the old path here, which does it inside one of the XBL bindings).

For example, unblocking popups is something both Camino and Firefox are capable of today, but each of them have to do the hard work on the app side. Camino is even forced to use private Gecko interfaces for it to work...

	Matt H
	Comment 75 • 16 years ago

Other browsers do this.

	Mike Connor [:mconnor]
	Comment 76 • 16 years ago

Comment on attachment 196315 [details] [diff] [review]
Something different, prototype (toolkit only)

this is bitrotted for sure, and doesn't seem like its ready for review anyway.

	Olur
	Comment 77 • 16 years ago

This just has to be so easy. Make a function that warns if form data (any data) is about to be lost - and a "don't show this again" preference to go with it - implement it and work out the kinks from there. User feedback is bound to come pouring in once it's implemented. 

Why is this not happening? Is it because the preference part has to be coordinated with the specifics of this bug? I really want to know 'cause i don't get it, what exactly is the hold up? Anyone? Please...

	verdy_p
	Comment 79 • 16 years ago

In fact, the way you seem to progress, you are attempting to guess whever a confirmation shuold come or not.

In my opinion, the confirmation should come EVERY TIME you attempt to close a window from a keyboard shortcut that contains a key from the main alphanumeric part of the keyboard (i.e. any shift modifier combination plus any letter or digit, like: Ctrl+W on Windows and Mac, or Alt+Q...)

The guess for modifications should be optional and desactivable when closing the window with a mouse (don't forget that some forms may be filled indirectly from scripts loaded with the page, and may appear as systematically modified, so the confirmation dialog could avoid closing immediately a window with the mouse click on the close button, if this is, for example, from a popup that fills some form).

The guess should ignore fields that are not editable (where user focus is disabled)

My solution is then simple:
* closing a window through a keyboard shortcut (including pressing ENTER when an element in the page currently has the focus, such as a displayed button or active link, and handles the key event as an activation) : display the confirmation dialog
* closing a window through another user event (such as mouse move, mouse hover, mouse exit, mouse click, clicking a button or active area or link within the page....) : don't need to display the confirmation

Remember that data loss will occur even if there is NO edit control in the disaplyed page, because this will also close a online session (imagine you're just playing a game online.)

There's little risk to close a window and loose all edits and a session when just clicking with a mouse.

The main danger comes from the keyboard and the fact that the focus may change inexpectedly, and the user did not notice visually that this focus changed (note: the visual signaling of this focus change may not happen, notably for the Ctrl+W or Alt-Q keyboard shortcut which is global to the whole open window, whatever the numer of open tabs and forms it contains).

Finally, you should still allow users to disable completely such global key bindings like Alt+Q and Ctrl+W that closes the window (users should still be able to keep an existing one such as Alt+F4, which is the system default and that has little reasons to be changeable, or to change this binding somewhere, or even disable this one completely).

I can't remember the number of times that I have been very angry against those bloody browsers that close their window, just because I accidently pressed Ctrl+W instead of Ctrl+X, which is just 1 millimeter away on my French keyboard, when I really wanted to cut some text with lots of modifications in progress. When this happens, I am always very close to sending my keyboard through the screen, and drop violently the screen away to the floor ! The unexpected window closure has consequences: loss of online sessions when performing some transactions, or online procedure with multiple forms on several successive screens, data loss for theedited items, and often loss of long hours of work, or loss of online contacts.

In my opinion Ctrl+W or Alt-Q are harmfull and should have never been forced on by default in ALL browsers (IE, Mozilla Firefox, Safari, Opera, Google Chrome...) I will stringly applaude Firefox if it becomes the first browser to implement this "feature" desactivation.

	verdy_p
	Comment 80 • 16 years ago

In summary from the above, I would really like that yuo extend the feature to not just control if forms have been edited. (Note that active input forms may also cnotain long lists of radio box, checkboxes, selection lists, and there may even be NO FORM in the displayed page, when the data is already on the server but in a temporary storage that will disappear if the online session is closed.

So:

- offer to disable superfluous shortcuts (Alt-Q, Ctrl+W) when just one is needed (Alt+F4 on Windows)
- confirm ALL window closes when this comes from the keyboard (whatever the keys which has been pressed that generated this event or the event chain)
- OPTIONNALLY: use the "guess" method (checking the state of forms) when closing through another event such as a mouse action, using the methods you've attempted to design above in this discussion. (Personnaly I will opt to disable this "guess" check completely, I just want the discrimination between the keyboard and mouse in fact).

	verdy_p
	Comment 81 • 16 years ago

Note that my solution above, if your "guess" method discussed here is not
implemented or disabled, will allow solving this bug without depending on Bug
161207 (which is related to the state of textareas) ! So my solution can be
developed and impelemted separately, even if Bug 161207 is still not fixed.
This should allow a faster immediate solution (and something that is much
easier to implement and fix, before you attempt to determine the conditions
checked by your guess methods about the state of input forms).

Effectively, you just need to:
- track the source of the event: keyboard or not ? (so pass the soruce of the
event to your tested scripts above to determine if the guess will be useful
- separately offer in the preferences a way to disable all the unneeded and
potentially dangerous keyboard shortcuts: Alt+Q and CTRL+W, and optionally even
the Alt+F4 or Ctrl+F4 shortcuts (they are less dangerous because they use
function keys, and not alphanumeric keys, so they aer much less likely to be
pressed by accident).
This requires two completely independant fixes that are easy to implement and
test separately.

I'm sure they will be easier to implement, with much less caveats than those
discussed here about the state of input forms (because you are currently only
considering text inputs and textareas, but ignoring all other input types such
as elements modified by a click on an active interface such as active images,
active links, radios, checkboxes, and also the state of the online session
(when the unsaved data is only temporarily saved on the server as long as the
online session is active)

	anonyhole
	Comment 82 • 15 years ago

A duplicate of this bug: bug 404591

	Alain Knaff
	Comment 84 • 15 years ago

I'm the reporter of bug 501606 which has been marked a duplicate of this one. Indeed, it is a duplicate of the initial description (warning when closing page with unsaved form contents) and the first few comment (navigating away from a page with unsaved form contents).

However, over its long life, the scope of this (48333) bug has morphed. It now is "warning before closing mozilla using a keyboard shortcut". Which is certainly a worthwhile feature too... but not the same use case as was initially discussed. 

Just pointing this out to make sure nobody erroneously closes the bug when this keyboard shortcut warning has been implemented, but not the "navigate away from form with unsaved data" part.

	Wayne Mery (:wsmwk)
	Comment 85 • 15 years ago

(In reply to comment #84)
> I'm the reporter of bug 501606 which has been marked a duplicate of this one.
> Indeed, it is a duplicate of the initial description (warning when closing page
> with unsaved form contents) and the first few comment (navigating away from a
> page with unsaved form contents).
> 
> However, over its long life, the scope of this (48333) bug has morphed. It now
> is "warning before closing mozilla using a keyboard shortcut". Which is
> certainly a worthwhile feature too... but not the same use case as was
> initially discussed. 

the summary still matches comment 0, so I don't know if the bug has morphed without reading the whole lot of comments.  But I would suggest unduping your bug if you don't agree that this bug will deliver what you want.

	Ralf Hauser
	Comment 88 • 14 years ago

see also bug 601550

	Brent
	Comment 90 • 12 years ago

This problem has bothered me for years.  Sometimes I remember to use ctrl-a ctrl-c to get text I'm working on into the clipboard, but more often, I don't.  I've had web pages throw away all my text by asking for a login and then returning me to a blank form.  Today, I lost a message I was typing because I meant to type in a capital W and hit ctrl instead of shift.  The browser was not closed, yet there was no way to get the text back.

Can't the text in a text box be saved to disk, so users can get it back even if the browser crashes?  How about remembering the text typed into each webpage so that a ctrl-z can get it all back?

	Frank Ch. Eigler
	Comment 91 • 12 years ago

Until this feature is implemented in mozilla core, consider using the Lazarus add-on.  It exactly saves the text in a text box (and in general, form contents) to disk, as they are being filled in.

	carsten.klein
	Comment 93 • 12 years ago

When will this be implemented? I know of Safari that already has it and it actually does prevent the user from data loss.

	Sylvestre Ledru [:Sylvestre]
	Comment 94 • 10 years ago

This has been also reported on the Debian bug tracker a while ago:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=332678

	TGOS
	Comment 95 • 10 years ago

OMG, that would be such an awesome and important feature. Why has this never been reviewed and added to the core?

	Wayne Mery (:wsmwk)
	Comment 96 • 9 years ago

(closer to reality)