Closed Bug 668474 Opened 9 years ago Closed 9 years ago

Remote calendar with webcal:// location not working


(Calendar :: General, defect)

Lightning 1.0b4
Not set


(Not tracked)



(Reporter: code, Assigned: Fallen)




(Keywords: regression, Whiteboard: [needed beta][no l10n impact][gs])


(1 file)

My system: 
OSX 1.6.7 Intel Core 2 Duo
Thunderbird 5.0

After updating from TB 3.1.11 to 5.0, I notice that one of my calendars is provoking a popup window, asking me what to do with the webcal protocol. Of all my remote calendars, it's the only one that uses a location of the type webcal:// 

I tried to change the URL of that calendar to use http:// instead of webcal, but notice that the Location cannot be changed in the Properties window.

I then re-create this calendar with - this works as expected, the content is shown.

For the sake of testing, I re-create a remote calendar with webcal:// - it immediately gives me the popup window. I now set Thunderbird as default application for the webcal protocol, and see what happens: I don't see the popup window anymore, but the calendar does not show any content.
Product: Thunderbird → Calendar
QA Contact: general → general
Version: 5.0 → unspecified
Could you open the advanced config editor (Options > Advanced > General > Config Editor) and set the following preference (it will likely not exist):

network.protocol-handler.external.webcal = false

and then try again? webcal is not a real protocol, so it kind of shadows http, but its often seen in the wild so we should handle it.

Could you also check your error console for any error messages?
Version: unspecified → Lightning 1.0b4
I added this entry in the advanced configs (indeed it didn't exist yet).

After reboot of Thunderbird, and creation of a new calendar with webcal://, the behaviour does not change : the events of that calendar are not loading.

I don't get any messages from Thunderbird in the console while doing those actions.

Btw, I suppose that the intended use of webcal:// "in the wild" is to facilitate the subscription to a calendar, as opposed to saving/donwloading the .ics file (that's the default behavior on MacOSX: the link with webcal:// will suggest subscription to the calendar over the network, the same link with http:// will download the file, and add the events to the calendar upon opening the file).
I'm having the same problem with the new Thunderbird 5 and Lightning 1.0beta4. I have a remote calendar with a webcal protocol, and every time said calendar refreshes, I now get a popup asking me what to open the webcal URL with. Running on MacOSX 10.6 too.

The webcal link was taken from Facebook, btw. (Calendar of Facebook events.) So anyone with a Facebook account should be able to test this reasonably easily.

I tried adding the new setting suggested in comment 1, and saw no behavior change. There are no relevant error messages in the error console of Thunderbird.
Christian, change the calendar URL from webcal:// to http:// to make it working.
Just to make it explicit, this is a regression -- the webcal:// URLs worked fine before upgrading to TB 5.0 and Lightning 1.0b4.  I saw this bug also, upgrading to TB 5.0 on WinXP Pro SP3.

Here is the information from the dialog box that pops up:

  An error was encountered preparing the calendar located at webcal://[redacted] for use. It will not be available.

  Error code: 0x804b0012

  Description: [Exception... "Component returned failure code: 0x804b0012 (NS_ERROR_UNKNOWN_PROTOCOL) [nsIIOService2.newChannelFromURI]"  nsresult: "0x804b0012 (NS_ERROR_UNKNOWN_PROTOCOL)"  location: "JS frame :: file:///C:/Documents%20and%20Settings/Joe/Application%20Data/Thunderbird/Profiles/6xp09u7u.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calICSCalendar.js :: <TOP_LEVEL> :: line 150"  data: no]
Yes, agreed. I believe Stefan was just trying to give you an alternative until we fix this bug.
Ever confirmed: true
Keywords: regression
Duplicate of this bug: 669255
Flags: blocking-calendar1.0+
Whiteboard: [needed beta][no l10n impact]
Whiteboard: [needed beta][no l10n impact] → [needed beta][no l10n impact][gs]
Attached patch Fix - v1 β€” β€” Splinter Review
This patch takes care, we just had differeing id's in the manifest. Test included, but don't worry about checking if it really works. That can happen when fixing the unit tests.
Assignee: nobody → philipp
Attachment #544514 - Flags: review?(matthew.mecca)
Comment on attachment 544514 [details] [diff] [review]
Fix - v1

Looks good! r=mschroeder
Attachment #544514 - Flags: review?(matthew.mecca) → review+
Pushed to comm-central <>
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Trunk
Backported to comm-miramar <>
Target Milestone: Trunk → 1.0b5
Duplicate of this bug: 671244
Duplicate of this bug: 672021
Duplicate of this bug: 673401
Duplicate of this bug: 674031
You need to log in before you can comment on or make changes to this bug.