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)

Product:
SeaMonkey
Component:
MailNews: Message Display
Platform:
Sun
Solaris
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
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...
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.
Also the Addressbook is missing.
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.
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
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
Any one know why? Anyone working on this? Why doesn't it affect other *nix builds?
*** Bug 137585 has been marked as a duplicate of this bug. ***
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.
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.
Look at bug 125489, it has a patch which might as well fix this bug. At least it did it for me.
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.
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
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.
Yup, verified working fine now that the fix for 125489 is in, thanks.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.