User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:188.8.131.52) Gecko/20070309 Firefox/184.108.40.206
Build Identifier: Thunderbird version 220.127.116.11 (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.
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.
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
Second error in log (point 5)
Error: gMsgFolderSelected has no properties
Source File: chrome://messenger/content/msgMail3PaneWindow.js
Event should move to correct place every time without error when dragged.
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?
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?
I can't reproduce the described problem using the same thunderbird and lightning in new profile. WFM
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.
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.
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.
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.
I can confirm, with a current debug build of Lightning (built on 5/21/07 and Thunderbird 18.104.22.168.
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:
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.
Created attachment 265630 [details]
Log from kewis dav server
Created attachment 265631 [details]
Dav Explorer log from kelv server
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,
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.
Works fine with original limitexcept + propfind.
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.
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.
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"
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?
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..
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.
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.
(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  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.
(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 ***
> 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.
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.
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.
Both lightning and sunbird nightlies now work for me, with the old Limit directives now, can't reproduce the moving event bug anymore.