Closed Bug 44590 Opened 24 years ago Closed 24 years ago

Browser won't start if ~/.mozilla not present

Categories

(Core Graveyard :: Profile: BackEnd, defect, P3)

Product:
Core Graveyard
Component:
Profile: BackEnd
Platform:
x86
Solaris
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 41057

People

(Reporter: ann.adamcik, Assigned: racham)

References

Details

If I do not have a ~/.mozilla directory, starting mozilla will create one, but it will not start up. There are no error messages and no core file - it just quietly exits. Subsequent attempts to start it will also quietly fail. Workaround: 1. Remove ~/.mozilla 2. Run Netscape6 to properly recreate ~/.mozilla 3. Exit 4. Run the nightly build - it will now start up. I'm guessing that the default profile isn't being created correctly?
reassiging to racham. Are we creating everything correctly when creating a new profile? If so, then we should reassign to a better owner.
Assignee: putterman → racham
I cannot reproduce this with build 2000070508- either mozilla build or Netscape 6 build using ./mozilla or ./netscape to run (ie creating a default profile) I did see strange bookmark file when I ran after creating a new profile- see bug 44339
I couldn't reproduce this either.....
same phenomena reported for linux: bug 44795
This appears to be fixed. I just tried last night's build (2000070704), with no ~/.mozilla directory. It now creates the directory and starts up properly.
*** Bug 44795 has been marked as a duplicate of this bug. ***
Setting "works for me" based on reporters last comments, and the fact that reporter of bug 44795 also says bug is now gone again.
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
.
Status: RESOLVED → VERIFIED
Although I can no longer reproduce this with SPARC, I am still seeing the problem with Solaris on intel (build 2000071005). Changing the platform to PC.
Status: VERIFIED → UNCONFIRMED
Hardware: Sun → PC
Resolution: WORKSFORME → ---
oh goody. I'll look into this tomorrow when I get solarix x86. Out of curiosity: Reporter are you still seeing this?
timeless - any luck here? Gerv
solaris8intel test runs ./run-mozilla ./mozilla-bin a portion of the output [retyped, i'm using an unfriendly x server]: ... WEBSHELL += 4 ... Enabling Quirk StyleSheet ... WARNING: chrome: failed to get base url for chrome://global/content/htmlBindings.xml -- using wacky default, file nsChromeReigstry.cpp line 507 last pid: 15114; load averages: 0.03, 0.02, 0.02 20:43:26 115 processes: 114 sleeping, 1 on cpu CPU states: 99.8% idle, 0.0% user, 0.2% kernel, 0.0% iowait, 0.0% swap Memory: 128M real, 40M free, 98M swap in use, 498M swap free PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND 15097 test 8 59 0 54M 32M sleep 0:06 0.00% mozilla-bin 15091 test 1 18 0 848K 624K sleep 0:00 0.00% run-mozilla.sh 15084 test 1 48 0 1992K 1364K sleep 0:00 0.00% bash 15074 test 1 48 0 844K 660K sleep 0:00 0.00% sh the behavior i get isn't identical but it's similar.
Status: UNCONFIRMED → NEW
Ever confirmed: true
You must have a .mozilla and contents to reach this far. Is this still happening ? Can anyone give stacktrace ?
Status: NEW → ASSIGNED
Target Milestone: --- → M18
I believe this problem is really being caused by bug 41057 - "Mozilla should not need write access to the binary directory". I found making the package directory recursively world writeable fixed this problem (but this is hardly an ideal solution)...
I find that hard to believe since i build as timeless and run as timeless. But who knows. yes I'm well aware of the correct procedure to run mozilla. I'll check again tonight.
I just encountered this problem (with a CVS trunk build from 2000-10-29). It definitely exists. It is definitely not a product of anyone's imagination. And it is related to (or duplicate of?) bug 41057. Specifically, I observed that if * .mozilla directory doesn't exist _AND_ * Mozilla binary directory is not writable by user THEN mozilla will not start. There also seem to be some strange problems when .mozilla doesn't exist but .netscape does - so here I assume that .netscape doesn't exist. I don't observe exactly the same as has been reported: I find that mozilla starts but just hangs there. strace shows that one of the threads just sits in poll(). I can give a stack trace if needed. IMHO, it is of the highest importance that this bug be fixed ASAP. At the very least, it would be very desirable to have a workaround stating which files must be made writable in the distribution directory, or which file should be copied from a legit .mozilla directory. Should I have attached that comment to bug 41057? Should I mark this bug as a duplicate of it (or vice versa)? I'll let someone else make the decision. Just my 0.02 EUR.
Sorry should have hunted about a bit more before posting bug numbers. This is a dup of bug 41057 - Mozilla should not need write access to the binary directory. Marking as such. *** This bug has been marked as a duplicate of 41057 ***
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → DUPLICATE
Urk too tired not, writing sane comments. I do think this is a dup of bug 41057 though (which is why I bit the bullet and marked it). Just out of interest, does anyone know of a quick fix to this? I don't want to ask on 41057 because it seems a highly strung bug at the moment...
I need to build again, but again I highly doubt this is the case. I build as timeless, and I run as timeless. There is now way the directories i'm creating would have some other owner.
vfy duplicate
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.