352566 - webcal protocol not registered with the OS (Gnome, Windows)

Status: RESOLVED FIXED

(Calendar :: Internal Components, defect)

Description

[Michiel van Leeuwen (email: mvl+moz@)]

The webcal protocol should be registered with the OS, so that the OS knows sunbird can handle webcal:// like urls.

Comment 1

[Matthew (lilmatt) Willis]

Not going to make the 0.5 train.

Comment 2

[Bernard Desruisseaux]

The "webcals" scheme should also be registered (i.e., for HTTPS) as currently does Microsoft Outlook 2007.

Comment 4

[Martin Schröder [:mschroeder]]

Should already work for Mac, but Gnome and Windows don't afaik.

Comment 5

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Why should this work for mac? From looking at thunderbird/firefox/prism code it seems like some extra bits are needed to register the protocol and we probably need ui to let the app check if its registered as a default for the protocol.

I'm thinking we should create an interface that may be worth submitting to core code, that allows registering arbitrary protocol handlers, unless this is already being taken care of in prism, see bug 434135.

Comment 6

[Martin Schröder [:mschroeder]]

I thought lilmatt implemented registering Sunbird for webcal url and ics file on Mac that in bug 358110.

Comment 7

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

I see, it does seem so. Unless there is another bug, We should also implement the "Sunbird is not your default calendar client" type dialog and add calendar to the thunderbird dialog.

I'm also not sure if the mac stuff only works on install, automatically enables this, or just gives the user the option to set it up himself. That should be checked.

Comment 8

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

I have some code to register protocols with the OS, currently implemented for gnome/gconf2, I'll be taking care (eventually...). If anyone wants to take over, feel free to write me an email.

Comment 9

[Dan Mosedale (:dmosedale, :dmose)]

Given how much calendar data comes from the web these days, we need this to ship Lightning with Thunderbird.  I suspect the information in bug 348450 and bug 304704 are likely to be relevant; adding philor for his thoughts...

Comment 10

[Phil Ringnalda (:philor)]

Interesting: did the bug 358110 code for Mac actually *work* for webcal:? I'd expect that with Sunbird already running, that would go through to where toolkit tries to look up the pref for browser.chromeURL and fails, assert, then try to load chrome://navigator/content/navigator.xul with the webcal URL as an argument. (Which I guess would work, if you don't mind the assertion and map that chrome URL to something that knows to look for webcal URLs as window.arguments.)

Comment 11

[David :Bienvenu]

marking p2

Comment 12

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Picking up work again

Comment 13

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

This is turning out to be much more complicated that I though. While url part is quite easy, the gnome mime api is changing and some functions (even those in use by nsIGnomeVFSService and such) are deprecated. I haven't succeeded in making the running app be the default for filetypes using the method firefox uses. I'm not even sure the code that firefox uses is even successful. Its highly possible that even that code actually fails and it just doesn't show since the respective distro takes care of associating the installed browser with html files.

Making it work requires using a bunch of gnome specific functions I haven't been able to fully test. Some should probably be abstracted into their own interfaces.

So, what should I do for integration? Just go with protocol integration and forget filetypes? Dig in more and do filetypes?

Comment 14

[Dan Mosedale (:dmosedale, :dmose)]

Ultimately, we need both, but it sounds like there are several different issues here with varying amounts of work.  Splitting this out into multiple chunks (I suspect multiple bugs) sounds like the right thing to me, as then we'll be able to manage the work such that we get (at least) all the low-hanging fruit.  I can help here some, as I spent lot of time in and around the exthandler code last year.

With regard to GNOME in particular, I kinda suspect we want to get away from GNOME specific APIs and replace them with the corresponding freedesktop.org API where such things exist, so that we get KDE support for free.  That said, we'll need to be careful about minimum version requirements.

I'd suggest starting off by just breaking down the work into pieces and putting an outline here in this bug.  Note that there are likely existing bugs in the Core: File Handling component that will be relevant here, you may be able to just mark them as blocking this one.

Generally speaking, if you have questions about relevant Gecko code, it's going to be easier to ask me, bz, or biesi (also maybe sdwilsh & dolske) rather than spending too much time banging your head against the code, because the code flow there is (currently) an evil twisted mess.

Comment 15

[Simon Paquet [:sipaq]]

Let me add to what dmose said, that IMO it would be a great thing all by itself to support Windows properly. If GNOME support is harder, that is bad for the few thousand GNOME users, but properly supporting Windows will reach hundreds of thousand users.

Comment 16

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

This is my plan. Points with ++ are things that should happen in this bug, -- in a different bug, * are facts and things to consider, + means more work that would be beneficial, - means work we can avoid.

If you prefer the short version (please consider reading the below though!), this bug will take care of url handlers (all platforms), initial frontend and filetype handlers for mac/windows, other bug(s?) will take care of filetype handlers for gnome/kde.

