When chromium is the only browser installed, i'm still asked to make it the default

Bug #513133 reported by Mario Limonciello on 2010-01-27
48
This bug affects 8 people
Affects Status Importance Assigned to Milestone
Xdg-utils
Unknown
Medium
chromium-browser (Ubuntu)
Undecided
Unassigned

Bug Description

I removed firefox* and xulrunner* from my system before installing chromium.

When I launched it using:
$ x-www-browser

I still got a dialog asking me to make it the default browser.

ProblemType: Bug
Architecture: i386
Date: Wed Jan 27 02:53:26 2010
DistroRelease: Ubuntu 10.04
InstallationMedia: Mythbuntu 10.04 "Lucid Lynx" - Alpha i386 (20100125)
Package: chromium-browser 4.0.305.0~svn20100123r36929-0ubuntu1
ProcEnviron:
 LANG=en_US.utf8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.32-11.15-generic
SourcePackage: chromium-browser
Uname: Linux 2.6.32-11-generic i686

Mario Limonciello (superm1) wrote :
Michael Terry (mterry) wrote :

Just by way of explaining what it does now, not necessarily what needs to be done to fix this bug:

It calls xdg-settings (/usr/lib/chromium-browser/xdg-settings) to check if it's the default. In the GNOME environment, it will check /desktop/gnome/applications/browser, /desktop/gnome/url-handlers/http, and /desktop/gnome/url-handlers/https as well as call "xdg-mime query defaults text/html" which checks /usr/share/applications/defaults.list. So at least all 3 of those must be set correctly. And for the gconf keys, it must be the full path to the executable.

So I would argue that it should be querying /etc/alternatives/x-www-browser
first, and if it isn't set the default there, then fall back to the other
environment checks.

On Wed, Jan 27, 2010 at 09:59, Michael Terry <email address hidden>wrote:

> Just by way of explaining what it does now, not necessarily what needs
> to be done to fix this bug:
>
> It calls xdg-settings (/usr/lib/chromium-browser/xdg-settings) to check
> if it's the default. In the GNOME environment, it will check
> /desktop/gnome/applications/browser, /desktop/gnome/url-handlers/http,
> and /desktop/gnome/url-handlers/https as well as call "xdg-mime query
> defaults text/html" which checks /usr/share/applications/defaults.list.
> So at least all 3 of those must be set correctly. And for the gconf
> keys, it must be the full path to the executable.
>
> --
> When chromium is the only browser installed, i'm still asked to make it the
> default
> https://bugs.launchpad.net/bugs/513133
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Mario Limonciello
<email address hidden>
Sent from Austin, TX, United States

Michael Terry (mterry) wrote :

I suspect that Google is trying to cover all its bases (why it checks all the gconf keys *and* the xdg-mime value) so that no matter what goofy launch mechanism is used, chromium will come up. So they would likely accept a patch that checked/set alternatives as well as others if on a Debian system.

As for whether the Debian packaging would disable the other checks... I'm not sure. There is some value setting all those fields, since the world of 'what to launch' is complicated and many apps check different things.

One complication I'm noticing here is that when chromium actually does the check, it calls "which" and "readlink -f" on the command in its desktop file. This causes two bugs: You need to set the full path in the gconf fields, which is not normal or the default, and further, that it finds the 'chromium-browser' in /usr/lib/chromium-browser first (because PATH is prefixed with that dir by the /usr/bin wrapper) and thus the gconf values must actually match /usr/lib/chromium-browser/chromium-browser.

We should probably patch xdg-settings to at least not call which/readlink.

Michael Terry (mterry) wrote :

Or safer, call basename on it for the _gnome() functions, I'm not sure if other environments (kde, xfce4) expect full paths or not. But I know GNOME doesn't.

Michael Terry (mterry) wrote :

I suspect regarding the big warning that chromium is not the default, we probably want to disable it, as we disable Firefox's warning (which I recall we do, right?).

And/or disable the part of the options menu that lets user press a big button to make it default. If we leave it there, we probably want the attached patch to make xdg-settings a little more gnome-friendly.

Created an attachment (id=32875)
Use basenames for GNOME

In GNOME, it's more appropriate to use basenames for the various browser gconf keys.

