Bug 109883 - Preferred Web Browser should run from panel launcher
Summary: Preferred Web Browser should run from panel launcher
Alias: None
Product: Fedora
Classification: Fedora
Component: control-center   
(Show other bugs)
Version: 1
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jonathan Blandford
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2003-11-12 17:38 UTC by Brian Pepple
Modified: 2013-04-02 04:18 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-10-22 09:30:35 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Brian Pepple 2003-11-12 17:38:57 UTC
Description of problem:

When trying to set a cutom web browser as the preferred application,
the new selection is not saved. 

Version-Release number of selected component (if applicable):

How reproducible: Always.

Steps to Reproduce:
1. Open the Preferred Application Tool, and Select Custom Web Browser
2. Enter command path to the web browser wishing to be used
3. Close the application.
Actual results: When clicking on a url, the desktop uses the default
web browser, normally Mozilla.

Expected results: When clicking on a url, the desktop should use the
web browser that was entered manually as the custom web browser.

Additional info:

Comment 1 Warren Togami 2003-12-11 05:48:44 UTC
I am in total agreement.  The panel launcher should launch the user's
chosen preferred browser.

Comment 2 Warren Togami 2003-12-11 19:45:42 UTC
I am quite sure this is not a control-center bug.  Read Bug #109738.

Comment 3 Brian Pepple 2003-12-11 20:50:18 UTC
Based on my preliminary research the bug seems to be in

Looks like DEFAULT_APPS_KEY_BROWSER_NEEDS_TERM is possibly defined
incorrectly, but I need to do more research to verify.

Warren, what leads you to believe this isn't a bug in control-center,
is there something I'm missing?  BTW, thanks for the link to the other
bug, they definitely seem to be related.

Comment 4 Warren Togami 2003-12-11 21:21:38 UTC
That application only sets the user's preferred browser (albeit
incorrectly Bug #109738) in gconf.  The problem here is the menu
option and panel launcher is calling mozilla directly, and not using
the gconf defined browser.

Comment 5 Brian Pepple 2003-12-11 22:19:44 UTC
Oh, that's sorta different than what my original bug was referring to.
 If I'm understanding you correctly, you basically want the menu &
panel launchers to invoke the preferred browser, and not 'mozilla %u'.
 If I'm incorrect in my assumption, you can contact me outside of
Bugzilla.  No reason to cause undue clutter here, due to my denseness.

Back to control-center: I also noticed that control-center doesn't
seem to set the 'enabled' key under url-handlers->http in GConf, when
attemping to use a Custom Web Browser. 

Comment 6 Warren Togami 2003-12-11 23:22:49 UTC
You are correct that I want the launchers to run the preferred
browser.  What did you have in mind instead?  (I'm curious.)

You are correct about the "enabled" key, but I don't think there are
any applications that actually pay attention to that.  I could be
wrong though.

Comment 7 Brian Pepple 2003-12-12 01:10:24 UTC
I was thinking of when you have a url in an e-mail (like in
Evolution), having the Custom Web Browser opening it, instead of
Mozilla.  I'm only able to get this behavior by editing the following
GConf keys: 

/desktop/gnome/url-handlers/https/command/ value=mozilla-firebird "%s"
/desktop/gnome/url-handlers/https/enabled/ value=true

Regarding your problem, is there a command that runs the default
browser?  Off the top of my head, I'm not aware of one.

Comment 8 Warren Togami 2003-12-12 02:40:59 UTC
Your problem would be fixed by Bug #109738.

Currently there is htmlview, but it is deeply flawed.  See this for
50% of the solution to eventually fixing htmlview.

Comment 9 Marco Pesenti Gritti 2004-10-22 09:30:35 UTC
The reporter problem is now fixed.

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