Bug 2051 - Preferred Web browser is not always respected
Summary: Preferred Web browser is not always respected
Status: ASSIGNED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: Normal normal
Target Milestone: Mageia 6
Assignee: Florian Hubold
QA Contact:
URL:
Whiteboard:
Keywords: NEEDINFO, USABILITY
Depends on:
Blocks:
 
Reported: 2011-07-06 19:11 CEST by Antoine Pitrou
Modified: 2016-10-10 22:14 CEST (History)
7 users (show)

See Also:
Source RPM: xdg-utils
CVE:
Status comment:


Attachments

Description Antoine Pitrou 2011-07-06 19:11:41 CEST
I configured another Web browser in the "preferred applications" GNOME settings box, by using a custom executable path. However, in some instances (clicking a link in some applications), the default browser is still run.

I've discovered that it's because gvfs-open (invoked from xdg-open, itself invoked from /usr/bin/www-browser) ignores that setting. It also ignores the $BROWSER envinronment variable. It seems to read its own configuration files in /usr/share/applications, namely defaults.list which itself references firefox.desktop.
(apparently I might be able to customize this in $HOME/.local, but that's beginning to be awfully tedious for a single config item)

This all makes it too hard to set a third-party browser as default, even though I'm running everything from a GNOME desktop.

(I've filed this bug against gvfs but I've got no idea whether this is the right component, since everything seems so entangled)
Comment 1 Walter Marek 2011-08-06 10:14:34 CEST
(In reply to comment #0)
> It seems to read its own configuration files in
> /usr/share/applications, namely defaults.list which itself references
> firefox.desktop.

I've got the same problem.

After change some relevant entries in /usr/share/applications/defaults.list from firefox.desktop to opera.desktop now opera is starting.

CC: (none) => wm6369

Comment 2 Walter Marek 2011-08-06 10:16:11 CEST
I have to add my platform is i386
Comment 3 Christian Lohmaier 2011-10-06 19:09:11 CEST
same here- using chromium, let chromium set the default browser. In preferred applications dialog, it entered

"/usr/lib64/chromium-browser/chromium-wrapper %s" in the custom command box
Chromium browser is not available in the dropdown list, but is available in Applications|Internet menu. 

But this is ignored from Pidgin, gnome-terminal, rpmdrake (however rpmdrake did not work in Mandriva either, so this might be a different problem) and opens stuff in firefox instead.

HOWEVER:
[cl@esprimo ~]$ xdg-settings get default-web-browser

[cl@esprimo ~]$ xdg-settings check default-web-browser firefox.desktop
no
[cl@esprimo ~]$ xdg-settings check default-web-browser chromium-browser.desktop
yes
[cl@esprimo ~]$ xdg-settings set default-web-browser chromium-browser.desktop
[cl@esprimo ~]$ xdg-settings get default-web-browser

[cl@esprimo ~]$ xdg-settings set default-web-browser firefox.desktop
[cl@esprimo ~]$ xdg-settings get default-web-browser
firefox.desktop
[cl@esprimo ~]$ xdg-settings set default-web-browser chromium-browser.desktop
[cl@esprimo ~]$ xdg-settings get default-web-browser

[cl@esprimo ~]$ 

So for some reason xdg-settings fail to acknowledge/set the chromium-browser.desktop file

But the effect of both is the same:

[cl@esprimo ~]$ xdg-settings set default-web-browser firefox.desktop
[cl@esprimo ~]$ cat .local/share/applications/defaults.list 
[Default Applications]
text/html=firefox.desktop
[cl@esprimo ~]$ xdg-settings set default-web-browser chromium-browser.desktop
[cl@esprimo ~]$ cat .local/share/applications/defaults.list 
[Default Applications]
text/html=chromium-browser.desktop
[cl@esprimo ~]$ 

As the firefox.desktop as well as the chromium-browser.desktop files are identical except for the name and command, I suspect there is some other configuration that makes the tools ignore it.

As it isn't even possible to set the default browser using the configuration in .local the severity is set to major.

Keywords: (none) => USABILITY
CC: (none) => lohmaier+mageia
Hardware: x86_64 => All
Severity: normal => major

Comment 4 Manuel Hiebel 2011-10-06 19:36:53 CEST
(not sure of the package)

Assignee: bugsquad => anssi.hannula
Source RPM: gvfs-1.6.7-2.mga1.src.rpm => xdg-utils

Dick Gevers 2011-12-09 20:24:47 CET

CC: (none) => doc-bugs

Oliver Burger 2011-12-10 22:07:55 CET

CC: doc-bugs => (none)

Comment 5 Florian Hubold 2011-12-11 18:52:53 CET
I'll try to look into it. But on a related note, under KDE this works normally. Also IIRC for "xdg-settings set" you need to omit the .desktop suffix, only give the bassename of the .desktop file, but not quite sure

Resetting severity to normal, as this is exactly "some loss of functionality under specific circumstances"

Status: NEW => ASSIGNED
CC: (none) => doktor5000
Assignee: anssi.hannula => doktor5000
Severity: major => normal

Comment 6 Florian Hubold 2011-12-12 16:22:23 CET
@Christian Lohmaier
Well, i can't reproduce:

[doktor5000@mageia1 ~]$ xdg-settings set default-web-browser chromium-browser.desktop
[doktor5000@mageia1 ~]$ cat .local/share/applications/defaults.list
[Default Applications]
text/html=chromium-browser.desktop
[doktor5000@mageia1 ~]$ xdg-open "http://www.google.com"

This opens chromium as it should, before that firefox was the default browser.
Setting it back to firefox and then xdg-open launches firefox.
Maybe you should open a seperate report for your issue, as your issue is different from the original report, because chromium seems to be unable to set itself as default browser. xdg-open working correctly here.



@Antoine Pitrou: This seems to be a problem of gvfs-open, yes, you're correct there. But sadly gvfs has no maintainer and i don't know how to fix, sorry :(
Comment 7 Dave Hodgins 2011-12-13 20:42:22 CET
After looking through the code of gvfs and glib2, it looks like
adding a line to .local/share/applications/defaults.list
with
x-scheme-handler/http=chromium-browser.desktop

will fix the problem.

So either the places that set the default application have to
generate lines for both text/html, and x-scheme-handler/http,
or glib2/glib-2.28.6/gio/gdesktopappinfo.c should be changed
to use the text/html mime-type for http urls.

I've noticed that gvfs-open does not pass the url in a way
that works with opera, but that is a different problem.

It does work with chromium.

CC: (none) => davidwhodgins

Comment 8 Florian Hubold 2012-02-14 14:05:15 CET
Sounds rather like a workaround, not like the real fix. I've found the following documentation about the overall problem:
https://wiki.archlinux.org/index.php/Default_Applications
http://www.freedesktop.org/wiki/Specifications/mime-actions-spec
https://wiki.archlinux.org/index.php/Default_Applications#Exactly_how_it_works has also some pointers why it doesn't work as it is intended to be (standard not correctly implemented, on mainstream desktop environments xdg-open might try calling their specific tools before xdg-mime)

Maybe we should try to package http://xyne.archlinux.ca/projects/mimeo/ as xdg-settings doesn't even work under some desktop environments.
Comment 9 Florian Hubold 2012-08-12 16:21:45 CEST
Reassigning to bugsquad, i don't have the time to work on this anymore.

Keywords: (none) => Junior_job
Status: ASSIGNED => NEW
Assignee: doktor5000 => qa-bugs

Florian Hubold 2012-08-12 16:21:56 CEST

Assignee: qa-bugs => bugsquad

Comment 10 Manuel Hiebel 2012-11-05 16:52:18 CET
This message is a reminder that Mageia 1 is nearing its end of life. 
In approximately 25 days from now, Mageia will stop maintaining and issuing 
updates for Mageia 1. At that time this bug will be closed as WONTFIX (EOL) if it 
remains open with a Mageia 'version' of '1'.

Package Maintainer: If you wish for this bug to remain open because you plan to 
fix it in a currently maintained version, simply change the 'version' to a later 
Mageia version prior to Mageia 1's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not 
be able to fix it before Mageia 1 is end of life.  If you would still like to see 
this bug fixed and are able to reproduce it against a later version of Mageia, 
you are encouraged to click on "Version" and change it against that version 
of Mageia.

Although we aim to fix as many bugs as possible during every release's lifetime, 
sometimes those efforts are overtaken by events. Often a more recent Mageia 
release includes newer upstream software that fixes bugs or makes them obsolete.

--
Mageia Bugsquad
Comment 11 Manuel Hiebel 2012-12-02 14:31:57 CET
Mageia 1 changed to end-of-life (EOL) status on ''1st December''. Mageia 1 is no 
longer maintained, which means that it will not receive any further security or 
bug fix updates. As a result we are closing this bug. 

If you can reproduce this bug against a currently maintained version of Mageia 
please feel free to click on "Version" change it against that version of Mageia and reopen this bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

--
Mageia Bugsquad

Status: NEW => RESOLVED
Resolution: (none) => WONTFIX

Comment 12 Florian Hubold 2014-04-13 15:52:41 CEST
Reopening, as this is still valid AFAICS.

FWIW, changing the default browser in KDE via systemsettings seems not enough, you also need to change the association via xdg-mime. Related forum thread:
https://forums.mageia.org/en/viewtopic.php?p=47081#p47081

Also, the same as for Thunderbird and default applications bug applies here:

Please somebody create a test case in the wiki so this can be tackled in the development phase for Mageia 5.

Keywords: Junior_job => (none)
Status: RESOLVED => REOPENED
Version: 1 => Cauldron
Resolution: WONTFIX => (none)
Assignee: bugsquad => doktor5000
Target Milestone: --- => Mageia 5

Comment 13 Florian Hubold 2014-04-13 15:53:36 CEST
assigning to myself again

Status: REOPENED => ASSIGNED

Comment 14 Florian Hubold 2014-08-24 18:16:10 CEST
I've created a draft test case and some related links in the wiki:
https://wiki.mageia.org/en/User:Doktor5000#Default_applications_handling_in_Firefox_.26_Thunderbird

Along with the related topic of default applications in general:
https://wiki.mageia.org/en/User:Doktor5000#Default_applications_.28e.g._default_browser.29_systemwide_.2F_per-desktop

Please everybody test and provide feedback.
Florian Hubold 2014-08-24 18:16:33 CEST

See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=2027

Comment 15 Florian Hubold 2014-09-16 21:10:23 CEST
FWIW, I've added instructions how to set the default browser. Trigger for me was that after switching from chromium too google-chrome, somehow https:// links were opened with firefox.

See https://wiki.mageia.org/en/User:Doktor5000#How_to_set_the_default_browser_.2F_url-scheme_handler

Still missing feedback on the test case, would be greatly appreciated for fresh cauldron/mga5 installations.
Comment 16 Florian Hubold 2015-06-11 11:51:33 CEST
Still waiting for feedback, see comment 14. Set target to mga6 ...

Target Milestone: Mageia 5 => Mageia 6

Dimitrios Glentadakis 2015-06-11 12:20:16 CEST

CC: (none) => dglent

Comment 17 Otto Leipälä 2016-05-06 12:58:51 CEST
This problem is very weird as i got in test install system with installer installed chromium and still xdg shows/sets default browser firefox.
Would be very nice to get this finally fixed i got my chromecast this week and use in lxqt only google-chrome.

CC: (none) => ozkyster

Comment 18 Florian Hubold 2016-05-07 14:15:08 CEST
Fix what issue exactly? I've provided a test case, nobody has provided any feedback so far, so nothing can be fixed.
Comment 19 Otto Leipälä 2016-05-17 11:51:37 CEST
Set chrome(ium) to default browser without manual configuration.
I use this right now little local fix to set chrome as default.

~/.local/share/applications/mimeapps.list

[Default Applications]
text/html=google-chrome.desktop
x-scheme-handler/http=google-chrome.desktop
x-scheme-handler/https=google-chrome.desktop
x-scheme-handler/about=google-chrome.desktop
x-scheme-handler/unknown=google-chrome.desktop
Comment 20 Samuel Verschelde 2016-10-10 22:14:16 CEST
Adding QA team in CC in the hope that someone from there can take the time to give feedback to Florian regarding comment #14, so that this bug can be fixed.

Keywords: (none) => NEEDINFO
CC: (none) => qa-bugs


Note You need to log in before you can comment on or make changes to this bug.