Open Bug 313273 Opened 19 years ago Updated 3 years ago

'Roaming' preferences not sticking

Categories

(SeaMonkey :: Preferences, defect)

Product:
SeaMonkey
Component:
Preferences
Version:
SeaMonkey 1.1 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

People

(Reporter: robbage, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Win 9x 4.90; en-GB; rv:1.9a1) Gecko/20051020 SeaMonkey/1.1a
Build Identifier: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-GB; rv:1.9a1) Gecko/20051020 SeaMonkey/1.1a

Roaming user preferences don't stay to what I set them. even without shutting
down and restarting Seamonkey.


Reproducible: Always

Steps to Reproduce:
1.Open Preferences:Roaming user
2.check 'Enable remote profile storage'
3.set server information to "File Copy"
4.select a directory
5.close preferences
6.Open Preferences:Roaming user
7.Nothing stuck

Actual Results:  
Settings reverted to defaults


Expected Results:  
Remembered my settings, and possibly allowed me to use roaming.
Assignee: prefs → nobody
Component: Preferences → Profile: Roaming
Product: Mozilla Application Suite → Core
QA Contact: profile-roaming
Version: unspecified → Trunk
WFM on win2k with SeaMonkey trunk
Reporter: Changing other settings in the preferences dialog works fine (like
homepag, etc.)? 
Other settings work fine. I also have the same issue on an XP machine. Am I using it incorrectly?
Reporter, is your mozreg.dat readonly or something like that?
The roaming prefs are stored in mozreg.dat, not prefs.js like the rest.
mozreg.dat does not appear anywhere on my system (especially in the install directory or win\application data\Mozilla\ directories)
Is the file installed with the installer or created by the app? 
I just installed on my FC4 machine: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051029 SeaMonkey/1.1a

Same thing happens here too... 
registry.dat is not readonly
it works for me at last, but I must set it 5 times and quit mozilla, before it really start uploading and downloading profile.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060130 SeaMonkey/1.0 on XP sp2 is the first version I have got to work, but I had to set it several times before it finally stuck.

The settings for roaming reverted back to defaults again some time in the follwing 3 days.
Confirming. I have observed the smae behavior, both Seamonkey 1.0 and 1.0.1.
Once you allow roaming, there is no way to change it or to apply preferences. No way top de-activate roaming. Looks like locked pref file but the other prefs were not having the problem.
Same behavior on two different machines (win XP).

To deactivate roaming workaround:
Reinstall Seamonkey and do not install the roaming feature.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060809 SeaMonkey/1.5a
it seems to be working now. But selecting items in preferences/roaming user/item selection is still not working.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061101 SeaMonkey/1.1b
Could reproduce bug with steps from comment 0. No info was written to registry.dat.

On another WinXP PC with SM 1.0.5, remote profile storage ("File Copy") worked. But it could not set to disabled later. Workaround: restore old registry.dat
Flags: blocking1.8.1.1?
Results of further testing with SM 1.1b on XP:

Reproducible: Always

Steps to Reproduce:
1. Open Preferences:Roaming user
2. Change setting
3a. Do NOT open Preferences:Roaming user:Items selected
3b. Open Preferences:Roaming user:Items selected
4. Click "OK"
5. Reopen Preferences:Roaming user

Actual Results:
Case 3a: OK, settings stored
Case 3b: Error, settings not stored

Examining chrome://sroaming/content/prefs/all.js in JS Debugger on "OK":

Case 3a: okClicked() finishes sucessfully
Case 3b: okClicked() throws "UIToData not defined", dataToRegistry() not called.

Possibly this condition in okClicked() does not work as expected:

  if ("UIToData" in window) // unless a different pane is selected
    {
      UIToData();
    }

Hope this helps.

Changing product to suite. If you're really trying to get this noticed then using the correct blocking flag is more important than the right component.

(I'll assume comment 14 is a confirmation of this bug)
Status: UNCONFIRMED → NEW
Component: Profile: Roaming → Preferences
Ever confirmed: true
Flags: blocking1.8.1.1?
Product: Core → Mozilla Application Suite
Version: Trunk → 1.8 Branch
SeaMonkey 1.1 is the one built off 1.8.1.x, right? That's what Franke wanted this bug to block.
Flags: blocking-seamonkey1.1?
Re comment 14:
Yes, thanks, this does help. I don't know why this appears, though.

It might be a good idea to rework this dialog structure, which is the reason for the complication and the bug. I wanted to make 2 panels, avoiding a dialog opening from a dialog, but Firefox does that with almost everything. Also, I tried to make it work with both Mozilla and Firebird, whose prefs panels work subtly differently.

I'd suggest to just turn the "Item Selection" panel into a dialog opening from the roaming pref panel. Then you avoid the whole issue (and using the same code for Firefox will be easier, too).
Not blocking.  We've apparently shipped multiple releases with this bug without too much noise... a patch would probably get approval for both 1.0.x and 1.1.x though.
Flags: blocking-seamonkey1.1? → blocking-seamonkey1.1-
Ben:
We're working on making our next major release (based on Gecko 1.9) use the same bakend as Firefox and Thunderbird, so it might be easier to get something that works with all those products then.

Are you still working on that feature? Would be cool to still have it working in this currently code-named "suiterunner" version, and this might be the chance to fix this bug as well.
> same bakend as Firefox and Thunderbird, so it might be easier

The problem was how the prefs dialog is implemented: (a) panels vs. tabs and subdialogs, and (b) how onload acts (panels unload on switch or not). Unless you use the same prefs dialog code as Firefox, the problem remains.

> Are you still working on that feature?

No.

Note that roaming is broken on toolkit for other reasons as well, see bug 249343.
On Linux Seamonkey 1.1.3, the preferences are sticky.
Confirming bug report on Seamonkey 1.1.7 Windows.
Preferences stick the first time, then you can never edit them again.

about:config shows
roaming.default.files bookmarks.html,abook.nab,cookies.txt
roaming.showInitialWarning false

But editing "roaming.default.files" has no effect on the checkboxes back in preferences.  Roaming feature would be better if it had an explicit "sync now" button or "sync up" "sync down".
See also this blog: http://thomas.tanreisoftware.com/?p=39July 7th, 2006
Amazingly, roaming profiles work in Seamonkey; you just have to be very careful when setting them up. [Update: they are way too flaky to use at the moment].
Blocks: 427936
No longer blocks: 427936
Can you reproduce with SeaMonkey v1.1.9 ?
OS: Windows ME → Windows XP
Version: 1.8 Branch → SeaMonkey 1.1 Branch
No way I'm gonna try.  Last time I tried this it took hours to restore my system.  You try it first :-).
Well, for the reason mentioned in comment #23 I do not install the roaming at all any more. Sorry.
You need to log in before you can comment on or make changes to this bug.