230617 - Jan 9 Build will not create new Calendar, Event, or Task for *first time* installation

Status: RESOLVED FIXED

(Calendar :: General, defect)

Description

[Rick Stockton]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040106
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040106

Calendar GUI comes up, showing a multi-week Calendar. Current day is
highlighted. On the toobar, only "New Event" and "Multiweek" are highlighted.
Pressing either of these icons has no effect. The corresponding MenuItems also
fail to present any change to the user. "File - New Calendar" does nothing, I
was expecting a GUI to enter a name and specify a file location. Upper left
"Calendars" shows no Calendars, just an empty gray box. Right-Click and attempt
to create a new calendar via context menu also does nothing. And, I can't create
any Tasks

Reproducible: Always

Steps to Reproduce:
1. Special setup: New installation of the Suite, with no existing calendars.
2. Bring up Calendar Window.
3. Attempt to create a Calendar, Event, or Task

Actual Results:  
nothing. Upon restart, there is still no calendar, and you still can't create
one. Failure to create a calendar might be the root of the problem, with the
other behaviors all being symptoms of having no Calendar (Maybe, once I can make
a Calendar, I might be able to create/edit/delete events and tasks, or change
views.)

Expected Results:  
Created a Calendar, let me create events, tasks, etc. 

Please feel free to build me a Linux test XPI and have me try it out at any
time. I can't build from source, but I can save/restore my profile and my
Mozilla codebase as often as we desire.

I'm calling it "Blocker" because Calendar appears to be totally unusable for a
brand-new user, who doesn't have an existing calendar or file to import.

Comment 1

[Stephen Moehle]

I had the same problem, also on Linux.  The cause turned out to be that the
Calendar directory in my profile had weird permissions - 001 (only execute for
other).  As soon as I changed the permissions to 775, everthing worked OK.

Tested with Linux nightly build from Jan 10, Jan 9 calendar xpi, and a new profile.

Comment 2

[Rick Stockton]

I've just confirmed comment 1: Problem is resolved by correcting the permissions
assigned to the profile 'Calendar' directory.

Comment 3

[Rick Stockton]

And of course, my Thanks to Stephen!

Comment 4

[Jussi Kukkonen]

Bug 196693 is about the calendar installer not fixing permissions
Bug 196694 is about mozilla hanging on wrong file permissions

I guess this is a dupe of one of those.
 

Comment 5

[Stephen Moehle]

Not dups.  Bug 196693 and bug 196694 are talking about the calendar directory
under chrome.  This bug is about the Calendar directory in the user profile.

Comment 6

[rmichael]

This bug is still in the released 1.6.

I'm glad others have provided the solution, thanks.

Note that the bad perms on the "Calendar" directory (d--------x) also blocks
"Tools->Subscribe to remote calendar".

Comment 7

[Mostafa Hosseini]

*** Bug 231544 has been marked as a duplicate of this bug. ***

Comment 8

[Mostafa Hosseini]

*** Bug 231632 has been marked as a duplicate of this bug. ***

Comment 9

[Mostafa Hosseini]

*** Bug 231743 has been marked as a duplicate of this bug. ***

Comment 10

[Mostafa Hosseini]

*** Bug 230615 has been marked as a duplicate of this bug. ***

Comment 11

[Simon Paquet [:sipaq]]

Seeing all the dupes I think we can confirm this bug.

Comment 12

[JB]

*** Bug 232510 has been marked as a duplicate of this bug. ***

Comment 13

[Mostafa Hosseini]

This fixes the problem:
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=calendarManager.js&branch=&root=/cvsroot&subdir=mozilla/calendar/resources/content&command=DIFF_FRAMESET&rev1=1.63&rev2=1.64

The original cause is from:
http://bugzilla.mozdev.org/show_bug.cgi?id=5134

Although fixed I'll leave bug open until new XPI is built.

Comment 14

[Mostafa Hosseini]

*** Bug 234338 has been marked as a duplicate of this bug. ***

Comment 15

[Mostafa Hosseini]

*** Bug 234556 has been marked as a duplicate of this bug. ***

Comment 16

[Mostafa Hosseini]

*** Bug 234676 has been marked as a duplicate of this bug. ***

Comment 17

[George Embrey]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040122 Debian/1.6-1

Calendar Installed from:
Mozilla Calendar 2004021918-cal

Users created prior to Mozilla 1.6 and Calendar being installed on Knoppix 3.2
could not create calendars.  

Workaround - Change Permissions as follows:
$ su - root
# chmod u+rwx ~username/.mozilla/username/xjhlwgcgh.slt/Calendar

# ls -lA ~username/.mozilla/username/xjhlwgcgh.slt

Output should now be similar to:
drwx---S-x username  username   4096  Feb 20 18:36 Calendar

Notes:
(1) The xjhlwgcgh.slt part will be different for each user.
(2) username in both cases = the username of the user having the problem.
(3) For Security sake don't give any group permissions - leave group a ---
Once the permissions are changed the Calendar works normally.

Comment 18

[Roland Mainz]

Alternative solution:
Copy the following shell script to
.../dist/bin/init.d/S80calendar_fix_permissions_bug_230617.sh or
~/.mozilla/init.d/S80calendar_fix_permissions_bug_230617.sh (without the "--
snip --", please :)
-- snip --
#!/bin/sh

if [ -z "${MOZ_USER_DIR}" ] ; then
    echo "${0}: Internal error: MOZ_USER_DIR not set."
    exit 1
fi

for cf in "${HOME}/${MOZ_USER_DIR}"/*/*.slt/Calendar ; do
    if [ ! -r "${cf}" -o ! -w "${cf}" -o ! -x "${cf}" ] ; then
        echo "${0}: Fixing permissions for ${cf}"
        chmod u+rwx "${cf}"
    fi
done
# EOF.
-- snip --
Since bug 230468 ("RFE: mozilla should provide a simple way to run custom shell
scripts at mozilla startup and shutdown") such scripts are being executed
automatically when being placed in $dist/bin/init.d/ or ~/.mozilla/init.d/
You can check for [ -r "$dist/bin/init.d/README" ] whether your Mozilla build
supports such pluggable shell scripts.

Comment 19

[Roland Mainz]

Mostafa Hosseini:
Should I make a patch for Mozilla with the workaround listed in the previous
comment (that's very easy and will fix all broken directory permissions
automagically :) ?

Comment 20

[Mostafa Hosseini]

*** Bug 236046 has been marked as a duplicate of this bug. ***

Comment 21

[Mostafa Hosseini]

(In reply to comment #13)
> Although fixed I'll leave bug open until new XPI is built.
New XPIs were built on 2004-04-08

Comment 22

[Brian Rogers]

*** Bug 234730 has been marked as a duplicate of this bug. ***

Comment 23

[Scott Wolfe]

OS linux, mozilla 1.7.2, calendar 1.7.1.8a2

permissions still not fixed for user install.
worked for root.

Comment 24

[Pi]

Attachment: spam

Comment 25

[Kalin Kozhuharov]

Can anyone delete this SPAM attachment?

Comment 26

[Reed Loden [:reed]]

The bugspam monkeys have been set free and are feeding on Calendar :: General. Be afraid for your sanity!