Closed Bug 126113 Opened 23 years ago Closed 23 years ago

No mail, chat features after "complete" install

Categories

(SeaMonkey :: UI Design, defect, P1)

Product:
SeaMonkey
Component:
UI Design
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 125489

People

(Reporter: sharding, Assigned: bryner)

References

Details

Attachments

(1 file)

Screenshot 2002-02-23-08-trunk GTK+ build on Solaris/SPARC, no mailnews, no chatzilla, addressbook etc.
228.00 KB, image/jpeg
Details
This seems kind of strange. I just downloaded the latest mozilla-i686-pc-linux-gnu-sea.tar.gz (2002021706) from ftp.mozilla.org and installed it using the option "complete." As usual, after it finished installing, it launched Mozilla. This Mozilla had all of the features -- browser, mail, composer, chatzilla, etc. They worked; at least I successfully used the browser and the mail client. I quit that instance of Mozilla and then relaunched it by running /path/to/installdir/mozilla. That mozilla doesn't seem to have mail or chat (there are no icons for it at the bottom left of the window, and no menu items for them). There's a composer icon and composer menu items (e.g. "new blank page to edit"), but they don't actually do anything -- choosing File->New->Blank Page To Edit results in nothing. No windows, no error messages (including on the console), etc. I nuked the install dir and redid the install to make sure I hadn't screwed something up, and it's still broken...
QA Contact: bugzilla → ktrina
Confirming bug, I have the same issue...
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 126805 has been marked as a duplicate of this bug. ***
I don't think this is an installer issue. Sounds like parts of Mozilla (possibly the chrome overlays) are sensitive to what the current directory is.
Assignee: dveditz → trudelle
Component: Installer → XP Apps
Fresh, new 2002-02-23-08-trunk build on Linux/gcc2.95, GTK+ toolkit. No mailnews, no chatzilla in menus. I think this is a _SMOKETEST_BLOCKER_ !
Marking this as "smoketest" blocker.
Severity: normal → blocker
Keywords: smoketest
Priority: -- → P1
Target Milestone: --- → mozilla0.9.9
->bryner
Assignee: trudelle → bryner
works for me, with build 2002022508.
Well, still doesn't work for me in 2002022508. And this is happening on multiple machines. I originally saw the problem on a machine at home, and I just installed 2002022508 on a machine at work and am having the same problem.
I'm unable to reproduce this on 2002022508.
I'm not sure what to say, but the fact that some people can't reproduce this doesn't mean it doesn't exist. I've seen it on three seperate machines with every single build I've tried since 2002021706. 100% reproducable for me. Let me again outline my steps. rm -rf ~/mozilla ~/mozilla-installer ~/mozilla-i686-pc-linux-gnu-sea.tar.gz ftp ftp.mozilla.org (get /pub/mozilla/nightly/latest/mozilla-i686-pc-linux-gnu-sea.tar.gz) tar zxf mozilla-i686-pc-linux-gnu-sea.tar.gz mozilla-installer/mozilla-installer (run the installer, choosing "complete" and "/home/sharding/mozilla" as the install dir) (Installer finishes and launches a copy of Mozilla. This instance of the application does have mailnews and chat buttons and menu items) (Quit that instance via file->quit) mozilla/mozilla & (New instance of Mozilla launches. This instance does not have any buttons or menu items for mailnews or chat. Further, the composer button and menu items don't do anything. All subsequently launched instances of Mozilla are like thism regardless of my cwd) Again, 100% reproducable on three of my machines.
I believe there is a bug, but it's probably not a blocker if it's not replicable by everyone...
I can reproduce it 100% on Solaris and Linux since a couple of days (first I ignored it because I thought my build is busted, but now... ;-( ) ...
have you tried changing profiles? (move your ~/.mozilla elsewhere then run) since it seems like you two are getting this, and perhaps set certain settings that are triggering this behavior.
Making a new profile (or completely nuking ~/.mozilla and starting over) has no effect for me. The problem persists.
Did everyone claiming they *don't* see this use an explicit path rather than being in the mozilla directory? For everyone who *does* see this, does the problem go away when you launch from the install directory?
Sean Harding wrote: > Making a new profile (or completely nuking ~/.mozilla and starting over) has > no effect for me. The problem persists. Same for me - |rm -R ~/.mozilla| before each start (GTK+, Xlib) does not fix this issue... ;-(
I am starting the Zilla in dist/bin, e.g. % cd dist % cd bin % ./mozilla starting the Zilla from the homedir does not fix it. Removing ~/.mozilla before doing that does not fix it either.
As I said in comment #11, my cwd does not have any effect. I went so far as to do: for dir in `find mozilla -type d` do ~/mozilla/mozilla done And for dir in `find mozilla-installer -type d` do ~/mozilla/mozilla done (As well as manually 'cd ~/mozilla ; ./mozilla' and 'cd ~/mozilla; setenv PATH ${PATH}:. ; mozilla'). Same problem from all directories.
Does running as root make the problem go away? If so, this might be a manifestation of bug 101271 If that doesn't help I'm left with silly questions, like, have you checked to verify that the mail and chatzilla chrome jars are actually present? If so are they referenced in chrome.rdf? How about chrome/overlayinfo/navigator/content/overlays.rdf? At a loss if it's not the permissions thing.
Running as root does not make the problem go away. ~/mozilla/chrome/chatzilla.jar and ~/mozilla/chrome/messenger.jar do exist. They are mentioned in chrome.rdf like this: <RDF:li resource="urn:mozilla:locale:en-US:chatzilla"/> .... <RDF:Description about="urn:mozilla:locale:en-US:chatzilla" c:baseURL="jar:resource:/chrome/chatzilla.jar!/locale/en-US/c hatzilla/"> <c:package resource="urn:mozilla:package:chatzilla"/> </RDF:Description> .... <RDF:Description about="urn:mozilla:skin:modern/1.0:chatzilla" c:baseURL="jar:resource:/chrome/chatzilla.jar!/skin/modern/ch atzilla/" c:allowScripts="false"> <c:package resource="urn:mozilla:package:chatzilla"/> </RDF:Description> .... <RDF:li resource="urn:mozilla:package:chatzilla"/> .... <RDF:Description about="urn:mozilla:package:chatzilla" c:baseURL="jar:resource:/chrome/chatzilla.jar!/content/chatzi lla/" c:locType="install" c:displayName="Chatzilla" c:author="mozilla.org" c:name="chatzilla" /> .... <RDF:li resource="urn:mozilla:skin:modern/1.0:chatzilla"/> And so on. There is no ~/mozilla/chrome/overlayinfo directory nor is there a file called "overlays.rdf" anywhere under ~/mozilla. Is that the problem?
The lack of overlayinfo is indeed the problem. I have absolutely no idea why that wouldn't have gotten written out, especially as it appears to have built the information in memory the first time since you saw the overlayed buttons. Assuming you still have your original mozilla/chrome/installed-chrome.txt file you could try deleting chrome.rdf and see if it rebuilds correctly.
Deleting chrome.rdf and then launching Mozilla does result in a Mozilla instance with the chat and news features. However, subsequent launches are back to not having those buttons...
I get exactly the same behaviour...
What filesystem are you guys using?
Solaris: Plain UFS with logging enabled Linux: NFSv2 to the Solaris machine
ufs
bug 127322 (smoketest blocker, too) seems be a chome.rdf-related issue - is it somehow related to this bug ?
Can this behaviour be reproduced with builds before 2002021706 ? Maybe we could find the commit that caused the regression...
fyi: this is a smoketest blocker and needs attention asap. Thanks!!
I can't reproduce this with the steps noted in comment #11.
Still 100% reproducable for me in 2002022808. There's no overlayinfo directory anywhere under my mozilla install directory.
I think i saw this on w98 or w2k :-(
not reproducible, not a smoketest blocker, removing smoketest keyword.
Keywords: smoketest
jrgm, what is the configuration (OS and build) you tried to reproduce it on? I'm a broken record, but this is getting really frustrating. I can reproduce this on three completely independent machines every time with every recent build. No exceptions. Since others have had similar experiences, and those of us who have had such experiences have gone to pains to outline the exact steps and configurations, I think it's fair to ask the same from those who can't reproduce it. Clearly something is different if I'm seeing the problem 100% of the time and you're not.
100% reproduceable on Linux and Solaris build from 2002-02-27-08-trunk.
> I can't reproduce this with the steps noted in comment #11 ... and the build was 2002-02-28-08 and OS was Linux Redhat 6.1
This is very similar to bug 109044 and bug 106701. We're not seeing the -239 errors because the Mozilla installs use the DELAYED_CHROME style (the workaround in bug 106701), but like those it seems to happen on newer kernels and not on older machines.
Hmm. Yes, similar. However, this bug is not Linux-specific. I'm seeing it on FreeBSD, and Mr. Mainz is seeing it on Solaris.
From my test maschine: uname -a == "SunOS mercator 5.7 Generic_106541-19 sun4u sparc SUNW,Ultra-5_10" - this is the kernel patch 106541 rev 19 for Solaris 2.7 - the latest kernel patch available for this OS. I doubt this is a kernel bug (and rev 16 has the same issue) ...
Also, what locale settings are you guys using?
I'm using whatever the defaults are in FreeBSD. No locale environment variables set or anything.
LC_TIME=en_US USER=mozilla LANG=en_US LC_NUMERIC=en_US LC_CTYPE=en_US LC_MONETARY=en_US LC_COLLATE=en_US but happens with en_US.UTF-8 and ja_JP.UTF-8, too ...
A failure to create the overlayinfo files is not likely to be the result of a locale settting. What are the permissions and ownership of your mozilla chrome directory and the chrome.rdf file?
drwx------ 2 sharding wheel 512 Feb 28 11:23 mozilla/chrome/ -rw------- 1 sharding wheel 28779 Feb 28 11:23 mozilla/chrome/chrome.rdf (Installed by my in my home directory, and it's only run by me)
Please humor me and try changin both to 777 to see if that makes a difference. This is tickling something similar in the back of my brain.
Just tried it. Chmodding ~/mozilla/chrome and ~/mozilla/chrome/chrome.rdf to mode 777 in my current install has no effect on Mozilla's behavior.
You'd also have to touch installed-chrome.txt to trigger a re-registration attempt.
touching installed-chrome.txt fixes it for the next launch, but subsequent launches are broken again. (I could, of course make an alias or change the wrapper to touch installed-chrome.txt every time, but that's kind of lame).
Also, the permissions on mozilla/chrome and mozilla/chrome/chrome.rdf don't seem to matter. I changed them back to 700/600 and touched installed-chrome.txt and it still worked (for that one launch only).
Touching installed-chrome.txt works because it forces a re-registration. For that one run the chrome registry knows about the overlays, but then it's not able to save that fact for the next run (we don't want to re-register every run because it is a huge drag on startup). I was hoping that changing the permissions would allow it to write out the overlayinfo files. I am stumped for what else might be keeping it from writing out, only on some systems.
Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+, topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword. Please send any questions or feedback about this to adt@netscape.com. You can search for "Moving bugs not scheduled for a project" to quickly delete this bugmail.
Target Milestone: mozilla0.9.9 → mozilla1.2
adding nsbeta1. I think this needs some investigation to determine where the failure is occuring. See comments in bug 125489 (which may be a dup of this bug [or vice versa]). If someone could step through this code on a system that is failing, that would help very much.
Target Milestone: mozilla1.2 → ---
Ahh, yes. Interesting. I've been seeing the behavior in Bug 125489 on the same systems I'm seeing this problem on...
nsbeta1, really this time.
Keywords: nsbeta1
This is hitting too many people, we have to find out what's going on.
Keywords: mozilla1.0
Argh! I just built from source to try to debug this a little better, and the version I built works fine...
Roland, can you look at comment 30 in bug 125489, and try to get some output for the nsIFile routines where it should be trying to create chrome.rdf and overlayinfo/*. Thanks.
*** Bug 129138 has been marked as a duplicate of this bug. ***
duping against bug 125489. The problem is the same, and it is that we are not creating the chrome.rdf and overlayinfo/*, I believe due to a failure of nsIFile::Create. Debugging help from those affected would be very helpful in getting this resolved. See bug 125489 for details. *** This bug has been marked as a duplicate of 125489 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Verified as a dupe of bug 125489
Status: RESOLVED → VERIFIED
Please look at the fix in bug 125489, and verify that is solves the problem here.
Yes, this is fixed for me in 2002050607.
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: