380291 - Event movement failure on local or remote events

Status: VERIFIED DUPLICATE of bug 387559

(Calendar :: Provider: ICS/WebDAV, defect)

Description

[Kelv]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Build Identifier: Thunderbird version 2.0.0.0 (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]]

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]

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="https://bugzilla.mozilla.org/show_bug.cgi?id=379498">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]

I can't reproduce the described problem using the same thunderbird and lightning in new profile. WFM

Comment 4

[cmtalbert]

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.

Steps:
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.

Marking QAWANTED.

Comment 5

[Kelv]

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]

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 7

[Martin Schröder [:mschroeder]]

The root of the error message may be http://mxr.mozilla.org/mozilla1.8/source/netwerk/protocol/http/public/nsIHttpChannel.idl#213 on http://mxr.mozilla.org/mozilla1.8/source/calendar/providers/ics/calICSCalendar.js#379.

Comment 8

[cmtalbert]

I can confirm, with a current debug build of Lightning (built on 5/21/07 and Thunderbird 2.0.0.0.

Comment 9

[cmtalbert]

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: kelv.net.  However, I *cannot* reproduce the problem when using one of the calendar test dav servers.  I also used DAVExplorer (http://www.davexplorer.org/download.html) 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:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=MOZILLA_1_8_BRANCH&branchtype=match&dir=mozilla%2Fcalendar%2Fproviders%2Fics&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-02-01+00%3A00%3A00&maxdate=2007-05-17+00%3A00%3A00&cvsroot=%2Fcvsroot

Here are the mozilla/netwerk directory checkins on branch since the beginning of the year:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=MOZILLA_1_8_BRANCH&branchtype=match&dir=mozilla%2Fnetwerk%2F&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-01-01+00%3A00%3A00&maxdate=2007-05-20+00%3A00%3A00&cvsroot=%2Fcvsroot

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]

Attachment: Log from kewis dav server

Comment 11

[cmtalbert]

Attachment: Dav Explorer log from kelv server

Comment 12

[Andrew McMillan]

I notice that the kewis is returning this content type in that last response:

 <D:getcontenttype>application/x-httpd-php</D:getcontenttype>

which looks completely bogus.  The other server is returning:

 <D:getcontenttype>httpd/unix-directory</D:getcontenttype>

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]

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]

Works fine with original limitexcept + propfind.

Comment 15

[Kelv]

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]

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]

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.

** WORK AROUND **

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]

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]

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 [:ssitter]]

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]

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)]

(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.

[1] http://lxr.mozilla.org/mozilla1.8/source/calendar/lightning/content/messenger-overlay-sidebar.xul#170

Comment 23

[Stefan Sitter [:ssitter]]

(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). 

Comment 24

[Michael Büttner (no reviews TFN)]

> 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 [:ssitter]]

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]

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]

Both lightning and sunbird nightlies now work for me, with the old Limit directives now, can't reproduce the moving event bug anymore.