Closed
Bug 130558
Opened 23 years ago
Closed 22 years ago
mail & news missing from solaris sparc build of 0.9.9
Categories
(SeaMonkey :: MailNews: Message Display, defect)
Tracking
(Not tracked)
VERIFIED
DUPLICATE
of bug 125489
People
(Reporter: calum.mackay, Assigned: sspitzer)
References
Details
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.8) Gecko/20020205
BuildID: 2002031103
The Solaris SPARC build of 0.9.9 is missing the mail & news components. The
official 0.9.9 release downloaded from mozilla.org has this problem.
We also see this problem locally on a build from CVS source. We don't see the
problem on a Linux source build.
Reproducible: Always
Steps to Reproduce:
1.Try to start Mail/News from the Tasks menu.
2.
3.
Actual Results: No menu option.
Expected Results: There should be...
Reporter | ||
Comment 1•23 years ago
|
||
Starting mozilla with "-mail" causes the mail reader to come up, so this is a
good workaround. Lowering Severity to Critical.
It looks like we're just missing the option on the Tasks menu and Component bar.
Severity: blocker → critical
Confirmed that 0.9.9 build and a local CVS build seems to be missing
the mail component.
Comment 3•23 years ago
|
||
Also the Addressbook is missing.
Comment 4•23 years ago
|
||
first time I start 0.9.9, menue items show up.
After that several menue items under Tasks are missing.
If I delete chrome/chrome.rdf, then start mozilla,
all menue items show up again. So the problem is in the
process of building chrome.rdf.
Great! I simply removed chrome.rdf (and made sure that it never get's recreated)
and everything starts working. This also fixed a couple of other bugs which I
opened yesterday, #130790, #130794 and #130797. Now I wonder what that file is
good for. I have the impression that I pay a performance penalty on startup if
it's not there but other than that I don't see any negative impact. It's at
least a great workaround until somebody finds the real cause.
Reporter | ||
Comment 6•23 years ago
|
||
I don't think that will work for those of us using moz in a multi-user
environment. If the file is deleted the next person to run mozilla will get a
crash since they don't have write perms to the directory it's in.
Part of the multi-user install procedure is to create this file.
Works fine for us. The mozilla files and directories are owned by root and
there's no chrome.rdf and users can run mozilla fine. So far I couldn't find
anything which breaks if I remove that file.
The workaround of removing chrome/chrome.rdf doesn't appear to work
in our multi user environment here.
If i delete chrome.rdf or symlink it to /dev/null, then when i (or
any other user) tries to start mozilla it loops trying to recreate the
chrome.rdf file, getting EPERM's and never maps the main (or splash)
window thus hanging.
This is with todays CVS local build 2002031811
Reporter | ||
Comment 9•23 years ago
|
||
A w/a that does work for our multi-user install is to remove all write perms
from the chrome directory: "chmod a-w chome".
Severity: critical → major
Comment 10•23 years ago
|
||
Any one know why? Anyone working on this?
Why doesn't it affect other *nix builds?
Comment 11•23 years ago
|
||
*** Bug 137585 has been marked as a duplicate of this bug. ***
Comment 12•23 years ago
|
||
This affects all mail,addressbook, and security items in
the menus and preferences dialogs.
This is critical for use in Solaris.
The bug should be marked as such.
I would consider it a 1.0 blocker.
No access to the saved passwords or forms data
either.
Comment 13•23 years ago
|
||
We have been using the workaround succesfully for quite a while
on Solaris (i.e. the removal of write access to the chrome
directory and the removal of chrome.rdf therein). After implementing
that, all the security manager, mail, addressbook, etc all work
perfectly, so i don't think we can consider this a beta blocker
since there is a known workaround.
Comment 14•23 years ago
|
||
Look at bug 125489, it has a patch which might as well fix this bug. At least it did it for me.
Comment 15•23 years ago
|
||
I tried the work around from #23
in bug#125489.
That seams to work better than removing a file
or preventing it's creation.
So I guess this is really a duplicate of the bug.
Comment 16•22 years ago
|
||
This bug is a duplicate of bug 125489, which will be fixed before 1.0.
*** This bug has been marked as a duplicate of 125489 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
verified dup
Status: RESOLVED → VERIFIED
Comment 18•22 years ago
|
||
Friendly note: you need to verify the fix in the original bug for the problem
reported here. That bug is Networking:file, so I will not verifying anything
being fixed here.
Reporter | ||
Comment 19•22 years ago
|
||
Yup, verified working fine now that the fix for 125489 is in, thanks.
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•