Notice the behavior of the "Preferred Applications" app. It will set basenames, not full binary paths. Thus, xdg-settings is in a bit of conflict with that app (the canonical method of changing preferred apps in GNOME).

Using full paths can also result in a bit of oddity when, say, using Chromium and it calls xdg-settings after having modified its own PATH to point at /usr/lib/chromium-browser first. It ends up setting paths that avoid its wrapper script at /usr/bin.

I'm attaching a patch that fixes this for just GNOME. I'm not sure if other DEs would appreciate the change, so I'm making it narrow. (The patch was originally written for chromium's built-in version, so the diff src path probably isn't right, but the patch should apply.)

Alexander Sack (asac) wrote :

what defaults do we ship for the gconf keys in ubuntu?

e.g. for /desktop/gnome/applications/browser, /desktop/gnome/url-handlers/http, and /desktop/gnome/url-handlers/https ?

Michael Terry (mterry) wrote :

From /usr/share/gconf/defaults/10_libgnome2-common:
/desktop/gnome/applications/browser/exec firefox

From /usr/share/gconf/defaults/10_libgnomevfs2-common:
/desktop/gnome/url-handlers/http/command "firefox %s"
/desktop/gnome/url-handlers/https/command "firefox %s"

From /usr/share/applications/defaults.list:
text/html=firefox.desktop

For the patch itself, please make the change to xdg-settings.in as well.

The problem reported to Ubuntu mostly comes from the Chromium PPA being packaged funny:

1. As you mentioned, the package has /usr/lib/chromium-browser/chromium-browser and /usr/lib/chromium-browser, so there's confusion when the latter messes with PATH. Google Chrome doesn't have this problem, it's binary and wrapper scripts are /opt/google/chrome/chrome and /opt/google/chrome/google-chrome, respectively.

2. The chromium package's xml file in
/usr/share/gnome-control-center/default-apps uses the basename, but it uses xdg-settings, which sets the full path. This mismatch confuses Gnome's Preferred Applications. Google Chrome works fine with Preferred Applications because it use the full path in the xml file.

If the Chromium PPA fixed those two issues, then there shouldn't be a problem with using the full path with Gnome. As far as I can tell, Gnome doesn't have a technical limitation that says basename only. It's only done by convention.

The reason we used the full path is so Chromium developers can run a self built copy of Chromium, set that as the default browser, and have the desktop environment know to use it as the default browser rather than the installed package. While this isn't a common use case for most users, it's very helpful for developers.

Actually, it's not just developers who would want to set a non-packaged version of Chromium as the default browser. There also exist users who likes bleeding edge software and download chrome-linux.zip from Chromium's continuous build system.

Right now, one can just unzip chrome-linux.zip, run chrome-wrapper, and have the latest copy of Chromium and be able to set that as the default browser. This change will break that and make bleeding edge Chromium users set PATH to point to chrome-wrapper for it to work.

Alexander Sack (asac) wrote :

so yes. to ship chromium by default we need to change those default gconf entries too ... and then check if chromium-browser is happy about that.

Mario Limonciello (superm1) wrote :

So perhaps in all of those gconf keys would it be worthwhile investigating if firefox and chromium get along with setting them to x-www-browser?

That would mean no changes need to be made to allow switching between the two.

Michael Terry (mterry) wrote :

I threw my patch over the wall to xdg-utils upstream (which accepted the xdg-settings script from chromium). We'll see what they say about it, and if they like it, we can have chromium include an updated version.

Mario, the upstream version [1] does support looking at x-www-browser if not in GNOME, KDE, or XFCE4. Not quite what you were looking for, but it's a step. I'm not sure what you mean in comment 10. That we could rig GNOME to ignore its gconf keys in favor of x-www-browser? My understanding is that x-www-browser is a deprecated form of looking up the default browser (since each DE has its own way of setting it and exposing it to the user and none of them interact with x-www-browser). I guess that's what you want to fix, eh? :) Probably a different/bigger bug than this though.

[1] http://webcvs.freedesktop.org/portland/portland/xdg-utils/scripts/xdg-settings.in?view=markup

Changed in xdg-utils:
status: Unknown → Confirmed
Lei Zhang (thestig-google) wrote :

@Michael Terry: what patch did you throw over the wall to xdg-utils? URL?

