Bug 88345 – mail-client/balsa-2.2.6 does not open browser for https:// links, only http:/

• Product: Gentoo Linux
• Status: RESOLVED INVALID

[Description Jack 2005-04-08 06:16:56 UTC]

If an email contains a URL http://wherever.com/page I can click on it and it opens a browser.  I just emerged 2.2.6 and if I click on an https:/site.com/page link, nothing happens.  I do not know it this was also true in 2.0.15.

(I filed this under applications instead of GNOME because I am using KDE so I think it's a balsa not a gnome bug.  Let me know if I should refile.)

I will separately file this at bugzilla.gnome.org (where I also do not see anything similar already listed)

Reproducible: Always
Steps to Reproduce:
1. open an email containing an embedded https:// link in either the preview pane or a separate window
2. click on the link.  The status bar shows the same messages as for a http:// link but nothing happens.
3.

Actual Results:  
nothing

Expected Results:  
open a browser (Mozilla for me) at the clilcked URL

balsa 2.2.6 was has ~x86 in /etc/portage/package.keywords.  just about
everything else is stable branch only.  emerge sync and -puD within the past few
days.

Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.3.5, glibc-2.3.4.20041102-r1,
2.6.11.4-1 i686)
=================================================================
System uname: 2.6.11.4-1 i686 AMD Athlon(TM) XP 2000+
Gentoo Base System version 1.4.16
Python:              dev-lang/python-2.3.4-r1 [2.3.4 (#1, Feb  9 2005, 23:54:50)]
dev-lang/python:     2.3.4-r1
sys-devel/autoconf:  2.13, 2.59-r6
sys-devel/automake:  1.5, 1.7.9-r1, 1.6.3, 1.4_p6, 1.9.4, 1.8.5-r3
sys-devel/binutils:  2.15.92.0.2-r7
sys-devel/libtool:   1.5.10-r4
virtual/os-headers:  2.6.8.1-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.2/share/config
/usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown
/usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms"
GENTOO_MIRRORS="http://mirror.datapipe.net/gentoo
http://gentoo.mirrors.pair.com/ http://mirror.datapipe.net/gentoo"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 X alsa apm arts avi berkdb bitmap-fonts bzlib cdr crypt cups curl debug
dvd dvdread emacs encode esd fam foomaticdb fortran gdbm gif glut gnome gphoto2
gpm gstreamer gtk gtk2 gtkhtml imagemagick imlib ipv6 java javascript jpeg kde
libg++ libwww lm_sensors logitech-mouse mad mikmod mime mmx mmx2 motif
moznocompose moznomail mozplaintext mozsvg mp3 mpeg ncurses nls nocd nptl ogg
oggvorbis opengl oss pam pcre pdflib perl png ppds python qt quicktime readline
scanner sdl slang snmp spell sse ssl svga tcltk tcpd tiff truetype
truetype-fonts type1-fonts xine xml xml2 xmms xv xvid zlib"
Unset:  ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, PORTDIR_OVERLAY

[Comment 1 John N. Laliberte (RETIRED) 2005-04-08 08:19:18 UTC]

Heres the link to gnome bug that Jack posted ( to refer to and monitor): http://bugs.gnome.org/show_bug.cgi?id=173065

[Comment 2 Jack 2005-04-08 10:28:40 UTC]

The response to the gnome bug implies that the handler for https:// is separate from the one for http:// in the gnome control center.  As I remember, this is a bit tough to find, since I'm using KDE, not Gnome.  I'll try to find and set it when I get home this evening.

[Comment 3 Joe McCann (RETIRED) 2005-04-08 11:52:11 UTC]

can you try running:
gconftool-2 --set /desktop/gnome/url-handlers/https/command -t string 'yourbrowser %s'

[Comment 4 Jack 2005-04-08 14:15:36 UTC]

Thanks. gconftool-2 worked.  It turns out it was set to epiphany, which fails to run.  (I'll have to track down that problem separately.)  After setting it to mozilla, it works as expected.  

Feel free to close the ticket, since this is clearly resolved, but I'm not sure what the best status is.  Gnome's bugzilla has NOTBUG.  I wonder if this should turn into a request that a failure to launch a handler is noted someplace instead of silently ignored (or is it already, and I just don't know where to look?)

[Comment 5 Joe McCann (RETIRED) 2005-04-08 14:33:56 UTC]

yea this is not a bug because it is getting the browser command from the proper location that one would expect from a gnome application.