Open Bug 48333 Opened 24 years ago Updated 2 years ago

Ask for confirmation of window close if form has been edited (prompt users before Quit)

Categories

(Firefox :: Session Restore, enhancement, P3)

Product:
Firefox
Component:
Session Restore
Type:
enhancement

Tracking

()

Status:
REOPENED
Milestone:
Future
Tracking Flags:
Tracking Status
firefox42 --- affected
firefox43 --- affected
firefox44 --- affected
firefox45 --- affected

People

(Reporter: hp, Unassigned)

References

Details

(Keywords: polish, Whiteboard: [FIX])

Attachments

(2 files, 4 obsolete files)

Patch v1.0.3
(deleted), patch
law
: review+
Details | Diff | Splinter Review
Something different, prototype (toolkit only)
(deleted), patch
Details | Diff | Splinter Review
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.
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 ))
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reassigning from bdonohoe to hangas
Assignee: bdonohoe → hangas
Sending to German for confirmation (pun intended). Please return to me if this should be fixed.
Assignee: hangas → german
this would be great idea for improvement for the next round. returning to you, paul
Assignee: german → hangas
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...
QA Contact: mpt → zach
updating to new owner. sorry for the spam.
Assignee: hangas → mpt
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.
Assignee: mpt → rods
Severity: normal → enhancement
Component: User Interface Design → HTML Form Controls
OS: Linux → All
QA Contact: zach → vladimire
Hardware: PC → All
Summary: ask for quit confirmation if form has been edited → Ask for confirmation of window close if form has been edited
Bill, maybe you will know who should own this
Assignee: rods → law
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?
Status: NEW → ASSIGNED
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.
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.
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.
I find your logic even less convincing with its repetition.
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.)
>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.
Setting target milestone.
Target Milestone: --- → Future
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.
changing severity to critical (data loss), clearing target, adding nsbeta1 keyword for triage team evaluation. cc lori for Nav UE input.
Severity: enhancement → critical
Target Milestone: Future → ---
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).
Target Milestone: --- → Future
QA Contact: vladimire → tpreston
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.
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...
Dominik: Bug 52821.
*** Bug 150768 has been marked as a duplicate of this bug. ***
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.
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.
*** Bug 158899 has been marked as a duplicate of this bug. ***
Taking, I have a patch coming up.
Assignee: law → jkeiser
Status: ASSIGNED → NEW
Attached patch Patch v0.9 (obsolete) (deleted) — — Splinter Review
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.
Also need to catch Close Tab.
Status: NEW → ASSIGNED
Whiteboard: [FIX]
/Great/ work, John ! Nominating for various things..
Keywords: mozilla1.0.1, mozilla1.1, polish, relnote, review
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.
It does that already. That is why there are three statements.
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 :)
Sounds fine to me then.
Attached patch Patch v1.0 (obsolete) (deleted) — — Splinter Review
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.
Attachment #93063 - Attachment is obsolete: true
Attached patch Patch v1.0.1 (obsolete) (deleted) — — Splinter Review
Fixed indentation and a stray bracket that does not appear to have adversely affected execution of the function it was in.
Attachment #93095 - Attachment is obsolete: true
Oops, sorry law, forgot to CC you when I took the bug.
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 ;)
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.
Attached patch Patch v1.0.2 (obsolete) (deleted) — — Splinter Review
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.
Attachment #93096 - Attachment is obsolete: true
Depends on: 161207
Attached patch Patch v1.0.3 (deleted) — — Splinter Review
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.
Attachment #94087 - Attachment is obsolete: true
Comment on attachment 94087 [details] [diff] [review] Patch v1.0.2 r=law
Attachment #94087 - Flags: review+
Comment on attachment 94087 [details] [diff] [review] Patch v1.0.2 editted the wrong attachment
Attachment #94087 - Flags: review+
Comment on attachment 94105 [details] [diff] [review] Patch v1.0.3 r=law
Attachment #94105 - Flags: review+
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.
*** Bug 143266 has been marked as a duplicate of this bug. ***
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.
So file a bug :) I'm not interested in adding prefs.
(Not only that, but your request is really a separate bug and deserves a separate debate and implementation.)
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?
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.
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?
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?
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.
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
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.
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. ;-)
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.
"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.
> 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.
Because jag is the maintainer of the code, and finds the current patch unacceptable?
No longer blocks: 158040
*** Bug 182595 has been marked as a duplicate of this bug. ***
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)
*** Bug 228159 has been marked as a duplicate of this bug. ***
Tweaking the summary to make this bug easier to find. Prog.
Summary: Ask for confirmation of window close if form has been edited → Ask for confirmation of window close if form has been edited (prompt users before Quit)
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.
Flags: blocking1.9a1?
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.
Attachment #196315 - Flags: review?(mconnor)
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
*** Bug 314597 has been marked as a duplicate of this bug. ***
*** Bug 321443 has been marked as a duplicate of this bug. ***
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.
*** Bug 339168 has been marked as a duplicate of this bug. ***
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!!!!!!!
Flags: blocking1.9a1? → blocking1.9-
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...
Blocks: 252646
Other browsers do this.
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.
Attachment #196315 - Flags: review?(mconnor)
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...
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.
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).
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)
A duplicate of this bug: bug 404591
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.
QA Contact: tpreston → layout.form-controls
(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.
see also bug 601550
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?
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.
When will this be implemented? I know of Safari that already has it and it actually does prevent the user from data loss.
This has been also reported on the Debian bug tracker a while ago: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=332678
OMG, that would be such an awesome and important feature. Why has this never been reviewed and added to the core?
(closer to reality)
Assignee: john → nobody
Status: ASSIGNED → NEW
See Also: → https://bugzilla.mozilla.org/show_bug.cgi?id=601550

Hello! I have tried to reproduce this issue on Ubuntu 20 with Firefox 87.0a1(2021-02-16), 85.0.2 and 86.0b9. I will mark this issue as RESOLVED -> WORKSFORME. If this issue is still reproducing please feel free to reopen it and change it's status.
Thank you!

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME

The key to close the application is not Alt-Q anymore but Ctrl-Q on Linux (1, 2). Tests e.g. on https://bugzilla.mozilla.org/query.cgi?format=advanced shows Ctrl-Q quits the application even if the user entered text into the form fields.

Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Type: defect → enhancement

As far as I can tell, our current behavior here matches (or is maybe even better-at-preserving-data than) other browsers.

Specifically, here's what I see from other browsers:

  • Safari 15.2 on macOS: Cmd+W and Cmd+Q close tab or quit on Safari, regardless of whether you have data entered into a form field. (Comment 93 suggests that Safari might have warned at that time, but they don't now.)
  • Chrome 99 on Linux (presumably also on Win/Mac): The Cmd+W and Alt+F4 combos close the tab / window on Chrome, regardless of whether you have data entered into a form field. (I don't think there's a key combination to fully-quit, but Alt-F, X (to open the menu and then select "Exit") does as well.)

I didn't find any browser or any key combo where I get any sort of "are you sure? you have form data entered" prompt.

Note that we do have ways to resurrect lost data, if you happen to accidentally close a tab or window (or quit). Firefox has "Recently Closed Tabs" and "Recently Closed Windows" in the History menu, and if you fully-quit, I believe the history menu also has "Restore previous session" (or you can configure Firefox to do that automatically).

I think that form-field-restoration behavior is newer than most of the comments on this bug, which is why it wasn't mentioned previously here. I can see the strong desire for a "Are you sure?" prompt in a world without session-restore, but it's not as necessary and potentially more clunky-cumbersome than it's worth now that we can ~painlessly restore inadvertently-lost tabs.

So I suspect this may end up being WONTFIX or WORKSFORME-via-sessionrestore-making-it-unnecessary, but I'll reclassify to a more-appropriate component (Firefox|Session Restore) to let the folks over there make that call. (The Layout|Form Controls bugzilla-component is about the rendering of form controls, but not really about how Firefox handles or reacts to the data that's inside them.)

Component: Layout: Form Controls → Session Restore
Flags: blocking1.9-
Product: Core → Firefox

Note that individual sites can implement this behavior themselves if they really want a modal prompt to prevent accidental closing of the tab, using this API:
https://developer.mozilla.org/en-US/docs/Web/API/WindowEventHandlers/onbeforeunload

This is what happens if you e.g. try to close a Google Calendar tab when you're partway through creating a new calendar-event. And this is appropriate for cases where the site is a dynamic web-app rather than just plain web-form with a list of input fields.

But in general, I think it'd be a step backwards in terms of user experience if we automatically added an "Are you sure" prompt to any form with data entered, as this bug seems to be requesting. As an example, the prompt would probably fire for most search-results pages, since those have a text field at the top with whatever search term the user entered. I doubt we want to add a click-through prompt to all search results pages, since users do a lot of searching and then want to be able to easily close the results and move on with their life.

Put more concisely: I think the feature-request here makes sense in a world before Session Restore, and undo-close-tab/undo-close-window.

Given that we (and other browsers) have those features (ever since Firefox 4, I think?), this makes less-sense, and is really a different more-in-the-user's-face approach to solving the same problem that Session Restore / undo-close-tab/window already basically solves.

I think it is <textarea> data loss that is most problematic.

Daniel, you mention "form-field-restoration behavior is newer than most of the comments on this bug", can you say when it was implemented?
As I'm not seeing it in 91.5.0esr (which is latest available version in Debian Stable GNU/Linux).

When I type some text for example at https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_textarea and close the tab with ctrl-w, upon right-click and selecting Reopen closed tab tab is restored, but all data that I typed is lost. Same if browser closed with ctrl-q.

(Which is especially annoying as ctrl-w is common shortcut for delete-word in most editors/shells I use, and I'm quite likely to do it often)

Flags: needinfo?(dholbert)

(In reply to Matija Nalis from comment #103)

I think it is <textarea> data loss that is most problematic.

Undo-close-tab works (generally) to restore the contents of textarea.

Daniel, you mention "form-field-restoration behavior is newer than most of the comments on this bug", can you say when it was implemented?

It was implemented a decade or more ago; I don't recall precisely when. It's been around for a long time.

When I type some text for example at https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_textarea

Yeah, I can reproduce dataloss-on-restore-tab at that page. That's because that is not a regular page; it's a sandbox with ephemeral dynamically-generated rendering, inside of a dynamically-constructed subdocument.

The content on the right (including the textarea) is dynamically generated based on the markup that you can see (and can edit) on the left, and the page itself discards & rebuilds it on various signals, e.g. if you click the "Run" button. The page can detect that a tab-restore (or a back/forward navigation) has happened, and I wouldn't be surprised if it is regenerating the content on the right (which includes discarding the textarea & its contents) based off of that signal, just as it generates it on the initial pageload.

This is kind-of similar to the Google Calendar example that I mentioned above; sufficiently-complex pages like that can use the "onbeforeunload" event to pop up their own dialog, if they need to.

You can try https://paste.mozilla.org/ as a simpler testcase for textarea, if you like, where undo-close-tab works fine.

Flags: needinfo?(dholbert)

If there are specific sites where undo-close-tab's form-field restoration doesn't work and it causes trouble, please do file bugs on those! Depending on the situation, breakage could be caused by the site doing something silly or by an actual bug in the form-field-saving browser feature, or a combination of the two. If we're aware of specific issues, perhaps someone can get to the bottom of what's going wrong, and even if it's a site bug, we may be able to suggest workarounds (e.g. telling the site to not inadvertently run JS that clears their form fields when the tab is restored).

(But probably don't file a bug on the w3schools example, since that particular case is almost certainly a situation where the site is intentionally regenerating or stomping-on the content, because the point of the site is to dynamically (re)generate content on-the-fly.)

(I'll try to report when I stumble upon them, but it seems like fighting an uphill battle... (especially given the effort needed to reach someone with clue at most websites - I usually fight for months just to get their sites which only support SSL 3.0 to get them to work at all; I shudder at amount of work needed to get them to implement some website changes. But I digress). Unfortunately they are likely to be private / behind login / internal networks.)

Perhaps firefox Reopen closed tab should be behaving more like real undo functionality - i.e. returning the tab to exact state it was before it was closed using state from memory/disk - before that feature should be considered as good workaround for preventing accidentals closes (e.g. it should work on any web site, including w3schools example, without even doing any network request to undo the close).

Or, perhaps the default behaviour for onbeforeunload (if not explicitly specified by website) should be among the lines of "if modifed textarea, then show alert before closing". Then websites could still modify it if they want (including setting it to no-op), but sites which have not been updated in ages would offer protection.

(Or disable ctrl-w shortcut if website has textarea and did not specify onbeforeunload, but that feels kludgy...)

Oh, and additional hint if someone for whom form-restoration does not work on any website stumbles on this - you (or some privacy addon) might have set firefox browser.sessionstore.privacy_level > 0 in about:config.

As someone who created the duplicate bug 277580 some 5 years ago - I can confirm that form-field restoration almost, but not completely, solves this problem.

In most situations where this happened to me recently, my form input was preserved using Reopen Closed Tab. So, good job there.

The most obvious situation where this doesn't work is when there is only one tab. In this case, Ctrl+W completely closes the browser, and bye bye all page state and form input.

The most obvious situation where this doesn't work is when there is only one tab. In this case, Ctrl+W completely closes the browser, and bye bye all page state and form input.

Luckily, for that one, there is advanced preference browser.tabs.closeWindowWithLastTab that one can use to workaround that specific issue.

(In reply to denis bider from comment #108)

The most obvious situation where this doesn't work is when there is only one tab. In this case, Ctrl+W completely closes the browser, and bye bye all page state and form input.

This actually does work in that situation, too. (You don't need a pref-flip as suggested in comment 109, though that does seem to be an additional help.)

  • If you have another Firefox window open (i.e. you haven't fully quit), you can reopen the closed window by using the "History | Recently Closed Windows" menu.
  • Otherwise: if this was the last Firefox window (i.e. you've quit by accident by closing the last window), then you can just launch Firefox and use "History | Restore Previous Session"

Many of the comments here focus on Ctrl+W (since that happens to be easy to trigger by accident particularly if you're an emacs user), but close-tab and quit aren't actually that special in terms of being destructive. Back, Forward, Reload (via e.g. accidental Ctrl+R), and clicking-a-link could all be just-as-destructive. So to really solve this with a prompt, the browser would need to prompt on all of those actions (when the user has entered some text).

Fortunately, form-field restoration elegantly provides a way to restore your lost data in all of these cases, without interrupting the user by forcing them to click through a dialog. (The same mechanism gets used to save form-data on reload or back+forward as gets used for undo-closed-tab.)

That's useful to know, thank you.

I was not aware of History | Restore previous session. Perhaps it could be useful if I explain how much trouble I had finding it, AFTER I read your comment.

  1. I conveniently just had a Firefox window open where there was only one tab. I closed that tab to completely exit Firefox.

  2. I reopened Firefox. It launches with an empty tab, the way I have it configured.

  3. My first instinct was to right-click the title of the empty tab and look for "Restore previous session". Not found there.

  4. My next instinct is to right-click the page content of the empty tab and look for "Restore previous session". Not found there.

  5. I remembered your message said it was under "History". So I open the History dock with Ctrl+H. I click and right-click all components of that interface, looking for "Restore previous session". Not found.

  6. Maybe it's in the menu. I look for "Restore previous session" in the main Firefox menu. Not found there.

  7. After clicking around the whole interface for a while, I finally capitulate and go back to your message.

  8. I read your message again carefully, and I see it says "History | Restore previous session". So I open again the Firefox menu, I find the History entry, and I see that's actually a sub-menu! Gee-whiz! Ah, there it is.

All of this may sound stupid, but I think it's worth pointing out that the feature is not in the first 3 intuitive places where I looked, and that I did not even think to look in the place where it actually is.

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Severity: critical → --
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: