User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:220.127.116.11) Gecko/2009042315 Firefox/3.0.10 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:18.104.22.168) Gecko/2009042315 Firefox/3.0.10 Hello Firefox-Team, I have found following Bug in 3.0.10 (I don't have checked Shiretoko/Minefield). *See Steps to reproduce* Thanks in advance. Regards Mehmet Reproducible: Always Steps to Reproduce: 1. Change the Toolbar. For example: insert a new button or hide the Bookmark-Bar. 2. Quit Firefox with "right-click" (context-menu) on the "Dock-Icon". 3. Start Firefox new. Actual Results: The changes from step "1" are not saved. Expected Results: The changes from step "1" should be saved. This behavior only comes up when I quit Firefox with a right-click (context-menu) on the dockicon after I have done changes on the Toolbar. With cmd-Q or by using "Quit" in the Menu-Bar this behavior doesn't happen.
I think pressing Quit on the dock icon sends a kill signal to the Firefox process, which leads to an unclean shutdown.... So your bug is basically a request for storing toolbar changes when the change is made rather than at shutdown?
(In reply to comment #1) > So your bug is basically a request for storing toolbar changes when the change > is made rather than at shutdown? Hello Patrick, Oh yes, it would be great, if you can realize this :-) Regards Mehmet
Confirmed with Mac OS X 10.5.6 (nl_NL) / Firefox 3.5b4 (nl_NL). However, I think it would also be worth to make sure that either regular method of quitting the application (File->Quit, dockbar->Quit, Cmd-Q) has the same effect. Because from the user's perspective a difference in behaviour would be unlogical. However, using Force-Quit (or `kill -9' or so) is different by nature, of course. I will open a new bug report just for this, because it's slightly different from the exact request from the originator.
I've created a separate bug for the generic consistency issue in Firefox, see bug 491265.
Component: Toolbars → Toolbars and Toolbar Customization
Product: Firefox → Toolkit
QA Contact: toolbars → toolbars
Why it is different from the steps in comment 0? The reporter has only told about bullet 3 in your newly filed bug. We should work on this in a single bug. Markus, do you know what is different in closing Firefox via the menu item or via the dock?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hardware: x86 → All
Version: unspecified → 1.9.0 Branch
Huh, no idea. This is definitely disturbing and needs investigating.
The general problem is a real hornets nest, and not at all easy to fix. The browser's shutdown sequence (in nsAppRunner.cpp and elsewhere) will probably need to be substantially re-written to make what happens on Dock : Quit the same as what happens on Firefox : Quit. (See bug 384284 comment #18 and bug 384284 comment #19.) This is unlikely to happen anytime soon. But it might be possible (i.e. not too difficult) to save Toolbar changes at a different point in the shutdown sequence -- one that's touched both when you do Dock : Quit and when you do Firefox : Quit. If it's any consolation, the general problem used to be even worse -- before I fixed bug 377506.
Forgot to ask -- does this problem also happen on the trunk (in Minefield nightlies)?
> But it might be possible (i.e. not too difficult) to save Toolbar > changes at a different point in the shutdown sequence -- one that's > touched both when you do Dock : Quit and when you do Firefox : Quit. For an example of this kind of thing, see bug 404531 comment #19.
Yes, still happens with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090610 Minefield/3.6a1pre ID:20090610032606
Perhaps related to bug 497482
Steven, What about relying on the quit-application-requested notification (see https://developer.mozilla.org/En/Observer_Notifications) and on that notification, call savePrefFile() on the pref service we have nsTryToClose.js (see http://mxr.mozilla.org/mozilla-central/source/toolkit/components/startup/src/nsTryToClose.js#52) The (untested) pseudo patch would be something like: case "quit-application-requested": + Cc['@mozilla.org/preferences-service;1'].getService(Ci.nsIPrefService).savePrefFile(null); var windowMediator = Cc['@mozilla.org/appshell/window-mediator;1']. getService(Ci.nsIWindowMediator);
Thanks, Seth, for the suggestion. I'll get to it when I can ... which isn't likely to be soon.
Created attachment 405299 [details] [diff] [review] patch Postbox (which is based on Firefox 3.0.14) has a similar issue with quitting from the doc, and the following patch fixed our problem. from http://www.mozilla.org/projects/toolkit/review.html, it looks like bsmedberg is the right person to review changes to toolkit/components/startup Unfortunately, I don't have a unit test for this change.
Attachment #405299 - Flags: review?
Attachment #405299 - Flags: review? → review?(benjamin)
Comment on attachment 405299 [details] [diff] [review] patch The pref service saves the pref file on profile-before-change which should be fired at every shutdown. It's not clear to me what codepath the dock quit item is using where we shutdown without going through here: http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsAppRunner.cpp#968 which ends up firing the correct profile notifications.
Thanks for the review, Benjamin. I'll let Steven Michaud comment on the code path quit-from-dock-item is using. See also comment #8 in this bug.
Can't reproduce in FF58. Closing my old bug.
Status: NEW → RESOLVED
Last Resolved: 4 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.