Getting Firefox to work with http://slurl.com

Sorry to ask such a simple question... when I try to teleport from rl to sl using http://slurl.com...

I get the message:

"Firefox doesn't know how to open this address, because the protocol (secondlife) isn't associated with any program."

I do have the linux secondlife client installed and working on my computer, and I am able to log into sl from my sl client.

I guess I need to tell ff to associate the sl client with http://slurl.com, but I don't know how to do that.

Any suggestions?

You know, I have exactly the same problem, and haven't found any obvious solution. It's my understanding that Firefox (and other browsers) get updated automatically in Windows when you install the SL viewer, since it adds entries to your registry. However, Linux has no registry, so all configuration changes must be done in individual ways depending on the application (a very good thing! No corrupted registry for me.) My Firefox gives me the same error, meaning slurls are useless to me. Searching Google has so far not yielded me any useful results. Anybody know the solution?

Get the Firefox Linkification addon. That's what worked for me.

I just tried to install that -- it failed. I'm running Firefox 2.0.0.6. Are you using some other version?

Adamas

2.0.0.7

I've had it stalled for about 6 months or so on earlier versions.

linkifacation does'nt fix that, although its great for links.
There is a fix in the forums somewhere.

Anyone know where this fix in the forums is?

Seems to me that most people who use Linux would also be using Firefox. I'm surprised this fix isn't a sticky here, or am I just one of a few users that have this problem?

Thanks for the link, Kornscope Komachi!

I got down to here:

5) Take a backup copy of the client startup script mentioned above, and then modify the original as follows. Among the various fields on the binary client invocation line, you will find these two fields separated by a space:



Place a new space-separated field "${1:+-url}" in between those two fields, so that it now looks like this:




I tried editing the secondlife startup script, but could not find anything that looked like . I presume the startup has since been changed, or have I just grabbed the wrong script?

just ignore the center-tags, those are markups for the vB-Forum (should display the tagged text centered) that aren't being parsed because parts of vB-Code have been switched off by the Lindens.

so it should read:

Nope. This is what's really in the current script:

eval ${SL_ENV} ${SL_CMD} ${SL_OPT} || echo Unclean shutdown.

All that stuff in brackets are variables set elsewhere in the script. The center one, ${SL_CMD}, is for the executable binary. Our addition goes right after it, like this:

eval ${SL_ENV} ${SL_CMD} ${1:+-url} ${SL_OPT} || echo Unclean shutdown.

I'm assuming "eval" is the runline in script-speak.

I tested this, and it works.

Adamas

I still can't find the lines in the script that I need to change!

I'm using the latest release of secondlife, which is SecondLife_i686_1_18_2_1, and there are two shell scripts:

secondlife:

## Here are some configuration options for Linux Client Alpha Testers.
## These options are for self-assisted troubleshooting during this alpha
## testing phase; you should not usually need to touch them.

## - Avoids using the ESD audio driver.
#export LL_BAD_ESD=x

## - Avoids using the OSS audio driver.
#export LL_BAD_OSS=x

## - Avoids using the ALSA audio driver.
#export LL_BAD_ALSA=x

## - Avoids the optional OpenGL extensions which have proven most problematic
## on some hardware. Disabling this option may cause BETTER PERFORMANCE but
## may also cause CRASHES and hangs on some unstable combinations of drivers
## and hardware.
export LL_GL_BASICEXT=x

## - Avoids *all* optional OpenGL extensions. This is the safest and least-
## exciting option. Enable this if you experience stability issues, and
## report whether it helps in the Linux Client Alpha Testers forum.
#export LL_GL_NOEXT=x

## - For advanced troubleshooters, this lets you disable specific GL
## extensions, each of which is represented by a letter a-o. If you can
## narrow down a stability problem on your system to just one or two
## extensions then please post details of your hardware (and drivers) to
## the Linux Client Alpha Testers forum along with the minimal
## LL_GL_BLACKLIST which solves your problems.
#export LL_GL_BLACKLIST=abcdefghijklmno

## - For advanced debugging cases, you can run the viewer under the
## control of another program, such as strace, gdb, or valgrind. If
## you're building your own viewer, bear in mind that the executable
## in the bin directory will be stripped: you should replace it with
## an unstripped binary before you run.
#export LL_WRAPPER='valgrind --smc-check=all --log-file=secondlife.vg --leak-check=full --suppressions=/usr/lib/valgrind/glibc-2.5.supp --suppressions=secondlife-i686.supp'

## - Avoids an often-buggy X feature that doesn't really benefit us anyway.
export SDL_VIDEO_X11_DGAMOUSE=0

## Nothing worth editing below this line.
##-------------------------------------------------------------------

