I thought the gaining philosophy here was to make "destructive" operations easy to undo, rather than having warnings and confirmations before carrying them out?
Quitting Firefox and then starting again and restoring all tabs fits well with easy to undo.
Forget confirmation, Ctrl-Q shouldn't exist in the first place. An keystroke that can close your whole session and is near-identical to another, very common keystroke is a design flaw, period.
Same with the backspace key activating the back button. Using these keystrokes for these purposes should be considered harmful.
Ctrl-Q is so harmful that I've long fantasized about hacking whatever driver in the kernel that controls the keyboard and having it ignore whatever signal the keyboard sends out whenever you press Ctrl-Q and not even pass it on to userspace.
On OSX I have a tiny applescript running inside Butler[1] that's active when firefox is foregrounded, and just intercepts Ctrl-Q and runs:
tell application "Firefox"
set buttonStr to "Ooops"
set errMsg to "Close with ?-Q disabled. Use the menu."
display dialog errMsg buttons {buttonStr} cancel button buttonStr default button buttonStr with icon stop giving up after 5
end tell
I'd imagine similar options exist for other OSes. AutoHotkey for windows, maybe? Not sure what linux/x has by way of systemwide handlers that can both intercept and cancel propagation of offending bindings, though.
I don't see how it can undo everything, if you'll lose data in the process. Not every open page is static and some can have user input and what not. Exiting the browser will wipe it all out, and restarting it isn't going to help.
So confirmation for Ctrl+Q is a must, there is no question about it. And if you don't want it - they can make an option that can turn it off.
"if you'll lose data in the process. Not every open page is static and some can have user input and what not. Exiting the browser will wipe it all out, and restarting it isn't going to help."
Not only that, but it can take a significant amount of time to restart the browser and reload the tabs you had open.
So just in terms of time wasted, accidentally quitting the browser and having to restart it is awful and painful compared to just canceling the quit.
Something that drives me nuts is how stateful about:config options are. If you set them once, either through about:config or using a user.js, they will stay like that forever unless you explicitly unset them.
Oh no, persistency is great. But the problem is how non-functional their implementation is.
Say I write a user.js file with a few options. I can't have the typical dotfile model, where removing options from this file will lead to defaults on the next run. I need to unset them. Explicitly.
Thus, using a dot file to set up Firefox (user.js) is incredibly clunky and people don't use this much.
I agree that in most cases an easy undo is much better than confirmations, but in this case is just such a huge pain in the ass to restart all your tabs that the confirmation is a better solution.
It's not binary. Both solutions can coexist as long as we choose the right tool for the job.
Unfortunately, restoring state after quitting on MacOS is not trivial. Specifically, restoring all your windows to the right spaces. No browser on MacOS (not even Safari) manages to do this...
Quitting Firefox and then starting again and restoring all tabs fits well with easy to undo.