Closed Bug 305733 Opened 19 years ago Closed 19 years ago

Can't publish remote calendar - NS_ERROR_NOT_AVAILABLE

Categories

(Calendar :: General, defect)

x86
Windows XP
defect
Not set
major

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: abl, Assigned: mostafah)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 MultiZilla/1.8.1.0b
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 MultiZilla/1.8.1.0b

Remote calnedar via WebDAV stopped working with 1.7.11 version of mozilla.
Suggested calendar version (
http://ftp.mozilla.org/pub/mozilla.org/calendar/xpi/windows/calendar_windows_latest.xpi
)worked with 1.7.8 and previous versions. Now it installs correctly, displays
events, but you cannot publish any event to remote calendar (not a problem with
server - i still publish events with 1.7.8 moz.).
Reload remote calendar works, but when i publish event, i get following error in
JS console :
Error: [Exception... "Component returned failure code: 0x80040111
(NS_ERROR_NOT_AVAILABLE) [nsIHttpChannel.requestSucceeded]"  nsresult:
"0x80040111 (NS_ERROR_NOT_AVAILABLE)"  location: "JS frame ::
chrome://calendar/content/publish.js :: anonymous :: line 297"  data: no]
Source File: chrome://calendar/content/publish.js
Line: 297
No error is shown, event is shown as published in calendar, but, if i publish
another event (with "automatically publish changes... ") - previous event
disappears.

Reproducible: Always

Steps to Reproduce:
1. Install mozilla 1.7.11
2. Install calendar (recommended 1.7 version from
http://www.mozilla.org/projects/calendar/download.html )
3. Try to upload event to WebDAV enabled calendar.

Actual Results:  
Event is not published. LiveHTTPHeaders shows GET requests when i refresh
calendar, but no tries to PUT any event, etc. Networking is not working in this
case ;-)

Expected Results:  
Publish events to remote calendar

Tried with clean profile (except liveHTTPheaders).
Solution - rollback to 1.7.8 with security holes :/
Assignee: dmose → mostafah
Component: CalDAV provider → General
QA Contact: caldav-provider → general
Do you have the ability to build you own version of calendar?  The trunk
versions handle remote calendars in a fairly different way.  It'd be nice to
know whether this issue is still present there.
Ok, i can build mozilla by myself, but my problem is not  about trunk versions.
AFAIK 1.7 branch is frozen for new features, etc, only security fixes. And my
problem is with "stable" (sorry for quotes, but in my opinion this is true -
1.7.11 has so many problems comparing with 1.7.8) version of mozilla - not with
trunk version.
Or you mean "1.7-trunk" branch?
The calendar extension, which is available on the website is pretty old and we
haven't come around to build a new one. If we can't find out if this happens on
current builds also, then we can't determine if this is a current bug or not.
Aditional info (no, i didn't build mozilla by myself) - calendar behavior with
1.7.11 (official build - calendar and mozilla) - on one computer - bug which i
described; On two others - you can publish calendar, but something weird
happened with character set interpretation - letter "ë" in event can broke
entire calendar, and make him unusable (i can't even see or edit any of few
hundreds events in my old calendar file), and one computer looks that works as
expected. All are winXP SP1.
More info when i build calendar by myself. Till now still use moz 1.7.8.
Again - tested with 1.7.12 - and it works. No other changes made to config (it
is locked via user.js), just uninstall old (1.7.11) version, install new,
install the same calendar - and it works. 
One of computers wasn't used from bugreport time, so no changes were made to
system config too ;-) 
Very strange bug. Which resolution should i use for this bug? As far as i know,
"fixed" is for bugs with mozilla code changes. So, WORKSFORME?
WORKSFORME is good.  Thanks for keeping up with this bug.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.