GNOME Bugzilla – Bug 119857
Confirm tab/window close with form data
Last modified: 2005-08-15 01:33:44 UTC
The HIG says that an application should always ask for confirmation before doing anything potentially destructive. Quitting a web browser comes into this catagory because the user may have entered information in web forms which will be lost. I have encountered this with Galeon and Epiphany when using web-based email. It's very easy to accidentally press CTRL-W instead of SHIFT-W, resulting in total loss of the email I was writing with no confirmation request. If possible, epiphany should check to see if any currently open pages contain user-entered form data and ask for confirmation if so.
It sounds like a bit of an overkill to me, Dave ?
1. You can't quit ephy, only open and close browser windows :) 2. my opinion is pretty well sumed up here http://www.advogato.org/person/funrecords/diary.html?start=11 Tabbed MDI Strikes Mozilla Again In attempt to deal with the monstrosity known as tabbed MDI, mozilla developers have now added a "Do you really want to close all these tabs" dialog, a variation on the horribly annoying "Do you really want to quit" dialog. The solution to this problem is really not all that difficult. Instead of trying to deal with the data loss caused by allowing users to close a group of documents at once, simply only allow the user to close one tab at a time. Epiphany gets this right. The file menu close item only closes the current tab. If there is only one tab in a window, the window is closed. Now if I can only get them to implement the same behavior for the window border close button.
The last comment has misunderstood the problem. I mistakenly wrote "Quit" in my original report because I first encountered this problem with Galeon which does have a Quit button. However the situation is exactly the same when the user can easily close a tab/window/whatever by accident. To illustrate, go to your favourite web-based email provider, select "compose", start typing, then 'accidentally' hit ctrl-w rather than shift-w. You have just lost what you were typing :-( No email client would quit when the user was in the middle of composing an email without asking for confirmation, and lots of people use web based email. This isn't a theoretical problem, it has bitten me personally a couple of times. I agree that checking to see if there's data in a form seems like overkill, but in that case it should simply always ask for confirmation whenever a tab is closed. Of course this could prove annoying, which is why I suggested doing the check.
Another reason why web-based e-mail is just crack... Though I agree that a warning would be useful when unsubmitted form data exists.
Created attachment 22859 [details] [review] implementation
My patch detects if there has been user input in text fields, and if so, asks for confirmation before really closing the tab/window.
You can see in embedding/components/find how to deal with frames. I'm not sure about the multiple messages thing, user tend to not read, or not read carefully alerts. I have the impression that activating the tab with unsent form would be more attention catching. Dave ?
Bumping the priority level to High because of the patch attached.
Created attachment 22872 [details] [review] updated patch
Changes in the updated patch: - works with framed documents too - jump to the first tab with modified forms when trying to close the window, before showing the dialogue - HIGgify confirm dialogue
- notebook = EPHY_NOTEBOOK (gtk_widget_get_parent (child)); - ephy_notebook_remove_page (notebook, child); + ephy_window_remove_tab (window, tab); I'd prefer to not call window_remove_tab because I want to keep it just a wrapper around notebook api. What about a tab-delete signal to mirror window-delete ? +nsresult EphyBrowser::GetHasModifiedForms I feel the two funcs with the same name a bit confusing. What about GetDocumentHasModifiedForms ? About the messages. I tend to think this would be enough and that we could make the more distinctions if there is evidence we need to: There are unsubmitted changes to form elements. If you close the document anyway, you will lose that information. At least I'm assuming "form" is a common word in english, not a technical one, right ?
Created attachment 22879 [details] [review] updated patch with the requested changes
Looks good. You have the patch for the slow closing bug too, but I think it's ok to commit. Just close the other bug too please. Thanks !
Hrm I just realized this could prove to be annoying on stuff like search engines. What do you think ? Dave ?
Maybe we could be smart and have a min text length. Another thing, did you check if this has bad effects on closing perf on long documents ?
An alternative logic could be 1 text area or more than 2 inputs.
An alternative logic could be 1 text area or more than 1 input.
I see from the code that there should not perf probs. Still not sure about the logic. Our warning is similar to the closing text editor window one. Though on the web forms arent ever "documents". Doing a text length check we risk to lose cases where someone typed a long code (short but slow and painful to type), doing 2 input or 1 area check we risk to catch u/p dialogs (not sure if a warning would be good in this case).
Created attachment 22885 [details] [review] updated patch, also check textareas for input
Just FYI: "Form" is a common word in English and most users should already know what it means and how it relates to Web browsing.
The "password" entry fields aren't considered, I explicitly skip them. Still there will be the "username" field.
Ok. So I think we should check that there is at least two input fields or one textarea.
Created attachment 22900 [details] [review] upate patch; require 2 modied text fields or one textarea
Looks good. Thanks !!!
Checked in. If neccessary, we can tweak the metric later on.
*** Bug 132598 has been marked as a duplicate of this bug. ***