++Add Frontend code
  * Thunderbird, might need some bits to make the default client dialog more
    extension friendly. I have some code for that, who feels like discussing
    this with me?
  * Sunbird, needs a bit of work to get the UI into the right place. I'm
    planning on making the procedure to extend the default client dialog the
    same for both Sunbird and Thunderbird. Due to the nature of the projects
    and the way the directories are layed out in comm-central, I'll need to
    copy the dialogs. We might want to create a common dir for things that
    are used in calendar,thunderbird and also seamonkey.
  + The prefpane was reordered a bit recently, we need to take care of this for
    Sunbird too if we want to minimize extra glue code.
  - Although I doubt the backend makes sense by its own, we can probably split
    up coding the common shell service and coding the frontend code into
    multiple bugs.

++Implement being default handler for URL (this bug)
  * This should work quite well for windows/gnome/mac. I have code for gnome
    right now and some untested code for mac. Windows shouldn't be that hard
    to accomplish given Firefox has already done it.
  + I'm not quite sure about KDE. I can see if there an (implemented)
    freedesktop.org standard for protocol handlers though, otherwise I'll need
    to set up a VM for KDE and test things there (yuck!)
  * Since implementing in windows (and possibly mac) should be relatively
    straightforward, I think we should already define the interface as a
    whole and make the code thats not done in this bug just fail for 
    gnome/kde.

--Implement General mime and application menu handling code
  * This should be compatible to both GNOME and KDE (yay!). The file locations
    and format are based on freedesktop.org standards, so maybe even more
    window managers will work.
  + While text/calendar and certainly also Thunderbird types are part of the
    default mime database, I'd like to add code to generally allow defining
    mime types from the application.
  * creates an xml file in ~/.local/share/mime/packages or 
    /usr/share/mime/packages, depending on if it should be set for all users
    or not.
  * creates a ~/.local/share/applications/
    <vendor>-<product>-<major-version>.desktop that allows defining mime
    types. If this file exists, makes sure the paths are correct and the mime
    types are set correctly. This will also allow adding items to the 
    GNOME and KDE menu, if wanted.
  + Both files should ideally be copied over from dist/bin/<somewhere>, maybe
    dist/bin/defaults ? This needs some poking at people who know more about
    such locations. These files could also use some build system integration.
  - We could probably get away with just copying over those files instead of
    adding code to add/remove handled mime types.

--Move shell service code to toolkit
  + Unfortunately 1.9.1 is already quite far along the way so I doubt this
    part will make it into toolkit before 1.9.2, but I'm trying to write the
    code in a way that it can easily be used for other XUL applications.
    This means firefox can at some point just extend my nsIShellService with
    its extra bits from nsIBrowserShellService.
  * Until its possible to move the shell service into toolkit, I'll either
    need to put it in some shared directory (see above), or create a copy for
    both Sunbird and Thunderbird.

--Testcases
  * About testcases, its kind of hard to test the url handlers in xpcshell,
    since the code I have now needs a qualified XRE app and its vendor, at
    least for gnome. We might be able to emulate this in a certain manner
    though.
  * If we really want to test this thouroughly we would probably need
    per-platform C++ tests to check if setting the handler for the OS actually
    worked.

Comment 17

[Dan Mosedale (:dmosedale, :dmose)]

