After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 524477 - stale lock file in mozilla profile directory prevents profile being loaded
stale lock file in mozilla profile directory prevents profile being loaded
Status: RESOLVED WONTFIX
Product: epiphany
Classification: Core
Component: [obsolete] Backend:Mozilla
2.22.x
Other All
: Normal major
: gnome-2-26
Assigned To: Epiphany Maintainers
Epiphany Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-03-26 13:40 UTC by Michael Gratton
Modified: 2009-03-11 10:54 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22



Description Michael Gratton 2008-03-26 13:40:40 UTC
Please describe the problem:
I've had a stale lock file hanging around in my profile for ever it seems:

> $ ls -l ~/.gnome2/epiphany/mozilla/epiphany | grep lock
> lrwxrwxrwx 1 mjg mjg    17 2005-07-26 19:38 lock -> 203.1.2.3:4742

After upgrading to Epy 2.22 and XULRunner 1.9 in Ubuntu Hoary, the mozilla profile stopping being loaded at startup, with this warning printed to the console:

> ** (epiphany-browser:26891): WARNING **: failed to read user preferences, error:
> 80004005

The result was that all saved passwords, cookies, history, certs, cache and everything else saved in the profile was ignored. Deleting the lock fixed the problem.

The problem is in embed/mozilla/mozilla-embed-single.cpp, line 178:

> rv = prefService->ReadUserPrefs (nsnull);

The next few lines check rv for an error and display the warning above, but maybe Epy should at least display an error dialog if an error is reported?

Steps to reproduce:
1. Quit Epy 
2. cd ~/.gnome2/epiphany/mozilla && ln -s 203.1.2.3:4742 lock
3. Start Epy


Actual results:
The warning above is printed and no passwords, cookies, etc are loaded.

Expected results:
An error dialog appearing informing the user of the problem.

Does this happen every time?
Yes, when a valid, stale lock file is present.

Other information:
Comment 1 Christian Persch 2008-03-26 13:45:56 UTC
The problem here is that gtk_moz_embed_push_startup has no return value that we could check. Should be filed upstream in bmo.
Comment 2 Michael Gratton 2008-03-26 14:42:27 UTC
Sounds like: https://bugzilla.mozilla.org/show_bug.cgi?id=319975

Given that the call to ReadUserPrefs is at least failing in Epy code, would it be possible to display a error from there for now? I'm not sure if that method returns an error under normal conditions, however - if prefs.js/user.js does not exist as the profile has just been created, for example.
Comment 3 Xan Lopez 2009-03-11 10:54:41 UTC
Gecko only, closing as WONTFIX since we are focusing on WebKit now.