Open Bug 314594 Opened 14 years ago Updated 4 years ago

No error message if invalid URL used for new calendar, creates invalid calendars

Categories

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

defect
Not set

Tracking

(Not tracked)

People

(Reporter: anthonypahitas, Assigned: Lenni)

References

Details

(Keywords: uiwanted, Whiteboard: [not needed beta][has l10n impact])

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
Build Identifier: 2005-10-31-08-trunk

When adding or reloading a remote calendar with a bad URL, error number 0x804a0107 is displayed. An appropriate friendly message should be displayed instead.
Furthermore, correcting the URL does not persist upon the next restart (there seems to be a more general more of saving edited information between restarts, ie. even when using valid URLS's).

Reproducible: Always

Steps to Reproduce:
Create reomte calendar with URL:
http://nosuchdomain.com/or/nosuchcalendar.ics


Actual Results:  
Error 0x804a0107.

Expected Results:  
Message "Could not locate calendar <Calendar_Name> at <Bad_URL>".

Display a friendly message.
confirmed, linux/x86, my build, 20051031.

I get the following on the cmdline:

Parsing the file failed:[Exception... "Component returned failure code: 0x804a0100 [calIICSService.parseICS]"  nsresult: "0x804a0100 (<unknown>)"  location: "JS frame :: file:///usr/local/src/mozilla/sunbird/sunbird-200510311632/components/calICSCalendar.js :: anonymous :: line 396"  data: no]

The calendar creation is successful, however, ironically.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All
Version: unspecified → Trunk
I just want to make sure I understand what this bug is asking for, since the summary and comment #1 seem to be heading off in a different direction from 'Expected Results'.

When I tested this, I did get a 'nice' error dialog about read-only status, which to me means the error was 'handled'  (Summary says unhandled).  As I understand it, this bug is a request for specifically handling the case where the calendar doesn't exist, and replacing the 'details' part of the dialog, which says error 0x804a0107 with a message about the calendar not existing.

Is this correct or is there something more severe going on here where an error is actually not being caught?
I didn't get any error dialog in this case; just the txt on the cmdline as shown in Comment #1.
> When I tested this, I did get a 'nice' error dialog about read-only status,
> which to me means the error was 'handled'  (Summary says unhandled). 

Well, it's handled in the sense that we no longer crash, behave unpredictably, or lose data.  But this sort of error message still doesn't make it easy on the user to figure out what the problem is.  I think we probably want as an (eventual) goal to never show this dialog except as an absolute last resort, and always have a user-friendly error message to any condition that might be encountered in normal use conditions.
Summary: Add/Reload remote calendar with bad URL causes unhandled error 0x804a0107. → need user-friendly error presentation
I've written a UI spec on how I think we can improve this:
http://wiki.mozilla.org/Calendar:Feature_Implementations:Error_Reporting
Comments on that proposal:
Just because firefox uses an error page doesn't mean that sunbird should copy it. Firefox has specific reasons for the page (mainly tabs), but that reason doesn't hold for sunbird.
For example, the dialog-with-error-page looks overly busy. There is no need for all those borders, different font sizes and everything. Just use a normal dialog window.
In the wizard, the extra border is also not needed.

And the main problem tracked in this bug is text, not UI or theme or graphics. The text needs to be much clearer. The presentation is for us to worry later.
Reassigning all automatically assigned bugs from Mostafa to nobody@m.o

Bugspam filter: TorontoMostafaMove
Assignee: mostafah → nobody
I observed 3 different cases of bad url each behaving differently:

1. http://nosuchdomain.com/or/nosuchcalendar.ics
is described in this bug. The calendar is created without an error dialog. After creation of the first event an error dialog pops up. The created event is not deletable.

2. http://server/folder/Test.ics
The calendar is created without an error dialog. After creating the first event, there is an error message in the error console (no dialog!):

Error: [Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIHttpChannel.requestSucceeded]"  nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)"  location: "JS frame :: file:///C:/Programme/Calendar/components/calICSCalendar.js :: anonymous :: line 420"  data: no]
Source File: file:///C:/Programme/Calendar/components/calICSCalendar.js
Line: 420

Additionally no normal shutdown is possible (Sunbird needs to be killed in Task manager)

3. is described in bug 350703
The calendar is not created, error is in the console (no dialog!)

All done with fresh profiles using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060831 Calendar/0.3a2+
*** Bug 350703 has been marked as a duplicate of this bug. ***
Changing the summary to accurately reflect the issue here.