(In reply to comment #16)
> If you prefer the short version (please consider reading the below though!),
> this bug will take care of url handlers (all platforms), initial frontend and
> filetype handlers for mac/windows, other bug(s?) will take care of filetype
> handlers for gnome/kde.

In general, this seems like an entirely reasonable plan.

> ++Add Frontend code
>   * Thunderbird, might need some bits to make the default client dialog more
>     extension friendly. I have some code for that, who feels like discussing
>     this with me?

Are you referring to the dialog that asks whether Thunderbird should make itself the default handler for (eg) webcal:?  Or something else?   In any case, I suspect one or more of (philor, mkmelin, Standard8) are likely to have some thoughts here, so I've added them to the CC.

>   * Sunbird, needs a bit of work to get the UI into the right place. I'm
>     planning on making the procedure to extend the default client dialog the
>     same for both Sunbird and Thunderbird. Due to the nature of the projects
>     and the way the directories are layed out in comm-central, I'll need to
>     copy the dialogs. 

Sounds like something that can be lived with.

>     We might want to create a common dir for things that
>     are used in calendar,thunderbird and also seamonkey.

Sounds reasonable to me, maybe cc-toolkit?  Adding KaiRo & bienvenu to the CC for their thoughts.

>   - Although I doubt the backend makes sense by its own, we can probably split
>     up coding the common shell service and coding the frontend code into
>     multiple bugs.

Sure, it's entirely reasonable to use bugs as generic "units of work", regardless of whether they happen to stand on their own. 
 
> ++Implement being default handler for URL (this bug)
>   * This should work quite well for windows/gnome/mac. I have code for gnome
>     right now and some untested code for mac. Windows shouldn't be that hard
>     to accomplish given Firefox has already done it.

Sounds good.

>   + I'm not quite sure about KDE. I can see if there an (implemented)
>     freedesktop.org standard for protocol handlers though, otherwise I'll need
>     to set up a VM for KDE and test things there (yuck!)

So the main reason I brought up KDE is that if we can get KDE support for free by using freedesktop.org APIs, we should do that.  However, KDE is not currently a supported platform for Mozilla, in large part because there is noone who is signed up to own that code.  If doing KDE support is any extra work at all, I'd suggest just cutting that until such time as Mozilla has some sort of KDE story; we've already got far too much on our plates.

>   * Since implementing in windows (and possibly mac) should be relatively
>     straightforward, I think we should already define the interface as a
>     whole and make the code thats not done in this bug just fail for 
>     gnome/kde.

Sounds fine.

> --Implement General mime and application menu handling code

Rather than clutter this bug further, I suggest spinning off another bug, pasting this strategy there, and asking for comments there.  Please CC me, bzbarsky, and biesi.

> --Move shell service code to toolkit
>   + Unfortunately 1.9.1 is already quite far along the way so I doubt this
>     part will make it into toolkit before 1.9.2, but I'm trying to write the
>     code in a way that it can easily be used for other XUL applications.
>     This means firefox can at some point just extend my nsIShellService with
>     its extra bits from nsIBrowserShellService.
>   * Until its possible to move the shell service into toolkit, I'll either
>     need to put it in some shared directory (see above), or create a copy for
>     both Sunbird and Thunderbird.

Sounds reasonable.

> --Testcases
>   * About testcases, its kind of hard to test the url handlers in xpcshell,
>     since the code I have now needs a qualified XRE app and its vendor, at
>     least for gnome. We might be able to emulate this in a certain manner
>     though.
>   * If we really want to test this thouroughly we would probably need
>     per-platform C++ tests to check if setting the handler for the OS actually
>     worked.

Sounds right to me.  There's also the possibility of writing a test that would use the mock HTTP server to subscribe to a webcal: calendar, and then cause Lightning to export its representation of the ICS it has found.  As usual, I'd suggest doing the stuff that's straightforward immediately, and making a list of the other things that we'd like to test along with what sort of infrastructure changes we'd need in order to make them easily testable.

Comment 18

[Dan Mosedale (:dmosedale, :dmose)]

A couple more points:

* I'd suggest filing the bug about uplifting the shell service into Toolkit now in order to give the toolkit owners a chance to chime in.

* When doing protocol-handler hacking last year, I wrote a mochitest that verified some basic amount of application-launching functionality.  On the off chance that that turns out to be useful in some other style of test related to this code, or if we at some point get a mochitest-based framework for Thunderbird, that code lives at <http://mxr.mozilla.org/mozilla-central/source/uriloader/exthandler/tests/mochitest/>.

Comment 19

[Robert Kaiser]

mcsmurf (Frank Wein) has been doing the (Winodws) shellservice work on SeaMonkey so far, he probably knows things best from our POV.

Comment 20

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Attachment: WiP Patch - v1

Uploading my current snapshot for backup and display purposes. This is not guaranteed to apply or work.

Comment 22

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Marking this bug as a student-project. It includes C++ work, could possibly be split into different bugs with smaller workloads. A lot of discussion has happened above, but to give a summary, this bug needs:

* Shell service that is as general as possible (i.e could work for other XUL apps too) that works for gnome and windows.
** Windows might need a helper app to avoid giving the main app admin privs on vista and 7.
* Some XUL/js work to make sure the Thunderbird is also made the default app for calendar, if this is wanted by the user
* Possibly some XUL/js work to add the same prefs to Sunbird

Most points are discussed in detail in above comments.

Comment 23

[marcel]

How about "Open with..."* from the browser? Could this be part of this task or does it rather belong to Bug 357480 (I assume here)?

* or generally clicking a link to a resource which streams an .ics with Content-Type: text/calendar to the browser

Comment 24

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Another note about my previous comments on C++: We should avoid using a C++ component at all costs. Instead, consider using js-ctypes. I've put this bug up as an idea for the Google Summer of Code 2012, see <https://wiki.mozilla.org/Community:SummerOfCode12:Brainstorming> or the final page if appropriate.

Comment 25

[Roy Orbitson]

How is this not done after 12 years? Installing Thunderbird as your default email/calendar client, then having only Outlook (or worse, nothing) be able to subscribe to calendars is terrible UX.

Comment 26

[Ping Chen [:rnons] (away)]

Attachment: Bug 352566 - Support opening webcal and webcals url. r=mkmelin

Comment 27

[Roy Orbitson]

Don't forget webcals:.

Comment 28

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/af9eecb9bca9
Support opening webcal and webcals url. r=mkmelin

Comment 29

[Geoff Lankow (:darktrojan)]

I think this what's broken browser_icsAttachment.js on Mac, for example: https://treeherder.mozilla.org/logviewer?job_id=322350692&repo=comm-central&lineNumber=1991. Please take a look.

Comment 30

[Ping Chen [:rnons] (away)]

(In reply to Geoff Lankow (:darktrojan) from comment #29)

I think this what's broken browser_icsAttachment.js on Mac, for example: https://treeherder.mozilla.org/logviewer?job_id=322350692&repo=comm-central&lineNumber=1991. Please take a look.

Don't know how it happened, I tested just now on a local mac machine and it works.