263214 - Reconsider default-browser selection mechanism for GNOME

Status: NEW

(Firefox :: Shell Integration, defect)

Description

[Christopher Aillon (sabbatical, not receiving bugmail)]

Well.  I hate to be the guy to ask to remove a feature which has obviously had a
fair amount of time spent on its implementation, but that is precisely what I am
doing.

GNOME integration is good.  We should strive to do it.  But that means following
how GNOME applications act, not making Mozilla use GNOME APIs to do what the
Windows version of Mozilla does.  With this "feature" (see bug 242254), Firefox
is the only application that personally asks to be the default application for
any task under GNOME or Linux.

On top of that, the way this handles the default browser is both wrong and
inconsistent with the way the Default Applications dialog in
gnome-control-center works.  This leads to interesting situations of clicking on
the "Web browser" icon and getting Epiphany as the launched browser.  Not good.

For the record, I am going to be removing this from our FC3 RPMs.  It would be
good to get mozilla.org buy-in here.

However, if it is important for you to set the default browser from within the
application, the way it should happen is to launch
gnome-default-applications-properties and have that take care of it for you. 
Though applications popping up default browser dialogs is very much a
windows-ism and reminiscent of the Netscape vs. IE battle, and it would be a
Good Thing(tm) IMO to not resurface that.

Comment 1

[Mike Shaver (:shaver emeritus)]

nsIShellService method implementation is separate from the issue of whether we
should prompt the user at startup.  Resummarizing the bug to address the
reported problem, not the knee-jerk overkill solution.

The GNOME HIG recommends:

"It is important for users to be able to double-click on documents they see on
the desktop, such as files and email messages, and have them launch in their
favorite application. Therefore, your GNOME application should associate itself
at install-time with all the document types it can handle."

