Closed Bug 592822 Opened 14 years ago Closed 14 years ago

Remove quit warning dialog

Categories

(Firefox :: General, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 4.0b10
Tracking Status
firefox5 - ---
firefox6 - ---
blocking2.0 --- betaN+

People

(Reporter: zpao, Assigned: zpao)

References

Details

(Whiteboard: [hardblocker][fx4-fixed-bugday])

Attachments

(4 files, 4 obsolete files)

I mentioned in bug 588482 comment #14 that I was going to drop the dialog changes out so that we could get something going sooner rather than later. Planned steps here are to just remove the dialog path under most cases, but the specifics get a little tricky for different platforms. I know we talked about only having the quit dialog show on OSX when you use Command-Q, but I'm not actually sure how feasible that is. I only briefly looked into it. On win/Linux, not sure if we should just quit or if we should show the "closing multiple tabs" dialog. I don't think this needs any strings. If anything it might remove some.
Since this is behavior altering, I guess this should be a b6 blocker?
blocking2.0: --- → ?
Attached patch Patch v0.1 (WIP) (obsolete) (deleted) — Splinter Review
WIP so far. Mostly just changes a couple default pref values & the rules for showing the dialog (not 100% sure those are right).
Attachment #473193 - Flags: feedback?(gavin.sharp)
Attached patch Patch v0.2 (WIP) (obsolete) (deleted) — Splinter Review
Fixed a couple things: 1. use the right variable name 2. keep existing behavior for browser-lastwindow-close-granted behavior and sessionstore on Windows/Linux Keep in mind this is meant to be applied on top of bug 588482
Attachment #473193 - Attachment is obsolete: true
Attachment #473258 - Flags: feedback?(gavin.sharp)
Attachment #473193 - Flags: feedback?(gavin.sharp)
Behaviour-altering isn't the test here, feature completeness is. Behaviour altering is the test for whether it needs to be in *a* beta. I think this does.
blocking2.0: ? → betaN+
Blocks: 590483
Whiteboard: [has patch][needs feedback gavin]
The UX team would like to see this in beta8 if possible, so we can get some feedback on any potential "OMG, my session is gone and I can't figure out how to get it back" issues, so we have time to adjust in beta9 if that's indeed a problem. Right now, we are implicitly saving the session, but people don't see the effects of that, since we ask on exit whether to restore every time anyway.
(In reply to comment #5) > The UX team would like to see this in beta8 if possible, so we can get some > feedback on any potential "OMG, my session is gone and I can't figure out how > to get it back" issues, so we have time to adjust in beta9 if that's indeed a > problem. > > Right now, we are implicitly saving the session, but people don't see the > effects of that, since we ask on exit whether to restore every time anyway. This is my major concern. The quit dialog has saved my session on numerous occasions and fairly regularly. If the recently closed windows can indeed restore old sessions, I'm fine with this removal, but if that is the case, we're lacking in terms of educating users about that. If not, perhaps we could extend that feature to be able to restore sessions?
zpao: will this bug change the preference in options > tabs > warn me when I close multiple tabs, or simply suppress the dialog box on exit?
I think this is a bad idea, because sometimes you really want to kill all these tabs by exiting the browser WITHOUT saving the session, so it should be in the hand of the user to decide whether or not the current session should be saved or not.
I don't think there's any more UI feedback needed here, but we should make sure we have a visible way to restore the previous session, ideally on the Firefox Start page — a link to "Restore previous session (N windows, M tabs)". This is tracked in bug 593421.
Keywords: uiwanted
Attached patch Patch v0.3 (obsolete) (deleted) — Splinter Review
Took out debugging stuff and an error that I was throwing (which I think was impossible to hit anyway). I also took out the session restore change (that part got changed in session restore anyway). I think we're ok (on OSX at least) without it. I haven't looked at Win/Lin yet - will test in the office on Monday.
Attachment #473258 - Attachment is obsolete: true
Attachment #500430 - Flags: review?(gavin.sharp)
Attachment #473258 - Flags: feedback?(gavin.sharp)
Comment on attachment 500430 [details] [diff] [review] Patch v0.3 (In reply to comment #10) > I also took out the session restore change (that part got changed in session > restore anyway). I think we're ok (on OSX at least) without it. I haven't > looked at Win/Lin yet - will test in the office on Monday. Well, I looked at it on a Monday, only a week late. So this doesn't work on Win/Lin as we used to. Take this case: 1. One browser window with some tabs open 2. Prefs window/error console/something secondary 3. Close the browser window Now we click on a link that would launch Firefox Previously: Firefox would open with the new link opened along with the tabs from the last closed window. As is: Firefox will open the new link by itself and the tabs from the last closed window are in the recently closed windows list. We should keep existing behavior here, so I think I'll just have to make the right changes in session store. Gavin, any chance you can look at this ASAP in case there are things you aren't going to like?
Attachment #500430 - Flags: review?(gavin.sharp) → feedback?(gavin.sharp)
Attached patch Patch v0.4 (obsolete) (deleted) — Splinter Review
Updated to do the right thing with that half-aborted session.
Attachment #500430 - Attachment is obsolete: true
Attachment #502977 - Flags: review?(gavin.sharp)
Attachment #500430 - Flags: feedback?(gavin.sharp)
Whiteboard: [has patch][needs feedback gavin] → [has patch][needs review gavin]
Flags: in-litmus?
Whiteboard: [has patch][needs review gavin] → [has patch][needs review gavin][hardblocker]
> + (aQuitType == "restart" && Services.pregs.getBoolPref("browser.warnOnRestart"))); Services.pregs? wozzat?
This should go away, to prevent this sort of thing from slipping through: + } catch (e) {} Also, since we can't test this in XPCShell, it should get a mozmill test (which are in contiguous integration now, IIRC).
(In reply to comment #13) > Services.pregs? wozzat? It's how babby is formed.
Comment on attachment 502977 [details] [diff] [review] Patch v0.4 discussed this on IRC, I think we want: - try to minimize code changes (ideally just flip the default for warnOnQuit, and maybe remove the setting of warnOnClose) - not touch warnOnClose pref default (avoid affecting window-close behavior)
Attachment #502977 - Flags: review?(gavin.sharp) → review-
Whiteboard: [has patch][needs review gavin][hardblocker] → [hardblocker][needs new patch]
Attached patch Patch v0.5 (deleted) — Splinter Review
Took out most of the browserglue changes (but changed which pref we set from the dialog) and left the default for warnOnClose alone.
Attachment #502977 - Attachment is obsolete: true
Attachment #505172 - Flags: review?(gavin.sharp)
Whiteboard: [hardblocker][needs new patch] → [hardblocker]
Whiteboard: [hardblocker] → [hardblocker][has patch][needs review gavin]
Comment on attachment 505172 [details] [diff] [review] Patch v0.5 Discussed this IRL - r=me on the firefox.js changes with the nsBrowserGlue change omitted. (The reasoning there is that it's not worth mucking around with what will be the non-default behavior - hidden behind a hidden pref - at this stage.) I think the sessionstore changes are fine too, but getting dietrich to review those would be best.
Attachment #505172 - Flags: review?(gavin.sharp) → review+
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Whiteboard: [hardblocker][has patch][needs review gavin] → [hardblocker]
Target Milestone: --- → Firefox 4.0b10
I disabled a test which failed as a result of this, because Paul promised to fix it! http://hg.mozilla.org/mozilla-central/rev/e470f73808f7
This is horrible - How do I start a fresh session, if I have to set 'show my windows/tabs' from last time'. I've always relied on the save/quit/cancel and just lost my 25 tabs when I closed the browser due to no warning, and having the setting in options to 'show my home page'...
(In reply to comment #21) > This is horrible - How do I start a fresh session, if I have to set 'show my > windows/tabs' from last time'. If you had "show my windows/tabs from last time" set you weren't seeing a quit dialog anyway. > I've always relied on the save/quit/cancel and > just lost my 25 tabs when I closed the browser due to no warning, and having > the setting in options to 'show my home page'... In that case, your previous session is available in the history menu (restore previous session). If you're on Windows with the Firefox button, click the firefox button then history. We are working on making that more discoverable by putting a button on the home page (bug 593421).
(In reply to comment #22) > (In reply to comment #21) > > This is horrible - How do I start a fresh session, if I have to set 'show my > > windows/tabs' from last time'. > > If you had "show my windows/tabs from last time" set you weren't seeing a quit > dialog anyway. > > > I've always relied on the save/quit/cancel and > > just lost my 25 tabs when I closed the browser due to no warning, and having > > the setting in options to 'show my home page'... > > In that case, your previous session is available in the history menu (restore > previous session). If you're on Windows with the Firefox button, click the > firefox button then history. > > We are working on making that more discoverable by putting a button on the home > page (bug 593421). That's still pretty horrible, that restores the previous session in a new window. I like the option on exit.
(In reply to comment #23) > That's still pretty horrible, that restores the previous session in a new > window. I like the option on exit. That's bug 627642.
(In reply to comment #24) > (In reply to comment #23) > > That's still pretty horrible, that restores the previous session in a new > > window. I like the option on exit. > > That's bug 627642. I think we need to somehow create an option somewhere to clear the session. While I was apprehensive about this bug. Restoring a previous session is incredibly easy, it's just something we generally forget about. But there needs to be a way to quit with multiple tabs open and not have the session restored when reopening the browser. I would suggest an alternative way of closing the browser, which doesn't require the user to close all tabs first.
(In reply to comment #25) Perhaps holding shift while clicking Exit can clear a session on exit?
The expectations changed here now that we restore in the not-quite-quitting case instead of looking at the prefs. Went green on try.
Attachment #505172 - Attachment is obsolete: true
Attachment #505848 - Flags: review?(dietrich)
Attachment #505172 - Attachment is obsolete: false
Attachment #505848 - Flags: review?(dietrich) → review+
This is a very bad design choice IMHO. Anyone finding it a bit incongruous that closing a window will warn you about closing multiple tabs, yet closing the last window will not? This seems like very inconsistent behavior to me. I mean, if we're going to disable warnOnQuit by default, why not warnOnClose since we have a menu option to restore a window too? Both dialogs "get in your way". There are two ways that I can see to eliminate this inconsistency: 1.)There should be a visible pref in Options -> Tabs that lets you choose warnOnQuit behavior. 2.)Make "Warn me on closing multiple tabs" pref control both warnOnClose and warnOnQuit.
(In reply to comment #28) you're right, the warning should be consistent. the option should probably be removed in favour of a doorhanger type notification that'll offer the user to restore the window.
(In reply to comment #28) > This is a very bad design choice IMHO. Anyone finding it a bit incongruous that > closing a window will warn you about closing multiple tabs, yet closing the > last window will not? This seems like very inconsistent behavior to me. You can restore the session easily if you quit the application, and this will be very visible once bug 593421 lands. I'd prefer getting rid of the window warning too, but not until Undo Closed Tab/Window is a bit easier to discover and use. Right now, people are still not aware that Firefox allows you to undo these operations (and indeed, Ctrl-Z and the Undo in the menu doesn't actually undo these operations!), so it'll be a compromise for now. Post-Firefox 4, we want to make this better.
(In reply to comment #30) > (In reply to comment #28) > > This is a very bad design choice IMHO. Anyone finding it a bit incongruous that > > closing a window will warn you about closing multiple tabs, yet closing the > > last window will not? This seems like very inconsistent behavior to me. > > You can restore the session easily if you quit the application, and this will > be very visible once bug 593421 lands. I'd prefer getting rid of the window > warning too, but not until Undo Closed Tab/Window is a bit easier to discover > and use. Right now, people are still not aware that Firefox allows you to undo > these operations (and indeed, Ctrl-Z and the Undo in the menu doesn't actually > undo these operations!), so it'll be a compromise for now. Post-Firefox 4, we > want to make this better. Its not about how easy it is to restore session. It's about accidentally closing a window with multiple tabs. What if you have a flash video playing and you've spent a while buffering it. Then you switch to another tab and accidentally close the window. Restarting Firefox and restoring the session is not going to give back the video you've buffered. It just doesn't make sense for secondary windows to warn and the main window to not warn. There are things that restore session CAN NOT PREVENT.
Filed bug 628080 to later determine the default value of the pref.
As I stated in comment 29, as long as we offer a method to restore a window in a single should we accidentally close a window, we should be fine*. also we can work on improvements to the cache to make sure things like accidentally closed buffered videos don't have an interrupted service. No matter how you look at it, bug 628080 doesn't actually solve anything, it just attempts to brush the problem under the carpet. Thus if we do land something along the lines of what I've suggested, we can take on the responsibility of offering an extension to provide the old behaviour of warn on quit. * Add preference to offer restoration of closed windows in a yellow bar dropdown or doorhanger to replace inconsistent quit warning dialog.
(In reply to comment #33) > As I stated in comment 29, as long as we offer a method to restore a window in > a single should we accidentally close a window, we should be fine*. also we can > work on improvements to the cache to make sure things like accidentally closed > buffered videos don't have an interrupted service. No matter how you look at > it, bug 628080 doesn't actually solve anything, it just attempts to brush the > problem under the carpet. Thus if we do land something along the lines of what > I've suggested, we can take on the responsibility of offering an extension to > provide the old behaviour of warn on quit. > > > * Add preference to offer restoration of closed windows in a yellow bar > dropdown or doorhanger to replace inconsistent quit warning dialog. Is it possible to save the state of the flash plugin? I thought this is out of the scope of what the cache can do.
(In reply to comment #34) > Is it possible to save the state of the flash plugin? I thought this is out of > the scope of what the cache can do. Occasionally I will reload a tab and the video will still be cached, so I'm assuming that their have been advancements in that field. But I'll defer this question to someone better educated on the subject.
(In reply to comment #34) > Is it possible to save the state of the flash plugin? I thought this is out of > the scope of what the cache can do. bug 597979
Limi and Faaborg do you think the UX Team can push for a higher priority on bug 597979 in relation to this one?
Not that bug 597979 wouldn't be nice to have, but the impact of re-caching the video isn't terrible, and with bar tab style tab loading, we are really more heading in the other direction, clearing items out of memory that don't appear to be in use to improve performance.
Well the logic would be if a tab/window with a flash/video is closed longer than XX minutes then clear the cache as per normal, otherwise hold it. It'd literally be a matter of allowing a user to undo an accidentally closed window. If something like that did land not only do we not have to worry about angry users accidentally closing windows and not being warned, but it'd provide more extensibility to Firefox in that I'm sure extensions will pop up to enable the user to only clear the flash/video cache every XX days as opposed to minutes. Of course users can treat flash/video as per normal pages with a flick of a hidden pref. Let's not forget that Flash often takes significantly longer to load than a normal webpage and if we can provide a means to make reloading flash content quicker while killing everything else in memory, it's a win/win.
if no warning on closing window with multiple tabs, "Warn me when I close multiple tabs" option should be delete ?
>"Warn me when I close multiple tabs" option should be delete ? Discussion on that is over in bug 628080
(In reply to comment #0) > I know we talked about only having the quit dialog show on OSX when you use > Command-Q, but I'm not actually sure how feasible that is. I only briefly > looked into it. It's an on-going pain for me and now even more. Closing a tab (Cmd+W) and quitting the browser (Cmd+Q) are too close next to each other. It happens all the time that I accidentally hit Cmd+Q instead of Cmd+W and it takes about 4-5 minutes until I have the new browser session open.
(In reply to comment #42) > (In reply to comment #0) > > I know we talked about only having the quit dialog show on OSX when you use > > Command-Q, but I'm not actually sure how feasible that is. I only briefly > > looked into it. > > It's an on-going pain for me and now even more. Closing a tab (Cmd+W) and > quitting the browser (Cmd+Q) are too close next to each other. It happens all > the time that I accidentally hit Cmd+Q instead of Cmd+W and it takes about 4-5 > minutes until I have the new browser session open. Yes, it's definitely something we want to fix. Quitting with Cmd-Q is easier to accidentally do than closing the window (OS X) or selecting Quit/Exit from the menu. Whether we can get it in before 4.0, I don't know. :)
(In reply to comment #43) > > It's an on-going pain for me and now even more. Closing a tab (Cmd+W) and > > quitting the browser (Cmd+Q) are too close next to each other. It happens all > > the time that I accidentally hit Cmd+Q instead of Cmd+W and it takes about 4-5 > > minutes until I have the new browser session open. > > Yes, it's definitely something we want to fix. Quitting with Cmd-Q is easier to > accidentally do than closing the window (OS X) or selecting Quit/Exit from the > menu. Whether we can get it in before 4.0, I don't know. :) Alex, do you know if we already have a bug for this particular issue?
(In reply to comment #44) > (In reply to comment #43) > > Yes, it's definitely something we want to fix. Quitting with Cmd-Q is easier to > > accidentally do than closing the window (OS X) or selecting Quit/Exit from the > > menu. Whether we can get it in before 4.0, I don't know. :) > > Alex, do you know if we already have a bug for this particular issue? Yes, bug 550559.
What's the rationale for not restoring the session by default after closing the last/only window with multiple tabs? People without about:home as their homepage (many people) who rely on the quit dialog to let them choose "Save and Quit" (many people) will now think that all of their tabs have disappeared. Restoring by default would annoy the people who did just want to quit and not recover the tabs that are still open, but I think that is less annoying than effectively losing all of your tabs (and possibly less common). The best solution in my opinion would probably be to have left this dialog. People are used to "warn-on-quit" dialogs when there is unsaved data in their word processor (and usually appreciate the warning), so why not in their browser?
(In reply to comment #49) > What's the rationale for not restoring the session by default after closing the > last/only window with multiple tabs? > > People without about:home as their homepage (many people) who rely on the quit > dialog to let them choose "Save and Quit" (many people) will now think that all > of their tabs have disappeared. > > Restoring by default would annoy the people who did just want to quit and not > recover the tabs that are still open, but I think that is less annoying than > effectively losing all of your tabs (and possibly less common). > > The best solution in my opinion would probably be to have left this dialog. > People are used to "warn-on-quit" dialogs when there is unsaved data in their > word processor (and usually appreciate the warning), so why not in their > browser? Options -> General -> When Minefield/Firefox Starts: -> Restore my windows and tabs from last time.
(In reply to comment #50) > Options -> General -> When Minefield/Firefox Starts: -> Restore my windows and > tabs from last time. OK, so what's the rationale for that not being the default now that the warning dialog has gone? I'm thinking of the majority of users who don't ever go to the options panel and who have come to rely on the browser restoring their session when they save it.
(In reply to comment #51) > OK, so what's the rationale for that not being the default now that the warning > dialog has gone? > > I'm thinking of the majority of users who don't ever go to the options panel > and who have come to rely on the browser restoring their session when they save > it. It looks weird right now since there are two missing pieces that are about to land (but weren't in beta 10): * We'll warn on window close by default if you have more than 1 tab * The default start page will have a large "restore previous session" link on it Give it a few days (if you're on the nightlies), and this should be much better.
(In reply to comment #38) > Not that bug 597979 wouldn't be nice to have, but the impact of re-caching the > video isn't terrible, and with bar tab style tab loading, we are really more > heading in the other direction, clearing items out of memory that don't appear > to be in use to improve performance. What about the impact of re-loading 10 Youtube tabs when you restore a session? Sometimes I'll close Firefox and save the session and I had 10 Youtube tabs open. When I re-open FF, they all start playing at once and needless to say, this is annoying (as well as making Firefox take a long time to start up). Bad design decision, guys. I think the pre-quit dialog was a Good Thing.
(In reply to comment #52) > * We'll warn on window close by default if you have more than 1 tab Am I misunderstanding here, or is what you're doing changing the behaviour from: 'Warning: you're closing X tabs. Save session or not? Check here not to be warned again.' to 'Warning: you're closing X tabs. Check here not to be warned again.'
(In reply to comment #52) > * We'll warn on window close by default if you have more than 1 tab > > * The default start page will have a large "restore previous session" link on > it Bug 629485 and bug 593421. OK. Do you have an estimate for the percentage of users that will have about:home as their start page? I still think that for those that don't, session restore isn't discoverable enough. IE8 has helpfully walked this path already. You can see the way in which it confused people by looking through the first few pages of this query: http://www.google.co.uk/search?q=%22Internet+Explorer+8%22+OR+%22IE8%22+%2Btabs+OR+%2Bsession+%2Bsave+OR+%2Brestore+OR+%2Breopen+OR+%2Bre-open&hl=en&num=10&lr=&ft=i&cr=&safe=off&tbs=
Depends on: 593421
I also encourage anyone who feels like a chuckle to read bug #383760. Seems like those guys got it wrong all along! They should've consulted the all-knowing oracles of the UX team and realized that it was a bad idea to introduce.
Attached image Table of previous and future solutions (deleted) —
>They should've consulted the all-knowing oracles of the UX team and realized >that it was a bad idea to introduce. It was better relative to the user losing their session when they closed (unless they had set it to always save). Attached is a comprehensive review of close behavior progress over time.
Attached image Table of previous and future solutions (deleted) —
(attached the wrong file)
Alex, Doesn't your table assume that session can be perfectly restored upon Firefox's restarting, and in a timely manner? Try having a bunch of Youtube windows open, for example. Not only will session restore take ages, you will not get the same session you had before. Videos will reload and play from scratch, and whatsmore page Javascript will be re-run. As session restores isn't gonna be anywhere near perfect for the forseeable future, I'd argue that any solution which relies on 'restore session' being just as good as 'dont kill off the current session' is a bad one.
>Doesn't your table assume that session can be perfectly restored upon Firefox's >restarting, and in a timely manner? No, but it does assume that intentional mouse based window close events very significantly outnumber unintentional mouse based window close events, and that users who very often unintentionally close the window by clicking on the window close icon will likely choose to opt into the warning.
Opting into the warning requiring the changing of a setting in about:config? I suspect I would be one such user.
We'll probably re-work the pref in options > tabs. Either way, that's Firefox 5 work now.
(In reply to comment #56) > I also encourage anyone who feels like a chuckle to read bug #383760. Seems > like those guys got it wrong all along! They should've consulted the > all-knowing oracles of the UX team and realized that it was a bad idea to > introduce. Apologies for my comments. I posted this in the heat of the moment and should've been more civil with what I said.
(In reply to comment #63) > > Apologies for my comments. I posted this in the heat of the moment and > should've been more civil with what I said. no biggies, Jeremy. at least you admitted your fault on that one. I sure miss that warning dialog box in Firefox 4.0 beta 10 when closing the browser with multiple tabs. it almost felt like using Google Chrome when closing that browser with multiple tabs open. hopefully the quit warning box would get restored in beta 11. I was wondering how the warning dialog box got "broken" in beta 10.
(In reply to comment #64) > hopefully the quit warning box would get restored in beta 11. It won't. > I was wondering how the warning dialog box got "broken" in beta 10. This was an intentional change per this bug.
Status: RESOLVED → VERIFIED
Whiteboard: [hardblocker] → [hardblocker][fx4-fixed-bugday]
Verified with Mozilla/5.0 (X11; Linux i686; rv:2.0b12pre) Gecko/20110204 Firefox/4.0b12pre
The removal of this dialog is very destructive in my situation. I have Firefox set to automatically clear my private data on exit since I like to start with a clean session about 99% of the time. What this means though is that if I accidentally close my browser, I have now lost ALL my tabs permanently. That little warning window (and subsequently clicking cancel) has saved me from losing my current session countless times. I can't be the only one who has their browser set this way. As a secondary point, it took me a good couple weeks to figure out where that warning went. I just figured it was a regression bug since I explicitly have the "Warn me when closing multiple tabs" option checked.
(In reply to comment #67) > As a secondary point, it took me a good couple weeks to figure out where that > warning went. I just figured it was a regression bug since I explicitly have > the "Warn me when closing multiple tabs" option checked. I think this shows that we need to do a much better job at communicating these types of changes.
This isn't a change, though, it's a losee of functionality. Session restore != keep session open.
(In reply to comment #69) > This isn't a change, though, it's a losee of functionality. Session restore != > keep session open. It's not a "loss of functionality" as there was a design decision to remove the dialog. I completely understand the reasons behind why you think it should be put back. However, this bug is not the appropriate forum. The point of this bug was to implement the change of removing the dialog. This has been done. Please move further discussion to a new bug asking for it to be put back or to a newsgroup thread (I suggest dev-apps-firefox). Thanks.
You probably look for bug 550559.
"A design decision to remove the dialog"?! I have browser.warnOnQuit set to default (true). Beta 11 gives me a blank screen on restart with no hint of how to restore my session. By not restoring it you are creating a DELIBERATE BUG and potentially **** off tens of millions of people. What POSSIBLE 'design decision' could justify that? I posit that you are losing your way - design before function. Please don't scupper your reputation.
I appreciate your point of view and recognize your passion for Firefox. However, as I said earlier, this bug is not the appropriate platform. Please move this discussion to a mailing list post on dev-apps-firefox@lists.mozilla.org
With apologies for the poor etiquette, I think the people responsible for this decision need to realise just what they're doing: deliberately losing user data! It's hard to imagine a Word update where quitting the program suddenly no longer prompted the user to save their work. Yet that's exactly the nature of what you're doing here. Sites can be near impossible to re-find and users can have scores of tabs open. This data is valuable to them, and you have increasingly been at pains to retain it, even after a crash. This latest decision totally flies in the face of that. Surely, you can't seriously be arguing "Well, they should have known to go into about:config and manually set browser.warnOnQuit to true before updating Firefox"? Simply do not change the default to 'false' - if you do it's deliberate and scandalous loss of user data. Thank you.
This is extremely bad behavior. Call me old school, but I tend to reflexively go for the main x far to often,. and having this dialogue come up has saved me a ton of times. Not having it really messing me up. Also, the menu setting is now confusing. I kept going in and checking to see if the browser had forgotten 'warn when closing multiple tabs'. That does not say 'unless it is the last window'. By checking it, the user logically expects that any time they close a window with multiple tabs, they will be prompted. As far as a user is concerned, closing the last window is no different from closing one window out of six. Many people, like me, only use one window and have a bunch of tabs, something made even easier with tab candy (or whatever it is called now). Having that feature and an option that is supposed to make it safer but basically does nothing if you use it is nonsensical.
(In reply to comment #75) > Also, the menu setting is now confusing. I kept going in and checking to see if > the browser had forgotten 'warn when closing multiple tabs'. That does not say > 'unless it is the last window'. By checking it, the user logically expects that > any time they close a window with multiple tabs, they will be prompted. That was corrected in bug 629485. We will show the "closing multiple tabs" warning when closing the last window.
No longer blocks: 627823
Depends on: 636806
Depends on: 644693
Depends on: 645020
No longer depends on: 645020
It seems we need a user-doc on this, since we see so many times people ask what happened to the dialog, thinking there is loss of functionality, etc... There are multiple ways to have your session restored if your reading this bug for the first time, please try these options: Turn on show your tabs from last time on startup in options panel general. Turn on warn me when I quit multiple tabs dialog in options panel tabs. Check the history menu after you restart the browser for restore previous session. Check about:home when you startup with the default homepage for restore previous session button. If you want see the save tabs dialog, set about:config pref browser.showQuitWarning;true
I've filed bug 645554 to enable a clean session on startup independent of the preference. It's been marked as an enhancement (though I feel it's an important usability that deserves more consideration than the usual amount an enhancement bug gets) but thought being as it's inline with the changes here, I'd bring it's existence to light here.
Depends on: 645338
Depends on: 653900
we need to get this considered for ride along for firefox 5, or as part of firefox 6. article in Providence Journal this moring sugggests not upgrading to Firefox 4 because tabs are lost on re-start. http://www.projo.com/lifebeat/content/MOZILLA_UPDATE_06-14-11_VFO99CG_v6.1f1641e.html
We're not tracking this for Firefox 5.
>we need to get this considered Currently the only effected users are people who have customized their home page (although admittedly that's very a sizable group of people). I've filed bug 664314 as a short term fix, which I believe we should move forward with quickly. (I thought we already started work on this, but I couldn't find a bug, we may need to dupe 664314 if it turns out we are in fact already work on it).
(In reply to comment #82) > >we need to get this considered > > Currently the only effected users are people who have customized their home > page (although admittedly that's very a sizable group of people). I've > filed bug 664314 as a short term fix, which I believe we should move forward > with quickly. (I thought we already started work on this, but I couldn't > find a bug, we may need to dupe 664314 if it turns out we are in fact > already work on it). While I agree with this option, I also think we should easily do bug 645338 and that would fix it for our non techie users who cry fowl wolf and don't try to research and learn. I also don't see any UX or technical reason not to give users a checkbox in prefs->Tabs to keep it simple for everyone.
This isn't version specific and as such we aren't tracking for 6. smooney will take the action item to talk to product, UX, and engineering to figure out the right way forward
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: