Closed Bug 252646 Opened 20 years ago Closed 16 years ago

Firefox should ask if you "really want to close this page" when you close a page/tab with a partially completed form

Categories

(Toolkit :: Form Manager, enhancement)

x86
Windows XP
enhancement
Not set
normal

Tracking

()

VERIFIED WONTFIX

People

(Reporter: jasonlustig, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: dataloss)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040707 Firefox/0.9.2 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040707 Firefox/0.9.2 When you are filling out a form - especially a very big and complex form - it's really quite annoying if you accidentally hit the close button before sending in the form and lose your data. Firefox has the box that pops up if you have multiple tabs open and you try to close the window saying "This window has X tabs open. Are you sure you want to close this window?" It would be really cool if there was a similar box that popped up when you try to close a window or tab with a partially completed form - i.e. you have changed it from what it was originally set to when you loaded the page. That way if you accidentally hit the close button when typing up, say, a bug for bugzilla or something, you won't lose the data. Reproducible: Always Steps to Reproduce: 1. Go to a page with a form 2. Enter some data 3. Before you submit it, accidentally close the window. Actual Results: Window/tab closes without confirmation Expected Results: Window/tab should confirm that you want to close the window/tab
Marking as dataloss
Keywords: dataloss
See also bug 48333, same bug for Seamonkey.
Requesting blocking-aviary1.0
Flags: blocking-aviary1.0?
It makes sense (even more after bug 48333). Confirming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
New feature not on the plan. -
Flags: blocking-aviary1.0PR-
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0-
Yes, it should. This bug was reported against Mozilla a long time ago, and it's causing a very large amount of data loss, especially for people participating in forums...
I'm amazed that this is still "new". I probably lose 10-20k of data a day to this bug when I'm working under Windows. It's a very old bug, and it's something that every non-browser program gets right.
This should be extended to include the back and forward buttons and other things that might accidentally leave a page with changed form data. Under Windows, I'm losing data on a regular basis because the middle mouse button doesn't paste stuff but instead jumps back in browser history.
IMO this should be marked as P3-critical just like other dataloss-related issues.
Bug 48333 has been changed to Product: Core. Wouldn't that make this bus a duplicate?
As an alternative, site authors can use the onBeforeOnload event. Pseudocode: var changed=false; form.onchange = function() {changed=true}; document.onBeforeUnload = function() {if (changed) return "Really close?"} Sorry, that's just a guess at how to do it; I forget the details. Could greasemonkey or similar be used to apply this? --Phil.
Depends on: 48333
Assignee: bugs → nobody
Neither greasemonkey nor onBeforeUnload is good enough. It should just work by default or it's going to break things most of the time for almost all users. However, if a custom onBeforeUnload is registered, should the default "Are you sure?" (as requested in this bug report) be avoided?
Product: Firefox → Toolkit
This is already largely mitigated by session restore and "undo close tab", both of which retain form data. Having a warning on every page with form data would become highly irritating, and page authors can already use onbeforeunload if the data on the page is especially critical.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
How this problem is solved by undo close tab? If I type something and close tab, undo close tab doesn't bring back my typing (which would be fine, btw). It is truth that site may implement some mechanisms, but it is also true that sites generally don't do this. I have no doubts how original Firefox philosophy would resolve this...
Perhaps the right thing is to file a new bug: when you close a tab and go back to it from the Recently closed tabs menu, the form data you entered should be restored. The strange thing is, according to Justin Dolske's comment and bug #419363, this is already the behaviour. Yet I don't see it. When I close a tab in Firefox (for example the Bugzilla page I am typing in now) and go back to it from the list of Recently closed tabs, the form data is lost. So in the Firefox I'm using (3.0.1 on Linux), the data loss problem here is not mitigated in any way by having a list of recently closed tabs. You still have to re-enter all the form data. Could I ask the developers to have another look at what is happening here?
(In reply to comment #14) > Having a warning on every page with form data would > become highly irritating as a regular Safari user, i haven't been highly irritated by this functionality. do you have any data to back up this claim?
reopening, for now. not sure how else to get further explanation from justin.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
(In reply to comment #15) > How this problem is solved by undo close tab? If I type something and close > tab, undo close tab doesn't bring back my typing (which would be fine, btw). It does for me, and is the intended behavour. The browser.sessionstore.privacy_level pref controls if it's done on SSL pages, though. Bug 424872 is about changing the default. (In reply to comment #18) > reopening, for now. not sure how else to get further explanation from justin. I already explained in comment 14. "Undo" capabilities are far less intrusive than annoying modal prompts. See also: http://www.alistapart.com/articles/neveruseawarning
Status: REOPENED → RESOLVED
Closed: 16 years ago16 years ago
Resolution: --- → WONTFIX
ok, justin. i concede that modal prompts are more annoying than straight-forward undo capabilities. i feel that not having page closure undo be integrated with the normal Edit -> Undo functionality disqualifies the current implementation from "straight-forward undo capabilities", (not to mention that it doesn't work for the final tab) but i'll argue that in bug 460360.
Status: RESOLVED → VERIFIED
Please change the status of this bug from "WONTFIX" to "DUPLICATE" : mark it as duplicate for bug 48333 (which is still highly wanted and must be fixed !)
verdy_p: this was supposed to be the firefox bug that depended on bug 48333, the core bug. i agree things are a bit muddled, now, but i'm not convinced duping this on 48333 clears anything up.
You need to log in before you can comment on or make changes to this bug.