RUN_PATH=`dirname "$0" || echo .`
cd "${RUN_PATH}"
if [ -n "$LL_TCMALLOC" ]; then
tcmalloc_libs='/usr/lib/libtcmalloc.so.0 /usr/lib/libstacktrace.so.0 /lib/libpthread.so.0'
all=1
for f in $tcmalloc_libs; do
if [ ! -f $f ]; then
all=0
fi
done
if [ $all != 1 ]; then
echo 'Cannot use tcmalloc libraries: components missing' 1>&2
else
export LD_PRELOAD=$(echo $tcmalloc_libs | tr ' '
if [ -z "$HEAPCHECK" -a -z "$HEAPPROFILE" ]; then
export HEAPCHECK=${HEAPCHECK:-normal}
fi
fi
fi
LD_LIBRARY_PATH="`pwd`"/lib:"`pwd`"/app_settings/mozilla-runtime-linux-i686:"${LD_LIBRARY_PATH}" $LL_WRAPPER bin/do-not-directly-run-secondlife-bin `cat gridargs.dat` $@ | cat

echo
echo '*********************************************************'
echo 'This is an ALPHA release of the Second Life linux client.'
echo 'Thank you for testing!'
echo 'You can visit the Linux Client Alpha Testers forum at:'
echo 'http://forums.secondlife.com/forumdisplay.php?forumid=263'
echo 'Please see README-linux.txt before reporting problems.'
echo



and launch_url.sh:

# This script loads a web page in the 'default' graphical web browser.
# It MUST return immediately (or soon), so the browser should be
# launched in the background (thus no text-only browsers).
# This script does not trust the URL to be well-escaped or shell-safe.
#
# On Unixoids we try, in order of decreasing priority:
# - $BROWSER if set (preferred)
# - kfmclient openURL
# - x-www-browser
# - opera
# - firefox
# - mozilla
# - netscape

URL="$1"

if [ -z "$URL" ]; then
echo Usage: $0 URL
exit
fi

# if $BROWSER is defined, use it.
XBROWSER=`echo "$BROWSER" |cut -f1 -d:`
if [ ! -z "$XBROWSER" ]; then
XBROWSER_CMD=`echo "$XBROWSER" |cut -f1 -d' '`
# look for $XBROWSER_CMD either literally or in PATH
if [ -x "$XBROWSER_CMD" ] || which $XBROWSER_CMD >/dev/null; then
# check for %s string, avoiding bash2-ism of [[ ]]
if echo "$XBROWSER" | grep %s >/dev/null; then
# $XBROWSER has %s which needs substituting
echo "$URL" | xargs -r -i%s $XBROWSER &
exit
fi
# $XBROWSER has no %s, tack URL on the end instead
$XBROWSER "$URL" &
exit
fi
echo "Couldn't find the browser specified by \$BROWSER ($BROWSER)"
echo "Trying some others..."
fi

# else kfmclient
# (embodies KDE concept of 'preferred browser')
if which kfmclient >/dev/null; then
kfmclient openURL "$URL" &
exit
fi

# else x-www-browser
# (Debianesque idea of a working X browser)
if which x-www-browser >/dev/null; then
x-www-browser "$URL" &
exit
fi

# else opera
# (if user has opera in their path, they probably went to the
# trouble of installing it -> prefer it)
if which opera >/dev/null; then
opera "$URL" &
exit
fi

# else firefox
if which firefox >/dev/null; then
firefox "$URL" &
exit
fi

# else mozilla
if which mozilla >/dev/null; then
mozilla "$URL" &
exit
fi

# else netscape
if which netscape >/dev/null; then
netscape "$URL" &
exit
fi

echo 'Failed to find a known browser. Please consider setting the $BROWSER environment variable.'

# end.


NOTE: I removed the first two lines from each of these files because they were causing problems posting with this forum software!

I'm using the release candidate which has a different execution line in the script. It looks like that second script is for calling Firefox (or whatever browser) from the client.

The first script you list is the correct one. That last line, the one that starts with "$LL_WRAPPER" is the execution line. The client binary is named "do-not-directly-run-secondlife-bin" and is in the "bin" folder. That "cat gridargs.dat" item seems to be a command-line parameter. Try putting the ${1:+-url} on one side of the "cat..." then the other to see which side it works on.

Adamas

I tried the ${1:+-url}

$LL_WRAPPER bin/do-not-directly-run-secondlife-bin `${1:+-url} cat gridargs.dat` $@ | cat $LL_WRAPPER bin/do-not-directly-run-secondlife-bin `cat ${1:+-url} gridargs.dat` $@ | cat $LL_WRAPPER bin/do-not-directly-run-secondlife-bin ${1:+-url} `cat gridargs.dat` $@ | cat $LL_WRAPPER bin/do-not-directly-run-secondlife-bin `cat gridargs.dat` ${1:+-url} $@ | cat

I can login to SecondLife from the client in every case, but when I try clicking on slurl, I get the message:



An external application must be launched to handle secondlife: links.

Requested link:

secondlife:// (link here)

Application: SecondLife_i686_1_18_2_1



So, it looks like the parameter that is getting picked up is the directory name and not the executable.

Where are you getting that message? From Firefox or from the sl client?

If you're getting it from Firefox, you probably might not have the about:config stuff set up properly. If you're getting it from sl, either there's something funky about the client (try the release candidate instead) or that "cat..." stuff is messing things up. It is the only thing that doesn't seem to follow the "$..." pattern of the rest of the execution line.

Adamas

Hi Adamas!

I was getting that message from Firefox, so I had a look at about:config and discovered that I was the culprit! I was pointing Firefox to the directory of the startup script instead of to the script itself - my bad!

Once I fixed that, the startup script worked without any modification!

So, just to be clear, step 5 of the instructions is not necessary with SecondLife_i686_1_18_2_1 using the above startup script.

Thanks to everyone for all your help!

Hi Morbid
can u tell me what u altered in about:config ?
I've had a look but cant see what I should change.

Arari

Hi Atari!

Sorry I haven't replied sooner...I moved at the end of September and just got my phone and internet working on Friday!

In the Firefox config file, I added a line for the secondlife protocol handler:

network.protocol-handler.app.secondlife

and set the user value to the location of the secondlife startup script.