Also, in the name of having all information available, I have also copied the steps for the third case o this problem from Bug 350703.

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.6)
Gecko/20060728 Firefox/1.5.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1)
Gecko/20060827 Calendar/0.3a2+

when you try to subscribe remote calendar based on URL which is not valid you
get error instead of user friendly alert

Reproducible: Always

Steps to Reproduce:
1. subscribe remote calendar URL= Error:
   -> when you type : Next button become enabled
2. finish wizard to create new calendar
Actual Results:  
error console

Error: [Exception... "Component returned failure code: 0x804b0012
[nsIIOService.newChannelFromURI]"  nsresult: "0x804b0012 (<unknown>)" 
location: "JS frame ::
file:///C:/Documents%20and%20Settings/Damian/Pulpit/sunbird/components/calICSCalendar.js
:: anonymous :: line 127"  data: no]
Source File:
file:///C:/Documents%20and%20Settings/Damian/Pulpit/sunbird/components/calICSCalendar.js
Line: 127
Summary: need user-friendly error presentation → No error message if invalid URL used for new calendar, creates invalid calendars
*** Bug 349712 has been marked as a duplicate of this bug. ***
Component: General → Provider: ICS/Webdav
QA Contact: general → ics-provider
Hardware: PC → All
I've been seeing this error recently for a calendar I've been subscribed to for a few months that went away recently.  Clarifying the error message would help, since then users would know what the problem was (I needed assistance from the folks in #calendar to figure it out).

But since the error is out-of-band (i.e. it happens to a background process the user isn't aware of), it's distracting and annoying to get a dialog box about it every time it happens.

Instead of putting it into that dialog, I suggest doing two things:

1. The first time the error occurs, drop down a notification bar (a la Firefox's notification bars) about the problem.  In the bar, mention that events from the calendar won't show up until the problem is corrected.

2. Until the calendar works again, display it in the Calendars box differently.  Highlight it with a light red background color, add an exclamation point icon to its listing (with a tooltip that explains why it's there), and/or do other things to make it clear to the user that there's something wrong with the calendar.
Duplicate of this bug: 375267
A patch to this bug should generally make it easier to display errors in the calendar creation dialog, and find a mechanism for smoothly handling the asynchronous actions needed here. This is also needed for bug 346540.

Christian, do you have some ideas for the UI here?
Blocks: 346540
Duplicate of this bug: 442025
Duplicate of this bug: 473364
Whiteboard: [error handling]
Duplicate of this bug: 325167
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.18pre) Gecko/20080917 Sunbird/0.9

This seems to happen if the file can't be read (i. e. because another program still is busy with generating it).

Error: [Exception... "Component returned failure code: 0x804a0100 [calIICSService.parseICS]"  nsresult: "0x804a0100 (<unknown>)"  location: "JS frame :: file:///F:/Software/Buero/Kalender/Sunbird/0.9-Branch/stable/components/calItemModule.js -> file:///F:/Software/Buero/Kalender/Sunbird/0.9-Branch/stable/js/calIcsParser.js :: ip_parseString :: line 58"  data: no]
Source File: file:///F:/Software/Buero/Kalender/Sunbird/0.9-Branch/stable/components/calItemModule.js -> file:///F:/Software/Buero/Kalender/Sunbird/0.9-Branch/stable/js/calIcsParser.js
Line: 58
Flags: blocking-calendar1.0+
Whiteboard: [error handling] → [not needed beta][has l10n impact][error handling]
We have an error bar, now we just need to handle the async stuff. Possibly we could add a method to calICalendar or calICalendarProvider that instructs the provider to check if the url is a valid calendar.

For ics this means sending a HEAD query to see if it has type text/calendar, for caldav it might mean detecting the right url and then changing it in the dialog.
This bug might be fixed by Lenni's new calendar wizard. Assigning to him so this bug isn't forgotten.
Assignee: nobody → Lennart.Bublies
An extension of Lennarts work can be found in bug #378873.
1. The first time the error occurs, drop down a notification bar (a la Firefox's notification bars) about the problem.  In the bar, mention that events from the calendar won't show up until the problem is corrected.

2. Until the calendar works again, display it in the Calendars box differently.  Highlight it with a light red background color, add an exclamation point icon to its listing (with a tooltip that explains why it's there), and/or do other things to make it clear to the user that there's something wrong with the calendar.
Whiteboard: [not needed beta][has l10n impact][error handling] → [not needed beta][has l10n impact]
You need to log in before you can comment on or make changes to this bug.