(http://developer.gnome.org/projects/gup/hig/draft_hig_new/desktop-mimedatabase.html)

Why is the installation of Firefox as a default browser not analogous to this? 
Should we just not prompt, and instead do it at startup?  We didn't want to do
that because we didn't think that's what users would want, and we don't always
have an "install-time" hook to run.  (We distribute as tarballs, as nobody has
offered to maintain spec/dpkg files in our source tree.)

Could you detail the inconsistency?  When I click my "Web Browser" icon, I get
Firefox.  Is there an API for doing it better?  (Which works with more than just
the most recent GNOME, natch.)  Does launching
gnome-default-application-properties work in all versions of GNOME with which
the current approach does?  (How does it find the list of available browsers? 
Wouldn't we still need nsIShellService to add gconf keys or some such to make
ourselves part of that list?)

We are not part of the GNOME Desktop(tm), as I'm told routinely on
#gnome-hackers, so we will sometimes have to do things that official GNOME apps
don't.  (Like support running from arbitrary prefixes in a self-contained way.)

I would be against having the removal of the nsIShellService patch happen with
an officially-branded package, but I'm not the one who gets to make that
decision.  This development was done with, and to the resounding approval of, a
heavy GNOME distributor, and this is the first we've heard of complaints.  I'd
like to see a more inclusive discussion before we resort to tearing the code out
wholesale. Cc:ing some people who should be in on it.

Comment 2

[Mike Shaver (:shaver emeritus)]

Also:

- there's a pref that distributors can use to suppress the ask-at-startup
behaviour, if it doesn't fit with the context in which they package firefox. 
Does that not meet your needs?

- extension authors have expressed interest in having scriptable interfaces to
the gconf services from that patch, and I don't see why we would choose to tear
out the implementation rather than setting the pref or (less likely) disabling
the check in the front end logic.

Comment 3

[Christopher Aillon (sabbatical, not receiving bugmail)]

I'll post my take here.  Perhaps jrb can add to this, or correct me if I got
anything wrong.

(In reply to comment #1)
> The GNOME HIG recommends:
> 
> "It is important for users to be able to double-click on documents they see on
> the desktop, such as files and email messages, and have them launch in their
> favorite application. Therefore, your GNOME application should associate itself
> at install-time with all the document types it can handle."
> 
>
(http://developer.gnome.org/projects/gup/hig/draft_hig_new/desktop-mimedatabase.html)
> 
> Why is the installation of Firefox as a default browser not analogous to this?

A few reasons.  One you are registering yourself with the schemes you handle,
not the document types.  Two, I believe you are misinterpreting "register
document types you can handle" with "register the app as the default application
to handle said document types".  This refers to the new shared mime database
using the shared-mime-info spec over at freedesktop.org.

 
> Should we just not prompt, and instead do it at startup?  We didn't want to do
> that because we didn't think that's what users would want, and we don't always
> have an "install-time" hook to run.  (We distribute as tarballs, as nobody has
> offered to maintain spec/dpkg files in our source tree.)

Um, whatever happened to the xpinstallers?

> Is there an API for doing it better?  (Which works with more than just
> the most recent GNOME, natch.)  Does launching
> gnome-default-application-properties work in all versions of GNOME with which
> the current approach does?  (How does it find the list of available browsers? 
> Wouldn't we still need nsIShellService to add gconf keys or some such to make
> ourselves part of that list?)

I don't know of any API that works across the board as you want.  Maybe someone
else does.  In the current world, I'd say using the shared-mime-info spec to
register your app with the mime types and then popping up
gnome-default-applications-properties is the way to go.  The list of browsers is
coded into control-center itself.


> We are not part of the GNOME Desktop(tm), as I'm told routinely on
> #gnome-hackers, so we will sometimes have to do things that official GNOME apps
> don't.  (Like support running from arbitrary prefixes in a self-contained way.)

Fair enough.  It would be nice to not conflict with GNOME though when possible.


> I would be against having the removal of the nsIShellService patch happen with
> an officially-branded package, but I'm not the one who gets to make that
> decision.  This development was done with, and to the resounding approval of, a
> heavy GNOME distributor, and this is the first we've heard of complaints.  I'd
> like to see a more inclusive discussion before we resort to tearing the code out
> wholesale. Cc:ing some people who should be in on it.

Fair enough.  I suppose the background image stuff can stay.



(In reply to comment #2)
> Also:
> 
> - there's a pref that distributors can use to suppress the ask-at-startup
> behaviour, if it doesn't fit with the context in which they package firefox. 
> Does that not meet your needs?

It could I guess if we can lock the pref.  I am unsure about how to do things
like that without the CCK and am not even sure it works with Firefox.  Maybe
someone else would know.  This is something that I don't want my users to be
able to turn on themselves.  Though honestly, I don't even want a random
extension doing the same thing you are doing, so I'd prefer to get rid of the
backend code.


> - extension authors have expressed interest in having scriptable interfaces to
> the gconf services from that patch, and I don't see why we would choose to tear
> out the implementation rather than setting the pref or (less likely) disabling
> the check in the front end logic.

nsIGConfService is different from nsIShellService.  I didn't realize they were
implemented in the same patch.  I should have left the summary at the
nsIShellService thing.  Though I am slightly confused as to why we are providing
very platform specific APIs to the XUL platform which is cross-platform (and yes
I know we provide winreg hooks).  Who wants to use gconf (and for what purpose)?

Comment 4

[Mike Shaver (:shaver emeritus)]

> A few reasons.  One you are registering yourself with the schemes you handle,
> not the document types.  Two, I believe you are misinterpreting "register
> document types you can handle" with "register the app as the default application
> to handle said document types".  This refers to the new shared mime database
> using the shared-mime-info spec over at freedesktop.org.

"new shared mime database" stuff doesn't solve this problem for us; we need to
support more than GNOME 2.8 (even once it ships widely).

I could find no examples of registering protocols, and I think bryner couldn't
either, and I wasn't able to find examples in Epiphany in my scan, so this was
the best path forward that we could deduce.  (And user feedback has been quite
good.)

> > (We distribute as tarballs, as nobody has
> > offered to maintain spec/dpkg files in our source tree.)
> 
> Um, whatever happened to the xpinstallers?

They're not always used.  They're not even the dominant download, IIRC.

> I don't know of any API that works across the board as you want.  Maybe someone
> else does.  In the current world, I'd say using the shared-mime-info spec to
> register your app with the mime types and then popping up
> gnome-default-applications-properties is the way to go.  The list of browsers is
> coded into control-center itself.

So how do we get firefox into the control-center for 2.6 and 2.4?

> > We are not part of the GNOME Desktop(tm), as I'm told routinely on
> > #gnome-hackers, so we will sometimes have to do things that official GNOME apps
> > don't.  (Like support running from arbitrary prefixes in a self-contained way.)
> 
> Fair enough.  It would be nice to not conflict with GNOME though when possible.

Where GNOME provides an appropriate way for us to do this sort of thing -- not
requiring a change to control-center to add another candidate browser, and an
API to invoke that and find out when the user has closed it, etc. -- I'm in
total agreement.  I don't see how it's possible for us to do that in a
cross-GNOME way right now, but even so I'd be happy to take a patch that did the
GNOME 2.8-correct thing when we could tell that it would work.  I'm not happy to
only work with 2.8, though.

> (In reply to comment #2)
> > Also:
> > 
> > - there's a pref that distributors can use to suppress the ask-at-startup
> > behaviour, if it doesn't fit with the context in which they package firefox. 
> > Does that not meet your needs?
>
> This is something that I don't want my users to be able to turn on themselves.

Why not?  If that's what a user wants, why would you not let them make that
choice?  Do you want to drive them away from your packaging?  They can change
all sorts of things about Firefox that make it less GNOMEy, the most obvious
being installing a new theme.

Given that there are obviously no other prefs you lock this way, or you'd know
if it worked, I'm led to ask: why is this specific pref such a big deal?  I'd
have expected distributors to want to die on the hill of app.update, maybe, but
not this.

> Though honestly, I don't even want a random
> extension doing the same thing you are doing, so I'd prefer to get rid of the
> backend code.

You can't keep a random extension from doing it, though, and I suspect you know
it.  They can just call gconf-editor with the right args, if they want.

> Though I am slightly confused as to why we are providing
> very platform specific APIs to the XUL platform which is cross-platform (and yes
> I know we provide winreg hooks).

The bug you want to back out discusses this to some degree, so I won't retread
the ground about this interface's specificity, but there's nothing un-XUL about
providing APIs for platform-specific integration.  The balance between
cross-platform development and the ability to integrate well into a given
platform is a big part of what we want to improve about the Mozilla platform. 
The winreg extensions are well-used to find external-app info for good
integration, platform settings, etc., and people want to do the same with gconf.
 gconf is "how you find and store settings about the GNOME platform", according
the the gospel I've read, and people who want to write GNOME-friendly extensions
are asking for that sort of access.  (Don't we _want_ extension authors, like
the Calendar extension, say, to be able to write more GNOMEy application
features?  I sure do, for GNOME and for Windows alike.)

That's why I don't want the patch backed out -- it would make "firefox 1.0 as
shipped by Red Hat" a different platform from "firefox 1.0 as distributed by
Mozilla Foundation" in what I think is a non-trivial way.

Comment 5

[Luis Villa]

(In reply to comment #4)
> > (In reply to comment #2)
> > > Also:
> > > 
> > > - there's a pref that distributors can use to suppress the ask-at-startup
> > > behaviour, if it doesn't fit with the context in which they package firefox. 
> > > Does that not meet your needs?
> >
> > This is something that I don't want my users to be able to turn on themselves.
> 
> Why not?  If that's what a user wants, why would you not let them make that
> choice?  Do you want to drive them away from your packaging? 

The general gnome philosophy suggests that most users really don't care about
this kind of thing. And more generically, we need to be able to lock things
down- that's a requirement for any enterprise app. 

> Given that there are obviously no other prefs you lock this way, or you'd know
> if it worked, I'm led to ask: why is this specific pref such a big deal?  I'd
> have expected distributors to want to die on the hill of app.update, maybe, but
> not this.

Can't speak to RH's motivation here; I personally don't care because we just set
things up such that if Firefox is installed, it is the default, period.
 
> > Though honestly, I don't even want a random
> > extension doing the same thing you are doing, so I'd prefer to get rid of the
> > backend code.
> 
> You can't keep a random extension from doing it, though, and I suspect you know
> it.  They can just call gconf-editor with the right args, if they want.

That's not strictly true; gconf keys can be locked system-wide. Is this possible
with firefox settings? (Honestly don't know.)

> > Though I am slightly confused as to why we are providing
> > very platform specific APIs to the XUL platform which is cross-platform (and yes
> > I know we provide winreg hooks).
> 
> The bug you want to back out discusses this to some degree, so I won't retread
> the ground about this interface's specificity, but there's nothing un-XUL about
> providing APIs for platform-specific integration.  The balance between
> cross-platform development and the ability to integrate well into a given
> platform is a big part of what we want to improve about the Mozilla platform. 
> The winreg extensions are well-used to find external-app info for good
> integration, platform settings, etc., and people want to do the same with gconf.
>  gconf is "how you find and store settings about the GNOME platform", according
> the the gospel I've read, and people who want to write GNOME-friendly extensions
> are asking for that sort of access.  (Don't we _want_ extension authors, like
> the Calendar extension, say, to be able to write more GNOMEy application
> features?  I sure do, for GNOME and for Windows alike.)

I strongly agree here; moz must be able to read from and write to gconf for good
integration- to read/share proxy settings, for example, or eventually to do good
printing integration. I'm honestly very surprised anyone from RH is advocating
ripping this out.

> That's why I don't want the patch backed out -- it would make "firefox 1.0 as
> shipped by Red Hat" a different platform from "firefox 1.0 as distributed by
> Mozilla Foundation" in what I think is a non-trivial way.

That flexibility is a feature of free/open software, not a bug. The sooner
moz.org groks that the better for everyone.

Comment 6

[Mike Shaver (:shaver emeritus)]

> The general gnome philosophy suggests that most users really don't care about
> this kind of thing. And more generically, we need to be able to lock things
> down- that's a requirement for any enterprise app. 

Lock down against what?  If the user can't modify their home directory, they
can't alter firefox behaviour.  If they can modify their home directory, they
can add extensions which arbitrarily alter the app.  I suspect that GNOME isn't
very different.

> Can't speak to RH's motivation here; I personally don't care because we just set
> things up such that if Firefox is installed, it is the default, period.

Does it periodically re-assert itself, at package update/install-time, or some such?

> > You can't keep a random extension from doing it, though, and I suspect you know
> > it.  They can just call gconf-editor with the right args, if they want.
> 
> That's not strictly true; gconf keys can be locked system-wide. Is this possible
> with firefox settings? (Honestly don't know.)

Sure, but if you lock the gconf key then this behaviour has no effect regardless
of how the extension does it.

You can lock firefox prefs via mozilla.cfg, if you want.  It's as "locked-down"
as gconf stuff is, AIUI, in that it relies on software that runs as the user.

> > That's why I don't want the patch backed out -- it would make "firefox 1.0
> > as
> > shipped by Red Hat" a different platform from "firefox 1.0 as distributed by
> > Mozilla Foundation" in what I think is a non-trivial way.
> 
> That flexibility is a feature of free/open software, not a bug. The sooner
> moz.org groks that the better for everyone.

Oh, they're free to do that, and I would defend to the death their right to,
both morally and legally.  But I don't have to like it, and it diminishes the
value of the Firefox name as a platform, which is why we have trademark rules. 
We take our platform integrity (increasingly) seriously, and I'm sure the GNOME
Foundation would be upset if someone shipped "GNOME 2.8" with a
notification-area-less panel or didn't use the fd.o mime-info stuff; I don't
want ISVs to have to say "get your Firefox from Mozilla, not from your vendor",
but I don't think they'll hesitate to go there if the platform diverges.

Thanks for your feedback here.

Comment 7

[Christopher Aillon (sabbatical, not receiving bugmail)]

First, bear in mind that I am a huge proponent of Firefox and Thunderbird. 
Unsure if that's been forgotten in the scuffle.

(In reply to comment #4)
> (And user feedback has been quite good.)

User feedback on Epiphany features from Epiphany users has been quite good, too.
  The Firefox camp would argue from "no its not" to "but it is better with
Firefox."  I would argue that is a similar case here.  Firefox users may like it
because they don't know better, or because they are used to this sort of thing
from the Windows side of things.  That doesn't make the feature itself good
within the GNOME context.


> > Um, whatever happened to the xpinstallers?
> 
> They're not always used.  They're not even the dominant download, IIRC.

That surprises me somewhat given the main product page
<http://www.mozilla.org/products/firefox/> only links to the installer.  Would
it not behoove mozilla.org to exclusively offer installer-based builds in some
way shape or form (RPM, xpinstall, whatever) for their binary packages if there
is a benefit to doing so (install time registration of things)?  That's one of
the reasons there is no Windows tarball right?


> So how do we get firefox into the control-center for 2.6 and 2.4?

Same way stuff gets into Mozilla 1.4.  Write a patch against the right branches.
 I can't guarantee all distributors will pick that up, though which is probably
what you really want.  :-(


> Where GNOME provides an appropriate way for us to do this sort of thing -- not
> requiring a change to control-center to add another candidate browser, and an
> API to invoke that and find out when the user has closed it, etc. -- I'm in
> total agreement.  I don't see how it's possible for us to do that in a
> cross-GNOME way right now, but even so I'd be happy to take a patch that did the
> GNOME 2.8-correct thing when we could tell that it would work.  I'm not happy to
> only work with 2.8, though.


Are you happy to not work with GNOME 2.8?  Older GNOMEs have mechanisms to
select the default browser, as you know I'm sure.  Such is the case with new
GNOME 2.8.  Would it not be better to educate users how to do that in all
versions rather than pop up a dialog and attempt to do it in a way which only
works in some versions and not in others?



> > > - there's a pref that distributors can use to suppress the ask-at-startup
> > > behaviour, if it doesn't fit with the context in which they package firefox. 
> > > Does that not meet your needs?
> >
> > This is something that I don't want my users to be able to turn on themselves.
> 
> Why not? 

In addition to Luis's response, because we already have a way of setting up the
default browser.  Yours differs and intrudes on the user experience we are
trying to offer.  See also next paragraph.


> If that's what a user wants, why would you not let them make that
> choice?  Do you want to drive them away from your packaging?


I would love for everyone to make the choice of Firefox.  I just feel that the
user should say "I want to switch my default browser to XYZ" and use the system
way of doing it (control-center) rather than have browsers intrude on your
browsing experience like a street beggar asking for change or a telemarketer
asking if you want to switch to Capital One during dinner.  Users launch the
browser to surf the web, not make decisions about their default, potentially
before they even have a chance to fully experience the software you are asking
them to decide about.  When they are ready to switch for good, we definitely let
them.

> They can change
> all sorts of things about Firefox that make it less GNOMEy, the most obvious
> being installing a new theme.

Actually, installing a new theme
<http://linuxart.com/log/archives/2004/09/20/industrial-for-firefox/> can make
it look more GNOMEy.  Gnomestripe really isn't that GNOMEy to be honest....


(In reply to comment #5)
> I'm honestly very surprised anyone from RH is advocating ripping this out.

I already mentioned in comment #3 that I didn't intend to rip out the GConf
stuff.  I was sort of surprised though because I thought one of the Mozilla
Foundation's stances were that we should strive for cross-platformness, and not
diverge the XUL platform.


Anyway, of note, one of the beefs I have is that the default browser registers
its path as an absolute path rather than as a simple binary name.  E.g. you
should register "firefox %s" rather than "/usr/lib/firefox-0.9.3/firefox %s" or
"/home/caillon/firefox/firefox %s" (using an m.o tarball) because that will
cause GNOME to prompt you every time the directory changes telling you your
default browser has been uninstalled.  This is a very real situation since we
change locations every version update.  It is also what control-center does, so
here is one way you can make the feature not suck as much.

Comment 8

[Mike Shaver (:shaver emeritus)]

I do want to work with GNOME 2.8, and I already said I would support patches
that made us work better with GNOME 2.8.  I apologize if I wasn't clear enough.
   If you're proposing an alternate way for the application to register, that's
fine, but that's not what I understood to be your point, from the bug you filed,
and your comments in IRC.  You were hellbent on ripping it all out, instead of
presenting specifically better ways to achieve the same registration given that
we're _not_ always distributed by the vendor, and we're _not_ always installed
via a packaging system that's stored in the Mozilla CVS tree.

> I just feel that the
> user should say "I want to switch my default browser to XYZ" and use the system
> way of doing it (control-center) rather than have browsers intrude on your
> browsing experience like a street beggar asking for change or a telemarketer
> asking if you want to switch to Capital One during dinner.

The user does say that.  We ask _once_, unless the user tells us that they want
to be checked every time.  And anyway, I started this discussion by asking about
the pref to suppress the default behaviour of having firefox pee in your cereal
and then steal your DVD collection.  If that's the objection, then just set the
pref in your distribution and be done.  Why doesn't that work?  (As a side note,
gconf-editor also pops a similar dialog up, intruding on my configuration
experience, at least in 2.6.  Did you want to unilaterally back that patch out?)

I'm sure Epiphany users are happy with Epiphany.  I don't try to tell Epiphany
that it needs to support Firefox extensions, or our live bookmark format, or
fastfind, and I'm not sure what your argument is here, or why you think it's
productive to speculate on why Firefox users like Firefox.  If Firefox were
Epiphany, then only Epiphany users would like Epiphany, right?

There are lots of theme choices people can make; I wish we'd had help from a
full-time graphic designer on GNOMEStripe as well, which might have let us
produce a more GNOMEy thing.  Again, nobody from the GNOME community seemed
interested in that, and even today nobody's sending us patches.  (Though we did
offer to import industrial into Mozilla CVS, to no answer.)

But what does that have to do with my core point, which you quote?  Users can do
lots of things to their Firefox that make it less (or more) like GNOME.  If they
go out of their way to turn that pref on, because they _want_ it to pop up every
time due to the way they switch between browsers or a chemical imbalance or that
they're "used to Windows", why not?

Using the explicit pathname is something we go to considerable lengths to do,
because it means that users don't have to alter their $PATH when they stick it
in, f.e., ~/firefox.  We have a self-extracting installer thing that bryner did
which works very well, and has one of the best installation experiences I've had
on a Linux desktop in quite a while.  I can see why that would cause some pain
for inter-version upgrades, though; can you think of a way we can do both?  I
would be fine with an environment variable or even pref to toggle that
behaviour, given how close we are to the shipping deadline.

When it comes to the installer-vs-tarball thing, I'm clearly a liar.  The
installer does outnumber the tarball in the numbers I see here, though the
numbers are _extremely_ small for the tarball.

Maybe this is something we should do in the installer, then?

Can you point me at something that talks about how apps should register for
control-center management and ask to be the default browser?  I don't actually
know how older GNOMEs provide for that; I thought poking at gconf keys was the
way to control those things, since I didn't see an API in the docs that seemed
to fit better.  I tried to find some media players that would do that, etc., but
generally it seemed to be that a) there was only one such app in The GNOME Tent
for a given application space, and b) it assumed it was default already, and
would be provided for in some other part of GNOME, possibly default packaging.

(I'm pretty disappointed that this bug was filed as it was, instead of as two
bugs about what you described in IRC: 

< caillon> shaver, the big complaints are that the backend impl is wrong and its
inconsistent with the gnome platform (no other app asks that)

Those two bugs ("use GNOME-standard mechanism for registering as default
browser" and "GNOME: don't prompt at startup for default-browser registration")
would have been more productive ways to address the complaint, instead of
declaring that you were going to back the patch out, playing the "you're being
like Windows!" card, etc.

In my opinion, anyway.)

Comment 9

[timeless]

> That's one of the reasons there is no Windows tarball right?

we have a .zip version of the windows builds, we've had it forever and i've been
using it for years (still do when i visit other places, unless i have time to
waste filing 5 bugs on the installer + cleaning up after whatever messes it makes).