123633 - Prefs.js not written on reboot/shutdown

Status: VERIFIED FIXED

(Core Graveyard :: QuickLaunch (AKA turbo mode), defect)

Description

[Wayne Davison]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.8) Gecko/20020204
BuildID:    2002020406

On two separate Win98SE systems I run, I've noticed that Mozilla often keeps
asking me the same questions each time I restart my system.  I finally took the
time to track this down:

With Quick Launch enabled, it appears that a preference change that happens
outside of the preference dialog does not cause the prefs.js file to be written
out right away (unless I choose "Exit Mozilla" from the tray icon).  If I leave
Quick Launch running and then shut down the system or reboot (via the normal
shutdown dialog), I've verified that the update time on the prefs.js file does
not change -- any preference changes that were made via popups are lost.  I've
seen this happen with the form-submit-insecure warning as well as with changes
made in the download dialogs (that sets the download prefs for the current file
type).

Reproducible: Always
Steps to Reproduce:
1. Setup mozilla so that it prompts you when you submit insecure form data by
ensuring that the security.warn_submit_insecure user_pref is not set to false in
the prefs.js file (exit all Mozilla processes and remove the line from the file).

2. Start mozilla (with Quick Launch enabled) and visit www.google.com.  Search
for anything.

3. When the dialog pops up warning you about the form-data submission, uncheck
the checkbox and press OK.

4. Close the mozilla window, but leave Quick Launch running.

5. Note that the prefs.js file has not been updated.

6. Reboot using the normal Shutdown menu.

7. Note that the prefs.js file was still not updated.

As an alternative to steps 6 and 7: instead of rebooting, choose the "Exit
Mozilla" item from Mozilla's tray icon.  Note that the prefs.js file is updated
with the change in preferences.  Also, if the user manually edits any
preferences, the prefs.js file will be saved with the pending changes.

Actual Results:  Preference changes lost.

Expected Results:  Preference changes should be remembered.

Comment 1

[Bill Law]

Nominating.

Even if blocker bug 14807 doesn't get fixed, we could flush the prefs file when 
the last window closes.

Comment 2

[Peter Trudelle]

nsbeta1+ per ADT triage team

Comment 3

[Peter Trudelle]

re-assigning 'several bugs at once' to [e-mail].

Comment 4

[Jaime Rodriguez, Jr.]

ADT2 per ADT/Nav triage.

Comment 5

[Blake Ross]

Should(n't) this block bug 108795?

Comment 6

[Blake Ross]

morse, an implementation tip: this can be fixed by calling 
nsIPrefService::SavePrefFile(nsnull) from either OnLastWindowClosing or in an 
nsIObserver implementation that listens for "session-logout".  See the QL spec 
(http://www.mozilla.org/xpapps/QuickLaunch/) for more information (if it ever 
shows up!)

Comment 7

[Stephen P. Morse]

Attachment: save prefs when closing last window

Comment 8

[Samir Gehani]

I think we should restructure the conditions so that we call SavePrefFile() in
only one place (so that additions to be made for an exiting profile can be in
one place and more robust).

Comment 9

[Samir Gehani]

Comment on attachment 80445 [details] [diff] [review]
save prefs when closing last window

r=sgehani

Comment 10

[Stephen P. Morse]

Checked in on trunk.  Awaiting approval for branch checkin.

Comment 11

[jag (Peter Annema)]

Comment on attachment 80445 [details] [diff] [review]
save prefs when closing last window

sr=jag

Comment 12

[Stephen P. Morse]

gbush, please test so we can get approval for branch checkin

Comment 13

[Grace Bush]

this is working on trunk build 2002042303

Comment 14

[Randell Jesup [:jesup] (needinfo me)]

Comment on attachment 80445 [details] [diff] [review]
save prefs when closing last window

a=[e-mail]

Comment 15

[Jaime Rodriguez, Jr.]

Is this has been verified on the trunk, pls mark as Verified/Fixed.

Comment 16

[Stephen P. Morse]

Marking as verified fixed per Jaime's request, although it has not been fixed on 
the branch.

Comment 17

[Stephen P. Morse]

Verified by gbush in comment 13

Comment 18

[Jaime Rodriguez, Jr.]

adt1.0.0+ (on ADT's behalf) for checkin to 1.0. Pls check this in today, after
you recieve a=, then add the fixed1.0.0 keyword.

Comment 19

[Stephen P. Morse]

Checked in on branch.

Comment 20

[Grace Bush]

verified on branch 20020603