Closed
Bug 126113
Opened 23 years ago
Closed 23 years ago
No mail, chat features after "complete" install
Categories
(SeaMonkey :: UI Design, defect, P1)
Tracking
(Not tracked)
VERIFIED
DUPLICATE
of bug 125489
People
(Reporter: sharding, Assigned: bryner)
References
Details
Attachments
(1 file)
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...
Updated•23 years ago
|
QA Contact: bugzilla → ktrina
Comment 1•23 years ago
|
||
Confirming bug, I have the same issue...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 2•23 years ago
|
||
*** Bug 126805 has been marked as a duplicate of this bug. ***
Comment 3•23 years ago
|
||
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
Comment 4•23 years ago
|
||
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_ !
Comment 5•23 years ago
|
||
Marking this as "smoketest" blocker.
Comment 7•23 years ago
|
||
works for me, with build 2002022508.
Reporter | ||
Comment 8•23 years ago
|
||
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.
Assignee | ||
Comment 9•23 years ago
|
||
I'm unable to reproduce this on 2002022508.
Comment 10•23 years ago
|
||
Same happens for Linux... ;-(
Reporter | ||
Comment 11•23 years ago
|
||
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.
Comment 12•23 years ago
|
||
I believe there is a bug, but it's probably not a blocker if it's not replicable
by everyone...
Comment 13•23 years ago
|
||
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... ;-( ) ...
Comment 14•23 years ago
|
||
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.
Reporter | ||
Comment 15•23 years ago
|
||
Making a new profile (or completely nuking ~/.mozilla and starting over) has no
effect for me. The problem persists.
Comment 16•23 years ago
|
||
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?
Comment 17•23 years ago
|
||
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... ;-(
Comment 18•23 years ago
|
||
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.
Reporter | ||
Comment 19•23 years ago
|
||
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.
Comment 20•23 years ago
|
||
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.
Reporter | ||
Comment 21•23 years ago
|
||
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?
Comment 22•23 years ago
|
||
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.
Reporter | ||
Comment 23•23 years ago
|
||
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...
Comment 24•23 years ago
|
||
I get exactly the same behaviour...
Assignee | ||
Comment 25•23 years ago
|
||
What filesystem are you guys using?
Comment 26•23 years ago
|
||
Solaris: Plain UFS with logging enabled
Linux: NFSv2 to the Solaris machine
Reporter | ||
Comment 27•23 years ago
|
||
ufs
Comment 28•23 years ago
|
||
bug 127322 (smoketest blocker, too) seems be a chome.rdf-related issue - is it
somehow related to this bug ?
Comment 29•23 years ago
|
||
Can this behaviour be reproduced with builds before 2002021706 ? Maybe we could
find the commit that caused the regression...
Comment 30•23 years ago
|
||
fyi: this is a smoketest blocker and needs attention asap. Thanks!!
Comment 31•23 years ago
|
||
I can't reproduce this with the steps noted in comment #11.
Reporter | ||
Comment 32•23 years ago
|
||
Still 100% reproducable for me in 2002022808. There's no overlayinfo directory
anywhere under my mozilla install directory.
Comment 33•23 years ago
|
||
I think i saw this on w98 or w2k :-(
Comment 34•23 years ago
|
||
not reproducible, not a smoketest blocker, removing smoketest keyword.
Keywords: smoketest
Reporter | ||
Comment 35•23 years ago
|
||
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.
Comment 36•23 years ago
|
||
100% reproduceable on Linux and Solaris build from 2002-02-27-08-trunk.
Comment 37•23 years ago
|
||
> 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
Comment 38•23 years ago
|
||
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.
Reporter | ||
Comment 39•23 years ago
|
||
Hmm. Yes, similar. However, this bug is not Linux-specific. I'm seeing it on
FreeBSD, and Mr. Mainz is seeing it on Solaris.
Comment 40•23 years ago
|
||
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) ...
Assignee | ||
Comment 41•23 years ago
|
||
Also, what locale settings are you guys using?
Reporter | ||
Comment 42•23 years ago
|
||
I'm using whatever the defaults are in FreeBSD. No locale environment variables
set or anything.
Comment 43•23 years ago
|
||
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 ...
Comment 44•23 years ago
|
||
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?
Reporter | ||
Comment 45•23 years ago
|
||
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)
Comment 46•23 years ago
|
||
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.
Reporter | ||
Comment 47•23 years ago
|
||
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.
Comment 48•23 years ago
|
||
You'd also have to touch installed-chrome.txt to trigger a re-registration attempt.
Reporter | ||
Comment 49•23 years ago
|
||
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).
Reporter | ||
Comment 50•23 years ago
|
||
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).
Comment 51•23 years ago
|
||
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.
Comment 52•23 years ago
|
||
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
Comment 53•23 years ago
|
||
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 → ---
Reporter | ||
Comment 54•23 years ago
|
||
Ahh, yes. Interesting. I've been seeing the behavior in Bug 125489 on the same
systems I'm seeing this problem on...
Comment 56•23 years ago
|
||
This is hitting too many people, we have to find out what's going on.
Keywords: mozilla1.0
Reporter | ||
Comment 57•23 years ago
|
||
Argh! I just built from source to try to debug this a little better, and the
version I built works fine...
Comment 58•23 years ago
|
||
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.
Comment 59•23 years ago
|
||
*** Bug 129138 has been marked as a duplicate of this bug. ***
Comment 60•23 years ago
|
||
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
Comment 62•22 years ago
|
||
Please look at the fix in bug 125489, and verify that is solves the problem here.
Reporter | ||
Comment 63•22 years ago
|
||
Yes, this is fixed for me in 2002050607.
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
You need to log in
before you can comment on or make changes to this bug.
Description
•