Xdg-open calls gnome-open and kfmclient to open urls. Gnome-open and kfmclient checks certain GNOME / KDE settings to figure out how to handle urls. Xdg-settings works by checking those same settings.

Please remember the xdg/portland project is about having a standard way of opening files, url, emails, etc on all Linux desktop environments in all Linux distros. AFAIK, x-www-browser is a Debianism that doesn't exist in rpm-land.

Additionally, unlike your per-user GNOME/KDE settings, x-www-browser is a system setting that requires root to change. It seems wrong for Chromium / xdg-settings to change x-www-browser when one user on the system decides to set it as their default browser. What happens to x-www-browser when Alice and Bob have different browser preferences?

As far as Chromium developers are concerned, we want to support the majority of its users, but at the same time not be burdened with having to deal with each individual desktop environment / distro since the Linux desktop landscape is so diverse. Thus we use xdg-utils wherever we can. So sort out how xdg-utils should interact with x-www-browser and go from there.

Michael Terry (mterry) wrote :

Lei Zhang, the patch is both attached to this bug [1] and in the upstream bug I linked to this one [2].

I understand that x-www-browser is a Debianism. It was not my decision to include it in xdg-settings. I think the x-www-browser issue is a separate issue from this bug, and one that I doubt will be changed.

As for sorting this issue out with xdg-utils upstream, that's what I'm doing, no? My concern is only that xdg-settings (upstream and chromium both) is improperly using the full path when in GNOME. GNOME does not use full path values in its gconf keys. That is what I'm trying to solve.

[1] http://launchpadlibrarian.net/38457518/gnome_browser_basename.patch
[2] https://bugs.freedesktop.org/show_bug.cgi?id=26300

Lei Zhang (thestig-google) wrote :

@Michael Terry: I was mainly trying to address the x-www-browser issue. I missed your patch in this bug report earlier. Yes, I agree sorting this out in xdg-utils is the way to go. I've commented on the bug upstream.

Lei Zhang, I agree it's not a requirement, but as you say it is a convention in GNOME to use basenames. For example, all the other existing preferred apps use it. So xdg-setting trying to set or get any of them would fail [1].

The current behavior was suited for chromium because the script comes from chromium, but it's not a good fit for the rest of GNOME.

The issue you bring up with versions in non-standard locations could be solved with PATH adjustments.

[1] xdg-setting check default-web-browser epiphany.desktop will check for '/usr/bin/epiphany' when it will find 'epiphany' and say 'no'. And setting it will result in a 'Custom' preferred app instead of the existing option 'Epiphany'.

Michael Terry (mterry) on 2010-02-02
tags: added: oem-services
David Futcher (bobbo) on 2010-06-09
tags: added: patch-forwarded-upstream
Changed in xdg-utils:
importance: Unknown → Medium
Fabien Tassin (fta) wrote :

quick update:

with my most recent packaging, chromium detects the default browser using:
/usr/lib/chromium-browser/xdg-settings check default-web-browser chromium-browser.desktop

it still says "no" even if Chromium is default in the Gnome Preferred Web Browser.
If you ask Chromium to make it default, now it works as expected.

The reason xdg-settings fails the 1st is that even if the gconf keys are correct, it makes one more test
(xdg-mime query default text/html) which points to firefox.

xdg-mime searches in defaults.list 1st in ~/.local/share/applications/ then in /usr/share/gnome/applications/

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package chromium-browser - 6.0.472.63~r59945-0ubuntu2

---------------
chromium-browser (6.0.472.63~r59945-0ubuntu2) maverick; urgency=low

  * Fix the default browser selection on KDE4 by bringing in a fresher
    xdg-mime (See http://crbug.com/18106) and ship it in the main deb
    - add debian/patches/xdg-utils-update.patch
    - update debian/chromium-browser.install
  * Set CHROME_DESKTOP in the wrapper to help the default browser
    checker (LP: #513133)
    - update debian/chromium-browser.sh.in
 -- Fabien Tassin <email address hidden> Wed, 29 Sep 2010 20:40:05 +0200

Changed in chromium-browser (Ubuntu):
status: New → Fix Released
Changed in xdg-utils:
importance: Medium → Unknown
Changed in xdg-utils:
importance: Unknown → Medium

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xdg/xdg-utils/issues/37.

Changed in xdg-utils:
status: Confirmed → Unknown
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.