393614 - SeaMonkey does not create prefs.js file if that is missing

Status: RESOLVED FIXED

(Core :: Preferences: Backend, defect, P4)

Description

[Peter Weilbacher]

Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.9a8pre) Gecko/2007081904 SeaMonkey/2.0a1pre (self compiled optimized build)
Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.9a8pre) Gecko/2007082401 SeaMonkey/2.0a1pre (self compiled debug build)

When removing the prefs.js file or when starting SeaMonkey without a profile (and without one to migrate), prefs.js does not get created. Changes in preferences are only remembered as long as the session lasts, as no prefs.js gets written they are reset to the defaults on application restart.

In the debug build I see the following output that might be related:
[...]
*** Registering components in: nsWidgetOS2Module
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed: file X:/trunk/mozilla/modules/libpref/src/nsPrefService.cpp, line 369
[...]
WARNING: Key 'key_preferences' of menu item 'Preferences...' could not be found: file X:/trunk/mozilla/layout/xul/base/src/nsMenuFrame.cpp, line 1025
[...]
JavaScript strict warning: chrome://communicator/content/pref/nsPrefWindow.js, line 101: reference to undefined property Components.interfaces.nsIChromeRegistrySea
*** Failed to create prefs object
[...]

After using "touch" to create an empty prefs.js file or after moving back the real prefs.js everything works are expected.

Comment 1

[Peter Weilbacher]

Dave noted in mozilla.dev.ports.os2 that prefs.js isn't migrated by the migration tool, either. I suspect that both problems are related.

Comment 2

[Peter Weilbacher]

OK, after quite a bit of debugging, I think I found where it goes wrong. The call to myDosOpenL() in _PR_MD_OPEN() in os2io.c

http://mxr.mozilla.org/seamonkey/source/nsprpub/pr/src/md/os2/os2io.c#249

fails with rc=110 which is the rather generic ERROR_OPEN_FAILED. Actually, I don't see anything wrong with the call, the parameters are
   myDosOpenL(<full path>\prefs.js,
              <valid pointer>,
              <valid pointer>,
              0,
              FILE_NORMAL,
              0x1 == OPEN_ACTION_CREATE_IF_NEW,
              0x40 == OPEN_SHARE_DENYNONE,
              0)
All variables are valid, including the full path specified, none of the parameters are in high memory when the call fails. Very confusing!

Comment 3

[Peter Weilbacher]

Attachment: call stack

Just for completeness, this is the call stack to the NSPR call where it goes wrong...

Comment 4

[Peter Weilbacher]

Args, the OS/2 Toolkit docs are faulty in one more place. 0x0001 is OPEN_ACTION_FAIL_IF_NEW (OPEN_ACTION_CREATE_IF_NEW would be 0x0010!). This OPEN_ACTION_FAIL_IF_NEW gets set in _PR_MD_OPEN() in os2io.c because the flags just contain the default (PR_RDONLY) as set in nsFileInputStream::Open(). This can be remedied by adding PR_CREATE_FILE | PR_RDONLY to the NS_NewLocalFileInputStream() call in openPrefFile().

In the end this regression occurred because of the checkin of bug 361102 (from end of November 2006!) because that really checked the return code of openPrefFile().

Comment 5

[Peter Weilbacher]

Attachment: fix

Benjamin, you were the last reviewer of changes in this file, so I hope you can review this, too. :-)

Comment 6

[Peter Weilbacher]

Actually a core bug, happens on Firefox trunk (OS/2), too.

Comment 7

[Benjamin Smedberg]

Comment on attachment 284875 [details] [diff] [review]
fix

I don't think this is correct. We don't want to create the file when we're *reading* it, only when we're *writing* it. Perhaps you just want to eat the error code in this case and return NS_OK?

Comment 8

[Peter Weilbacher]

Perhaps calling exists() before openPrefFile() as in bug 395618 could work. Have to test that.

Comment 9

[Peter Weilbacher]

Attachment: fix v2

OK, this works, too.

I guess the shared file is always there from the start, otherwise I would have to do the same change in ReadAndOwnSharedUserPrefFile().

Comment 10

[Peter Weilbacher]

Seems that I have to ask for blocking1.9 to get this on the map for the sr again. It's certainly critical for OS/2.

Comment 11

[Peter Weilbacher]

Reed, would you (or somebody else) be so kind to land this? I won't have time to actually watch tinderbox before the freeze.

Comment 12

[Reed Loden [:reed]]

Checking in modules/libpref/src/nsPrefService.cpp;
/cvsroot/mozilla/modules/libpref/src/nsPrefService.cpp,v  <--  nsPrefService.cpp
new revision: 1.98; previous revision: 1.97
done