264831 - Sunbird should not expose all protocols

Status: RESOLVED FIXED

(Calendar :: General, defect)

Description

[Daniel Veditz [:dveditz]]

While working on bug 263546 I found that sunbird defaults protocol handlers to
exposed. From bug 263546 comment 25

> yes, these prefs are wrong.  expose-all should default to false for
> all applications except browsers.  perhaps we should make that the
> default in all.js.  in fact, this should be
> 
> pref("network.protocol-handler.expose-all", false);
> pref("network.protocol-handler.expose.{some-calendar-protocol}", true);

The only protocol handler I found in a quick scan was webcal

Comment 1

[Daniel Veditz [:dveditz]]

Attachment: potential patch

Here's a potential patch, adding the whitelisting prefs you'll want after bug
263546 lands. Not sure if webcal is a scheme you click on in calendar or not;
if so you want exposed to be true.

Comment 2

[Justin Wood (:Callek)]

Comment on attachment 162431 [details] [diff] [review]
potential patch

personal nit:
The comment is now wrong above the
-pref("network.protocol-handler.expose-all", true);
+pref("network.protocol-handler.expose-all", false);

Comment 3

[Mostafa Hosseini]

What exactly does the network.protocol-handler.expose pref do?
Does it limit the app from using a network protocol or does it prevent the app
from handling the protocol?
In other words, with this patch:
Would it still be possible to handle http:// urls that point to a .ics file?
How about file:// and ftp:// ?
Altogether, sunbird wants to be able to handle .ics files that might be
available through different types of protocols, not just webcal:// and would
like to be able to handle those urls from both command-line and click events.
Would this patch interfere with this?

Comment 4

[Daniel Veditz [:dveditz]]

The expose pref does two different things, and I was recently complaining that
it was overloaded. Perhaps Calendar is the case that forces the split, just as
Thunderbird forced me to split the network.protocol-handler.external pref (added
a warn-external pref).

expose is used to tell XRemote that you are a handler for that type. Calendar
and Thunderbird should not advertise to the OS as default handlers for desktop
http: links.

expose is also used to direct link clicks to an external handler. Thunderbird,
for example, directs http: link clicks off to Firefox, but non-clicks (HTML in a
mail message) are still rendered inside the Thunderbird app.

If Sunbird doesn't need clickable links then the current expose features will
work for you; if users need to click on http links from somewhere then we'll
need to figure something out.

Comment 5

[Mostafa Hosseini]

I'm not quite getting it talking in general terms. I'll give examples of what
Sunbird would like to be able to do and we'll see if the current expose settings
will be enough.

1)Example 1: Would like to be able to accept and handle an http link to a
text/calendar (.ics) file. This link may be a clickable link in a webpage viewed
by firefox or a clickable link in an email viewed by thunderbird.Once the user
clicks on the link in those apps, sunbird would like to receive the url as an
argument.

2)Example 2: Would like to launch the default browser for viewing an http link
encountered in some calendar content. This link might be part of the description
for a calendar event or a url directly specified in a URL property.

Comment 6

[Daniel Veditz [:dveditz]]

For example 1) you want to register with the OS as a handler for that MIME type,
and let browsers call you up as a helper-app. For thunderbird and firefox in
particular you could perhaps get into their pre-populated mimeTypes.rdf,
although that only gets used by new profiles, not any existing users. This one
has nothing to do with the protocol/scheme-based prefs I've been talking about.

For example 2) you want the expose.http pref to be false. This is accomplished
by my patch (via the default expose value). You may want to uncomment the webcal
line if that's a protocol/scheme that will appear in clickable items. Leave it
alone if that's just an internal thing that wouldn't appear in user links.

Comment 7

[Mostafa Hosseini]

Sounds good then.
Patch checked in.
Comment removed.
webcal protocol expose uncommented.
Fixed in CVS.
Thanks

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=mozilla%2Fcalendar&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-10-19+06%3A50&maxdate=2004-10-19+06%3A55&cvsroot=%2Fcvsroot

Comment 8

[Simon Paquet [:sipaq]]

Mostafah, dveditz: 
Is this perhaps related to bug 258857 or is that bug a totally unrelated issue
in Sunbird?

Comment 9

[Daniel Veditz [:dveditz]]

This bug has to do with whether certain URI schemes are handled internal to the
program or run in an external application. For example, Sunbird and Thunderbird
want clicks on an http: link to open in Firefox rather than do it themselves.

Nothing to do with networking/ports.

Comment 10

[Reed Loden [:reed]]

The bugspam monkeys have been set free and are feeding on Calendar :: General. Be afraid for your sanity!