User interface widgets that are part of a web browser's content (such as web forms) are actually handled by a separate toolbox --- rather than XP Toolkit --- and should be assigned to Layout: Form Controls.

I've talked to two other people who verified that this item is, in fact, on the
tasks menu. Please ensure that if you're running installer, you're actually
installing the mail component. verifying wfm for now...

Will give it a try with next nightly, though don't think there's anything to
change. Iremove everything from /opt/mozilla where i install mozilla and my
personal .mozilla directory. If that's not enough, nothing will do it!

Bottom task bar, I assume, are the three icons on the left side, below the
status bar. First one starts navigator, second starts composer, third produces a
Javascript error, from the icon it seems it is Mail. JS error says line 0:
toAddressBook is not defined

I had someone checking this out on Linux, latest CVS. Marking WfM.
Go ahead if you wanna sort this out, Christos.
Reopen if someone can confirm this happening on Linux again or if its not gonna
work for you at all, Christos.

reopening.
waterson may have some steps:
Just installed the commercial build on Linux. I installed it as root,
ran it once so that component.reg would get built. Now I try to run as
user. No mail overlays loaded! (No little mail folder at the bottom, no
mail in task menu.)
Run as root. Mail is there.
Run debug mozilla build, mail is there.
Change all file permissions to ugo+w in /usr/local/netscape6. Still no
mail running as user.
Recreate profile. Still no mail.
Also, I got email from someone else jsabatke@execpc.com who ran into this. I'll
add him to the cc: list.

From alecf:
"I have had a few random occurances of this bug on my machine today - in once
instance I opened a mail search window, and mailWindowOverlay.xul wouldn't
load.. in the other instances, mozilla -mail wouldn't bring up any content..
but it almost always worked the second time.
This is on linux, never as root"

problem is this:
if you start as user a, overlayinfo directories containing overlays.rdf file are
created underneath chrome with permissions drwx------. If you run as user b,
then you can't read or traverse these directories because of the permissions. I
think they should be created drwxr-xr-w.

Flush() is always creating files with permissions 0700. This is wrong for the
case of stuff created below chrome, in which case 0755 is more appropriate. A
solution that seems to have some agreement would be to add an argument to
Flush() that tells Flush() what sort of permissions flags to use. We could make
the argument be the Unix permissions flags (which will map to DOS/Windoze bits)
or we can pass in some enumeration value(s) OR'd together. If you want, hand me
this bug and I will be glad to come up with a workable solution.

SOLUTION: I did an strace on this and found that it is opening
chrome/installed-chrome.txt for write. When I chmodded it o+w it started to
work again. I don't see why it should be writing this file in
particular and I don't want any user process writing in my install
tree at all, thankyou.

Doug: see earlier comments. We are a component based piece of software. During
component registry, we have to write certain things into chrome. It is normal.
The solution is to get the permissions correct.

During the strace I saw that it tried to write on the component registry,
got denied permission, and then opened another copy in the user's file
space. Why doesn't it do the same thing with chrome? That seems like
the proper approach to me. By the way, I love Mozilla mail - it's the
best client going for me, and I use it all the time despite the
various problems and crashes. Thanks!

This bug, I think, is miscategorized/mis-summarized. The fact that mail
is missing from the Tasks menu is only a symptom of the fact that mail is just
plain missing altogether when logging in as anything other than root! Mail is
nowhere to be found in Preferences, the Tasks Menu, or the Component Bar. Is
this a XUL problem, or something else entirely?

I think that the real problem is that nsIFile (or some such) is creating files
using the wrong permission bits, and not letting umask filter them. This causes
the installation (when run as root) to create a directory with 0600 permissions
(or some such). I'm pretty sure this is a dup of another bug -- or vice versa.
dougt, sound familiar?

This still happens on build 2000.07.30.05, after a virgin install using the
installer, all distribution and user directories deleted. The problem went away
after I did a chmod a+rx on /usr/local/mozilla/chrome/overlayinfo and all its
subdirectories and files.

On linux build 2000073009 M18 nightly, the overlayinfo directory is still being
created mode 700. It should probably be mode 755 so that other users can enter
the directory.
drwx------ 6 root root 1024 Jul 30 15:28 overlayinfo
Clearing nsbeta2- status for reevaluation by PDT. This is a simple fix and
should probably be done before m17 is released.

Ben, but it does. So, are you going to change that? In the meantime, a quick fix
will avoid users in the scenario from talking about from losing access to mail
news until some other architecture is devised.
So, let's make the current design work, and stop fussing about how it might be
better, ok?

