294944 - Accepted input for Remote Server URL is inconsistent between new/edit calendar dialogs

Status: RESOLVED FIXED

(Calendar :: Sunbird Only, defect)

Description

[Josh]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

Whenever you create a new calendar if you input the remote URL and check the box
that publishes your changes automatically, those settings are never saved.  You
have to EDIT the calendar after you've created it to get those to stick.

Reproducible: Always

Steps to Reproduce:
1. Create a new calendar.  Enter a Remote URL and check the publish box.
2. Go back and edit your settings to check them (those two settings (maybe more)
weren't really saved)

Actual Results:  
Didn't save my settings

Expected Results:  
Save my settings

I'm using the Cal extension for thunderbird.  Looks like the cal ver is
2005011112-cal

Comment 1

[Joey Minta]

Josh,
   Right now I'm unable to reproduce this bug.  In fact, it seems to directly
conflict with bug 217197, which says almost the exact opposite (that only new
calendars can be made remote, editing doesn't work).  First off, are you seeing
this error with the 'New Calendar File' option or the 'Subscribe to remote
calendar' option?  Secondly, after creating a new remote calendar, you should
immediately see the refresh icon displayed in the calendar list.  With your
error, do you see this?
   If all else fails, try creating a new remote calendar and then closing
TB/Calendar before editing it as your workaround describes.  Now, in your
profile folder (For WinXP it's: C:\Documents and Settings\<username>\Application
Data\Thunderbird\Profiles\<random number>.default\Calendar\) open the
CalendarManager.rdf file in a text editor (like wordpad).  Find the entry for
the calendar you just created and look for lines like 
NC:remote="true"
NC:remotePath="http://blah"
Are they there?

The only other thing I can think that it might be is some error specific to the
URL you are entering.  Can you say what URL you're trying to use?

Comment 2

[Josh]

I go to File->New Calendar File..  Fill in all the blanks, click ok.  Go back to
the calendar (calendars tab), right click the new calendar, click edit Calendar
and the only thing filled in is the Calendar name and local file location.  The
Remote Server URL and checkbox choices are not saved.  

My remote server url is file://x:\mycal.ics

After I create the calendar, I viewed the CalendarManaer.rdf as instructed. 
remote="false" and I do not see remotepath anywhere:

<RDF:Description RDF:about="urn:calendarcontainer:calendar5"
                   NC:active="true"
                   NC:serverNumber="5"
                   NC:name="blarg"
                   NC:path="C:\Documents and Settings\joshd\Application
Data\Thunderbird\Profiles\h4qeg5s0.default\Calendar\CalendarDataFile5.ics"
                   NC:color="#F9F4FF"
                   NC:remote="false" />

I should also add.  On a seperate machine machine, the exact same thing happens.
 Only on his, the check box selection is saved.  But he still has remote=false
with no remotepath.

Comment 3

[Joey Minta]

(In reply to comment #2)
> My remote server url is file://x:\mycal.ics
> 
This is the problem.  Calendar expects remote paths to begin with http://,
https://, or ftp://.  (That's why it says Remote Server URL.) If the path does
not, then it is ignored.  As long as you are able to browse to the location you
want to save the calendar in, you should choose this in 'Local File Location'. 
Changes you make to the calendar will be stored there then.  Other users with
access to x: can choose to 'Open Calendar File' and point Calendar to this
location, but be wary that if more than one user has the file open, data
corruption/loss can occur.

Please let me know if this solves your problem.

Comment 4

[Josh]

According to calendarhelp.mozdev.org the "Publish Entire Calendar" feature,
supports five URL protocols for sharing calendars: file, ftp, http, https and
webcal.  

Is this a different mechanism than REMOTE SERVER URL.  I had assumed that they
both go hand in hand.  Both publish your calendar, only difference is that
REMOTE SERVER URL downloads the file, then publishes it back automatically (if
you have the box checked).

That brings up another question.  If publishing a calendar supports file:// and
remote server doesn't, then why does it keep my settings after I edit the
calendar, AND functions properly from then on?

Comment 5

[Joey Minta]

(In reply to comment #4)
You're definitely asking the right questions.

To make a long story short: The 'New Calendar File' checks for the three
protocols I listed when a calendar is created.  When you edit the calendar, it
doesn't do these checks.  So, there is some inconsistency in the code.



New Calendar:

http://lxr.mozilla.org/mozilla/source/calendar/resources/content/calendarManager.js#350



Edit Calendar:

http://lxr.mozilla.org/mozilla/source/calendar/resources/content/calendarManager.js#416



As far as the 'Publish Entire Calendar' dialog goes, that doesn't do any checks
either, and merely relies on the actual publishing mechanism to return the
error.  (This is what is also happening when you use the 'Edit Calendar' option
to put in an arbitrary address.)

It should be pointed out that calendarManager.js (the file referenced above) is
now an obsolete file, and the entire 'New Calendar File' setup has been
completely re-done for the next version of Calendar.  In the new dialog, the
differences between remote and local calendars are made more explicit.  The
'Edit Calendar' portion hasn't made it back into the new code yet, though.  

Therefore, I'm going to go ahead and confirm this bug, regarding the
inconsistency between dialogs.  Ideally, a proper re-write will make this
problem disappear.  When the next release of Calendar comes out, please test to
make sure that this is the case.

Status: NEW
OS/Hardware: All
Component: Front-End (since this is where the error checks are inconsistent)
Summary rewritten.  Was "Remote Server URL and Publish Changes Checkbox settings
not saved when creating a new Calendar"

Comment 6

[Josh]

Thanks, just a couple more questions.

Your explanation still doesn't seem to answer the question: Why does entering
file:// actually work then?  In my setup, I would like the primary data files on
each workstation so they can be backed up, but I would like a "copy" of the
calendar to be stored on a web server so others ran subscribe to everyone's
calendar.  Using REMOTE URL file:// accomplishes this.

Also, instead of simply ignoring my bad url, it would really be nice if it told
me something useful, like "Hey I only accept http/ftp" or something like that.

Thanks,

Josh

Comment 7

[Joey Minta]

(In reply to comment #6)
> Thanks, just a couple more questions.
> 
> Your explanation still doesn't seem to answer the question: Why does entering
> file:// actually work then?  
When Calendar hands off the problem to the internal publishing mechanicism, it
CAN handle file:// (and probably webcal://, like CalendarHelp says, but I
haven't checked).  So, as long as Calendar will let you input file://,
everything works fine.  Notice if you try putting in garbage, it throws an
exception in 'Publish Entire Calendar'.  'Reload Remote Calendar' lets this fail
silently.

> Also, instead of simply ignoring my bad url, it would really be nice if it told
> me something useful, like "Hey I only accept http/ftp" or something like that.
Yep, you probably want to file another bug on this one, since, as far as I can
tell, even the new Create Calendar Wizard doesn't do this.  (Search first, but
I'm pretty sure this bug doesn't exist.)

Comment 8

[Joey Minta]

I fixed this in bug 295343.