The webcal protocol should be registered with the OS, so that the OS knows sunbird can handle webcal:// like urls.
Not going to make the 0.5 train.
Target Milestone: Sunbird 0.5 → ---
The "webcals" scheme should also be registered (i.e., for HTTPS) as currently does Microsoft Outlook 2007.
Should already work for Mac, but Gnome and Windows don't afaik.
No longer depends on: 281398
Summary: webcal protocol not registered with the OS → webcal protocol not registered with the OS (Gnome, Windows)
Version: Trunk → unspecified
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.
I thought lilmatt implemented registering Sunbird for webcal url and ics file on Mac that in bug 358110.
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.
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.
Assignee: nobody → philipp
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...
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.)
Priority: -- → P2
Picking up work again
Status: NEW → ASSIGNED
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?
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.
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.
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.
(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.
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/>.
mcsmurf (Frank Wein) has been doing the (Winodws) shellservice work on SeaMonkey so far, he probably knows things best from our POV.
Uploading my current snapshot for backup and display purposes. This is not guaranteed to apply or work.
Component: Internal Components → OS Integration
QA Contact: base → os-integration
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.
Assignee: philipp → nobody
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
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.
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.
You need to log in before you can comment on or make changes to this bug.