Bug 44338 is about the classic theme not appearing in prefs, but the cause was
determined to be the same as this bug, that overlayinfo is not readable by other
users. So, not only does this bug break mail/news but also themes. :(

Summary: Some directories not read or executable, makes Mailnews disappear. → Some directories not read or executable, makes Mailnews disappear, and themes break.

I did, a while back. Read earlier. It is the component registry, and the flush
call in rdf needs a perms flag (in this case) to cause the underlying fs code to
use 766 (the rest of the flush calls can just pass some predefined value so they
use the value they always used before so we don't break anything). I've
discussed with rjc and hyatt, both like it, let's do it.

okay. found the problem. all nsFileStreams (nsFileSpec io) use 0666 as the
permission. It was once 0700 but I change it to 0600 based on man 2 umask. I
guess we need to do something else, like 0755 as I initally though that we
should do.

This is *not* fixed in Linux build 2000080505.
Starting Mozilla as root, I can see mailnews, and I can download themes from
x.themes.org.
Starting as a normal user I do not see mailnews, nor do downloaded themes appear
in prefs.

When you say you can't see mailnews, does that mean there is a tasks menu item
but that it doesn't work? Or there is no tasks menu item? Can you recursively ls
-l dist/bin/chrome/overlayinfo and attach to this bug report? Also, what is your
umask set to when you installed, or when you first ran?

Doug, am I reading the patch right? You made the default permissions be 0755
for all files, including directories? That's not right, if so: calling context
is required to know whether to use 0666 (modified by umask, as usual) for a
regular file, or 0777 (modified by umask again) for a directory. Some Unix
utilities use 0755 for the default mode when creating necessary directories
along the path to a new file, btw, but I think umask should govern which bits
are turned off, so 0777 seems best in general.
Is the problemt that the "accessMode" is used both for creating the ultimate
(leaf) file, and for creating any necessary directories along the path? Or are
we really creating leaf directories as well as files using the same method(s),
in which case we've overloaded badly?
/be

no. we did not use that patch.
the final fix was in RDF (like other places in the code) to create files with
755 permission.
The problem is that nsFileSpec creates directories with 0700:
const mode_t mode = 0700;
nsFileSpecHelpers::MakeAllDirectories((const char*)ioPath, mode);
nsLocalFile (nsIFile) fixes this problem. From the comment:
Ancestor directories get the same permissions as the file we're creating, with
the X bit set for each of (user,group,other) with an R bit in the original
permissions. If you want to do anything fancy like setgid or sticky bits, do it
by hand.

Dougt: setting to 755 is not going to cause the failure, that is silly :-) --
just means the file is incorrectly marked as executable, not that it can't be
read (if you try to execute the file the shell will try to interpret it and
fail). The bug that some people still have for whatever reason is that a user
that was not the creator of the overlayinfo dir is unable to read files because
the directories about are not readable.
Brendan is prolly right, the 755 on files is unnecessary and perhaps a tad evil,
the rdf-created stuff can be 644, and we should change it. My bad. The
directories in the path should be 755 so they can be accessed by a different
user than the
creator, that is what the change in nsFileSpecUnix did, as dougt described
earlier (700 was too restrictive), and what this bug is all about. Regardless of
the issue with the "file" perms, my checkins fixed the bug as it was originally
described. I verified it with the default umask and with a umask of 002.
As you can see in the last attachment (by zach), the overlayinfo dir has been
created with permissions inconsistent with the checked in fix. Setting umask to
002, I did not get the same result as Richard Zach -- my permissions on
overlayinfo are what I would have expected, drwxr-xr-x (his are drwx------ which
will cause the failure case).
I am *not* using the installer, but debug builds from m18 tip. The installer
does not create chrome/overlayinfo so I can't see it as being relevant.

Syd: just to be sure we agree, the octal literal passed for regular file mode
should be 0666, and let umask turn it into 0644 or 0664 as the user desires.
For directories created implicitly along the path to a new file, we should do
what shaver et al. did in nsLocalFileUnix: use the file's mode with an 'x' bit
for every 'r' bit added.
IOW, please to be respecting my umask setting, dammit!
/be

syd: if you know for sure that 0644 is right (no group member should be able to
write, or to unlink the file from a sticky dir), go for it. In a general
purpose API, you can't know that. Umask can only clear bits, never set them.
Some people run in group-write-access mode, with umask of 002. Others use 022.
Different strokes, but don't preempt the choice.
/be

Doug Collins, did you run mozilla once first as root to register the necessary
files? You may be experiencing bug 42184. If so then this bug is fixed or a
dup of bug 42184. I don't have easy access to a linux box right now, can anyone
else on linux confirm this?

Doug, didn't get all of your last comment. Please update.
At any rate, if I either run the mozilla installer, or do a tar xvzf, and
then run as root to get the initial registration done, when I subsequently
run as ~jrgm, I run fine, I have mail overlays, can run mail, can change
themes, ... the overlayinfo and other files created on the initial run as
root are created with 644 for files and 755 for directories (given a root
umask of 022).

All my great comments got deleted for some reason. Anyway, the gist
of it is that bug 42184 sounds like it is being treated like an
esoteric security issue but what I'm seeing today is that Moz
won't even *BOOT* as a user anymore but it runs perfectly as root.
So I "chmod -R a+w ." and guess what? Now it works fine.

John, did you change the owner/permissions back after the install-run and before
the run as normal user?
David, Doug Collinge, if you ran Mozilla once as root (and it ran fine), then
change the owner, and it doesn't work and more, then this is not a dup of bug
42184. If anything, it's a bug of bug 41057.

No. To be clear, I did not use 'chmod' at any time. After the initial run
as root, I could run as 'jrgm' without error.
However, what Doug says is correct: if you do not do the initial run as
root (just do the install/untar as root), and then try to run as 'user',
the program aborts completely. [I don't know if that is new behaviour or
if it was already like that, since I don't typically install the daily
builds as root on my system].

Seems like I misunderstood you, John. What you describe is indeed bug 42184. But
Doug Collinge seem to be completely unable to run Mozilla as normal user, which
would be a dup of bug 41057. Anyway, doesn't really matter (unless you want to
come up with a workaround again). All of you know the relevant bugs now :).

Okay, the crux of _this_ bug was what syd said, Jul 13: overlayinfo was
being written with zero rwx permissions for 'go'. That is fixed: if user
A does the install and initial run, then user B can run that installed app.
The other bugs cover different issues: what app should do the initial install,
and whether bob the user needs write access to the bin directory at runtime
(although I did not need write access and could run fine).