Install issue: Blockstack-browser gets launched in Firefox


After having somewhat resolved my previous issue (how to restore a keychain on another machine) I went on with a fresh install of Blockstack on a new Ubuntu 16.4 system.
I first installed Chromium and made it the default browser since this is not done automatically by the Ubuntu install.
I then installed Docker using the installation script provided on the Docker site.
I also added my user id to the docker group as recommended by Docker.

Then I went on to install Blockstack:

  • downloaded the from Blockstack’s site
  • gave it the execution permissions
  • ran ./ pull without any error message
  • and finally ran ./ start

It seemed to run properly in the CLI, but then, to my surprise, launched the blockstack-browser in Firefox instead of Chromium (which is the default browser) It asked me to setup the browser which I did by restoring my existing keychain. This went OK, since it was able o retrieve the info I had saved in a previous Linux install.
However, the helloblockstack app doesn’t let me sign-in: it hangs when trying to get my ID

Curiously enough, when going back to the terminal in which I launched the container, the process was still busy and I wasn’t receiving the prompt. When I closed the Firefox window, that launch process crashed ad went back at the prompt. The docker container was apparently still running since a restart told me it had to stop it first.

In case, you wonder, when I type the command/
xdg-open '
it opens properly in Chromium as expected
Same thing if I prefix it with bash -c

How can I get the blockstack-browser to launch in Chromium?
Why is the helloblockstack app not able to find out my ID?

I rolled back my Linux machine to the point just before running the script
This time, just to make sure, I tried executing xdg-open before running the script and surely enough it opened Chromium as expected.
However, after installing Blockstack, the start command fired up Firefox once again!
I closed that browser and then went to Chromium where I opened the http://localhost:8888 URL
It asked me to enter the API password to “pair” the browser with blocktack. Afterwards, it allowed me to restore my keychain, and retrieved everything in my profile (including the picture) from my previous attempt.
So far, so good. Unfortunately, firing the helloblockstack app got me stuck at exactly the same point as before:
It first asked me to confirm “Open xdg-open?” (BTW why is it doing that?) and after I gave the okay, it opened a new tab, with a dialog modal displaying: “Sign In Request / Loading app details…” and waited forever.
No other prompt was displayed in any other window…

So again two questions:

  • why does the blockstack start script insist on using Firefox?
  • what makes it unable to retrieve the app details?

Sorry your experience has been a little rocky – we are still working on improving our Linux support.

why does the blockstack start script insist on using Firefox?

The start script as it exists today, uses xdg-open in Linux. In most desktops, this usually does a good job of selecting the user’s default browser — unfortunately, it’s not always perfect, and as we improve the native support on Linux, investigating the default open policy is definitely an area where we can improve.

what makes it unable to retrieve the app details?

That shouldn’t be happening — there’s likely a bug somewhere causing this behavior. Do you see any errors in your Javascript console in Chromium while this is happening?

Same thing is happening here on Windows 10. Blockstack is opening in my default browser, Firefox.

Hi @aaron,
thanks for answering my concerns.
I found the solution to the first question and I guess I should share it with you since it’s a really simple oversight in the Blockstack-for-Linux shell script.

At the end of the start() case in the script you can find the following lines:

if [[ $(uname) == ‘Linux’ ]]; then
# let’s register the protocol handler if it isn’t already registered:
sensible-browser “http://localhost:8888/#coreAPIPassword=$password

It turns out that sensible-browser doesn’t always follow the same rules as xdg-open and might end up opening a different browser. The simplest fix it to replace the last line by:
xdg-open "http://localhost:8888/#coreAPIPassword=$password"
In this case, whatever default browser you have defined will be fired.

Also, I would suggest that the enter() case be amended as follows:
docker exec -it $corecontainer /bin/bash
It’s the Core container we need to enter to get access to the Blockstack CLI not the Browser container

I’ll look into the second issue and come back to you.

Then why not make Chrome your default browser?
My issue was that even though Chromium WAS my default browser, Blockstack would insist opening Firefox no matter what. But I found a solution now and it’s running fine.

Ah – good catch, thanks for that! I updated the launcher script with these changes ( and future releases will incorporate those.

Hi @aaron,

OK the issue with the helloblockstack is more obscure. I suspect it comes from a discrepancy between various pieces of the whole stack. The source of the app seems to have somewhat evolved over time and the version I see on various platforms is not exactly the same.

In the version presented in the Youtube tutorial the Sign-in button is bound to a call-back that reads:

var authRequest = blockstack.makeAuthRequest(null, window.location.origin)

The version I see in the Windows version is slightly different but equivalent:

var appDomain = window.location.hostname
var privateKey =  null
var authRequest = blockstack.makeAuthRequest(privateKey, appDomain)

While the version I get on Linux is:


The last version was previously hangingon Linux, but is now opening a new tab where it’s telling me Blockstack is not installed and offering me to either install it or go to the Webapp.

The first two versions are functionally equivalent and indeed display something in the Devtools console while running on Linux (for some reason is runs fine on Windows):

blockstack.js: generating v1.1.0 auth request
bundle.js:34625 Uncaught Error: private key must be a string
at Function.derivePublicKey (bundle.js:34625)
at Object.makeAuthRequest (bundle.js:8871)
at HTMLAnchorElement. (VM69 app.js:7)

Obviously, the makeAuthRequest has some problem with one of its parameters (the null private key) but how comes that the Windows version seems to deal properly with it while the Linux version doesn’t?

More specifically here are the differences I find in the respective Linux and Windows versions of MakeAuthRequest:
/* Convert the private key to a public key to an issuer */
var publicKey = _jsontokens.SECP256K1Client.derivePublicKey(transitPrivateKey);

if (privateKey === null) {
/* Create an unsecured token and return it */
token = (0, _jsontokens.createUnsecuredToken)(payload);
} else {
/* Convert the private key to a public key to an issuer */
var publicKey = _jsontokens.SECP256K1Client.derivePublicKey(privateKey);

Obviously, the Windows version takes more precautions with the parameters and can handle null while the Linux version is probably older and doesn’t care, hence the crash…
How can we ensure we have a consistent , up-to-date version on Linux, WITHOUT having to rebuild the whole thing???

I’m not sure this difference is due to the OS — should deliver the same version of blockstack.js no matter what OS you are on. There may be an issue with caching in this case — the version I see (on Linux) is:

document.getElementById('signin-button').addEventListener('click', function(event) {
    var appDomain = window.location.hostname
    var privateKey =  null
    var authRequest = blockstack.makeAuthRequest(privateKey, appDomain)

However, this is causing buggy behavior on sign-in, because it is generating an invalid authRequest. You should be able to log in to other apps such as the Todos app or Graphite.

Starting an issue for this here:

Hi Isben, have you tried to just install core and browser from source? You might have more luck than the docker way.

also from my experience logs at location helps in the troubleshooting: