Beginning on October 25th, 2016, Persona will no longer be an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 380291 - Event movement failure on local or remote events
: Event movement failure on local or remote events
Status: VERIFIED DUPLICATE of bug 387559
[0.5 publish fails]
Product: Calendar
Classification: Client Software
Component: Provider: ICS/WebDAV (show other bugs)
: unspecified
: x86 Windows XP
: -- major (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
Depends on:
  Show dependency treegraph
Reported: 2007-05-10 08:28 PDT by Kelv
Modified: 2008-02-04 02:13 PST (History)
10 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---

Log from kewis dav server (45.84 KB, text/plain)
2007-05-21 22:25 PDT, cmtalbert
no flags Details
Dav Explorer log from kelv server (11.85 KB, text/plain)
2007-05-21 22:25 PDT, cmtalbert
no flags Details

Description Kelv 2007-05-10 08:28:17 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv: Gecko/20070309 Firefox/
Build Identifier: Thunderbird version (20070326) + Lightning nightly build for 10th May 2007

The first time an event is moved by dragging the event moves but an error is produced in the console. Subsequent attempts to move the event fail in that the event does not move and a different error occurs.

Reproducible: Always

Steps to Reproduce:
1. Go to week view.
2. Drag an event to a new day / time.
3. Look in the error log.
4. Drag the same event again to a different day / time.
5. Look in the error log.

Actual Results:  
First error in log (point 3)

Error: [Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIHttpChannel.requestSucceeded]"  nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)"  location: "JS frame :: file:///C:/Documents%20and%20Settings/Administrator/Application%20Data/Thunderbird/Profiles/tzqnsmqq.testing/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calICSCalendar.js :: anonymous :: line 378"  data: no]
Source File: file:///C:/Documents%20and%20Settings/Administrator/Application%20Data/Thunderbird/Profiles/tzqnsmqq.testing/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calICSCalendar.js
Line: 378

Second error in log (point 5)

Error: gMsgFolderSelected has no properties
Source File: chrome://messenger/content/msgMail3PaneWindow.js
Line: 226

Expected Results:  
Event should move to correct place every time without error when dragged.
Comment 1 Martin Schröder [:mschroeder] 2007-05-10 10:09:33 PDT
Kelv, this is the same error message as in your comment from bug 379498. The second error message looks like it comes from Thunderbird, not Lightning. Maybe you have sme kind of misconfiguration with your remote calendars?
Comment 2 Kelv 2007-05-10 11:51:34 PDT
It does look like it has the same route cause. However, the means by which the error is created are different. In this one I am actually dragging the events around. In <a href="">bug 379498</a> I am double clicking on an event and changing the time.

As regards misconfiguration, why would it be that 0.3.1 has no problem with but 0.5 does?
Comment 3 Omar Bajraszewski 2007-05-10 12:37:32 PDT
I can't reproduce the described problem using the same thunderbird and lightning in new profile. WFM
Comment 4 cmtalbert 2007-05-17 10:41:56 PDT
User is accessing the ICS calendar with 0.3.1 in one profile and with a 0.5 nightly in another profile.  This interaction may have issues, and should be tested.

1. Install Tb + lightning with a 0.3.1 profile and a 0.5 nightly profile
2. Access an ICS calendar from 0.3.1 
3. Access the same ICS from 0.5 using steps above, see if you can reproduce the reported behavior.

Comment 5 Kelv 2007-05-17 11:21:41 PDT
I have gone a bit further into this. My DAV server is Apache 2.2 + mod_DAV.

Under normal profile (TB2.0/Lightning 0.3.1)..

1. Start up TB. Apache access log shows HTTP GET on the remote calendar.
2. Go to monthly view and move test event. access shows a successful GET and PUT (200)

Under testing profile (TB2.0/Lightning 0.5 pre)..

1. Start up TB. Apache access log shows HTTP GET on the remote calendar.
2. Go to monthly view and move test event. PUT shows 401 (forbidden).

The calendar URL, username and path are exactly the same between the normal and test profiles. The test profile password manager shows the correct URL, username and password. Therefore it must be that it is just not sending it correctly.
Comment 6 Kelv 2007-05-17 11:24:47 PDT
To further qualify my comment #5, I went so far as to delete the login info from the password manager in the test profile, and re-entered it. When I then moved the test event I was prompted for login information as I expected. As soon as I had entered it, exactly as it is in 0.3.1, the same 401 in logs + error in tb error console occured.
Comment 8 cmtalbert 2007-05-21 13:27:04 PDT
I can confirm, with a current debug build of Lightning (built on 5/21/07 and Thunderbird
Comment 9 cmtalbert 2007-05-21 22:23:51 PDT
I've done quite a bit of QA as well as debugging, and I still don't see what has gone wrong here.

I can reproduce the error when using the server in question:  However, I *cannot* reproduce the problem when using one of the calendar test dav servers.  I also used DAVExplorer ( to verify access to the DAV system on both servers, and both servers responded in very similar ways.  I have attached the logs from Dav Explorer.  There are two PUTS because both servers had a Java EOF exception in the first attempt to upload the modified ICS file.

Everything points to this being some kind of server configuration bug, except the fact that it works with 0.3.1 Lightning and fails with 0.5 lightning. (I have verified that it works with the kelv server in 0.3.1).

When Debugging a PUT, I see the following status come back from the server w/current code:
Kelv      Kewis
200        200
200        204
401        207

Obviously, the write fails when the Kelv server receives that 401.

I don't see what check-ins could have caused this change in behavior.  Were there checkins to other locations that affected the password management subsystem?  But, if so, why don't those checkins affect the kewis server, since it makes the same calls to the password system.

Here are the branch checkins to the ICS provider since the beginning of the year:

Here are the mozilla/netwerk directory checkins on branch since the beginning of the year:

At this point, I think that the only thing to do would be for Philipp and Kelv to sit down and go through their Dav installations piece by piece and see what is different between the two.  Perhaps that will elucidate some important difference in why this works on one dav server but not the other, and why it worked back in 0.3.1.
Comment 10 cmtalbert 2007-05-21 22:25:05 PDT
Created attachment 265630 [details]
Log from kewis dav server
Comment 11 cmtalbert 2007-05-21 22:25:45 PDT
Created attachment 265631 [details]
Dav Explorer log from kelv server
Comment 12 Andrew McMillan 2007-05-21 23:05:02 PDT
I notice that the kewis is returning this content type in that last response:


which looks completely bogus.  The other server is returning:


which is much more what I would expect.

There is also a suspicious looking "1f5d" at the start of the response from kewis, and from my experience Mozilla won't respond nicely to a text/xml response which contains rubbish before the start of the XML.  Though maybe that's just my memory playing tricks there :-)

Hope that is some help,
Andrew McMillan.
Comment 13 Kelv 2007-05-24 13:43:30 PDT
My DAV servers had <LimitExcept GET HEAD OPTIONS> on the DAV directory. Upon removal of the directive everything started working as it should e.g. events could be moved around and edited at leisure with no errors showing in the TB console. It sounds like Ctalbert is right in suggesting maybe 0.3.1 has been submitted auth details with every request, so when 0.5pre didn't there was a 401 when anything other than the above was requested.
Comment 14 Kelv 2007-05-24 13:47:09 PDT
Works fine with original limitexcept + propfind.
Comment 15 Kelv 2007-05-24 18:32:24 PDT
Spoke too soon. I came back later, uninstalled 0.3.1 from my main profile, installed the latest 0.5 nightly and started up TB. With the Limit line above in the dreaded 401 was back on PUT. I had to disable the limitexcept.
Comment 16 Ed 2007-05-31 09:34:02 PDT
I'm seeing similar behavior that Kelv reports.  I use a similar setup, and I've got the same sort of WebDav controls in place (open reads, password protected writes).  I've seen the same error reported in the ticket open as "First error in log".  Similar to Kelv, this setup was working for me with Sunbird 0.3.1.

If there's additional information I can provide to help track the issue, let me know what to include.

As discussed over in bug 380292, the Thunderbird / Sunbird process stays up after window closure in this case.  One has to kill it via the Task Manager.
Comment 17 Michael Cronenworth 2007-06-14 10:33:53 PDT
I also see this on my TB 2.0 and Lightning 0.5 nightly system.

I am using WebDAV with Apache and the <LimitExcept GET HEAD OPTIONS> options.

If I take that out then it works fine.


Manually publish your calendar before editing and before you close TB. (so two publishes) This requires you to right-click on your calendar name and select "Publish Calendar"
Comment 18 Kelv 2007-06-25 08:42:02 PDT
The only way I can get it to work reliably is by taking my limit clauses out entirely, which has obvious security implications. Any news?
Comment 19 Felix Hebeler 2007-07-07 03:46:15 PDT
Well for me it results in not being able to see any calendar entries, not even of local ones (bug 386734), after reload.
I can't take out the limit clauses though, no idea if that would work.
Publishing the calendar manually doesn't work for me either..
Comment 20 Stefan Sitter 2007-07-12 11:00:34 PDT
I would suggest to resolve this bug as a duplicate of Bug 387559 although this bug is older. Bug 387559 has clear STR and information on the regression range.
Comment 21 Michael Cronenworth 2007-07-30 06:25:15 PDT
Now I can no longer use remote calendars. The latest nightly has removed the option to Publish Calender (grayed out) so the workaround I described in comment #17 is no longer possible. Who keeps removing WebDAV functionality???? I'm fixing to go hunt down change logs to find this guy.

Do any of the Lightning devs care about this bug? There's half a dozen duplicates and no one has taken one or even cared to mark them as duplicates.
Comment 22 Michael Büttner (no reviews TFN) 2007-07-30 07:40:46 PDT
(In reply to comment #21)
> Now I can no longer use remote calendars. The latest nightly has removed the
> option to Publish Calender (grayed out) so the workaround I described in
> comment #17 is no longer possible. Who keeps removing WebDAV functionality????
> I'm fixing to go hunt down change logs to find this guy.
I'm the one you're after :-) I just tried to find out why this option has been disabled. This was an unfortunate copy'n'paste bug that has been introduced with the patch for bug #371916. See [1] for the relevant source code location. I'm going to submit a patch in a minute, just select any event to make the option being enabled as a temporary workaround.


Comment 23 Stefan Sitter 2007-07-30 07:54:11 PDT
(In reply to comment #20)
No objections were raised, resolving as duplicate.

(In reply to comment #21)
Michael, if you find new regressions or errors during testing of nightly builds please file a new bug report (if the issue is not already filed). 

*** This bug has been marked as a duplicate of bug 387559 ***
Comment 24 Michael Büttner (no reviews TFN) 2007-07-30 07:58:34 PDT
> Michael, if you find new regressions or errors during testing of nightly builds
> please file a new bug report (if the issue is not already filed). 
I filed bug 390147 on the 'export calendar' issue.
Comment 25 Stefan Sitter 2007-09-12 09:00:50 PDT
Bug 387559 is fixed now. I'd like you to retest with a Sunbird or Lightning 0.7pre (20070912) or newer build if your issue is entirely fixed now.
Comment 26 Kelv 2007-09-12 15:22:04 PDT
Re: Stefan - Will do. Fingers crossed! :) Which Apache Limit directives would you like used if you have a preference? If none I'll try with what they were prior to finding the bug.
Comment 27 Felix Hebeler 2007-09-13 01:17:43 PDT
Both lightning and sunbird nightlies now work for me, with the old Limit directives now, can't reproduce the moving event bug anymore.

Note You need to log in before you can comment on or make changes to this bug.