279569 - want "Live Bookmarks" auto-discovery on pages with rel=alternate type=text/calendar

Status: RESOLVED WONTFIX

(Firefox :: General, defect)

Description

[Jamie Zawinski]

http://www.dnalounge.com/backstage/log/2005/01.html causes the "Live Bookmark"
icon to show up because it says

    <LINK REL="alternate" TYPE="application/rss+xml"
          TITLE="RSS" HREF="../latest.rss">

But http://www.dnalounge.com/calendar/2005/01.html says

    <LINK REL="alternate" TYPE="text/calendar" TITLE="iCal"
          HREF="webcal://www.dnalounge.com/calendar/dnalounge.ics">

and the Live Bookmark icon doesn't show up there.  I think it should!

I do happen to have both RSS and ICS versions of the calendar, but in my
experience, RSS of calendars just isn't very useful -- that's what ICS is for.

So it would be nice if you did auto-discovery of ICS files as well, handing the
"webcal" URL off to the calendar module so that the calendar could be subscribed
to more easily.

Comment 1

[Phil Ringnalda (:philor)]

Putting it in the Live Bookmarks discovery icon doesn't seem like a very good
idea to me - bad discovery (I already subscribe to your RSS, why would I ever
look in there again?) and useless code for people without the calendar
installed. Wouldn't it work just as well, while not impacting non-calendar
users, to have the calendar install a Firefox extension that adds another
calendar discovery statusbar icon? It's trivial to do that way, just add a
listener for DOMLinkAdded and they're handed to you on a silver platter.

Comment 2

[Jamie Zawinski]

> bad discovery (I already subscribe to your RSS, why would I ever
> look in there again?)

I don't understand what you mean.

Isn't the point of "auto-discovery" to discover alternate presentations of the
page you're looking at?  This is exactly such a thing.

Mozilla at least had the "More / Other Versions" menu on the Site Navigation
Bar; Firefox has (as far as I can tell) no way to present the various
non-navigation LINK REL types at all, except by reading the page source.

> and useless code for people without the calendar installed.

Useless code for people who don't use *any* calendar, perhaps.

I think this belongs in Firefox and not in the calendar because this should work
even if you don't use the Firefox calendar exension; for example, a Mac user who
uses Firefox and iCal; or a Linux user who uses Firefox and Evolution.  The
"webcal" URL should just be handed off to whatever calendar is configured.

Also, isn't Sunbird intended to function without any extensions for it being
installed in Firefox itself?

Having a different icon in the toolbar for RSS versus iCal doesn't matter to me,
but I think that REL="alternate" TYPE="text/calendar" should be presented to the
user in *some* GUI way.  It's just not there at all right now.

Comment 3

[Mike Connor [:mconnor]]

sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs, filter on "beltznerLovesGoats" to get rid of this mass change

Comment 4

[matthaeus123]

This really needs to be implemented into Firefox.

Comment 5

[Phil Ringnalda (:philor)]

(In reply to comment #4)
> This really needs to be implemented into Firefox.

Then you better get to work: you'll need a specification of what does and does not constitute a calendar link that should be discovered and how multiple links should be handled and what UI to use if you allow multiple links and what elements can create calendar links (see the WHATWG feed autodiscovery spec, plus Atom and RSS autodiscovery "specs"), you'll need to test the common calendar clients on the tier 1 platforms to see what they will or won't tolerate in the way of being handed URIs on the commandline, and how they go about making themselves the system default calendar client, and unless faaborg's already got you covered, you'll need an icon that represents calendars, and some UI approval on where to put it. Oh, and don't forget to expand navigator.registerContentHandler to let web apps add themselves.

Shame nobody did an extension two years ago, which would have built up all that needed knowledge through actual experience.

Comment 6

[Alex Faaborg [:faaborg] (Firefox UX)]

>unless faaborg's already got you covered, you'll need an icon
>that represents calendars, and some UI approval on where to put it.

We have a generic calendar icon, but we should go with the icon of the user's
calendar application since this will be more recognizable.  I'll be posting
information about the UI to my blog pretty soon.

Detecting links to .ics files will probably get wrapped into our overall
microformats strategy (assuming we decide to have one) for Firefox 3.

These posts introduce the overall idea:
http://blog.mozilla.com/faaborg/projects/

>Shame nobody did an extension two years ago, which would have built up all
>that needed knowledge through actual experience.

We are using the Operator extension to build up experience with microformats
and dealing with the various APIs of applications prior to integrating these
features directly into Firefox (again, assuming we decide to do that).

Comment 7

[matthaeus123]

Having Calendar integration should be important for the integration of Firefox to general desktop integration. Even if the user isn't using Sunbird they should be able to export feeds to what ever calendar program they want to use.

Comment 8

[Asa Dotzler [:asa]]

We're not investing further in live bookmarks.