Testing for presence of plugin

The demo applications show a notice after a timeout if connectSsb() does not call back successfully:

This Page needs to access Scuttlebut. Make sure that Scuttle Shell Browser is installed and that "SSB access" is switched on for this page.

Could there be a way for an application to get a more definitive answer about whether it can connect to the plugin/ssb-server? That would provide quicker feedback in the not-working case, and remove the opportunity for a race condition in the working case.

A side note first: ssb-connect supersedes connect-ssb and no longer relies on global variables.

If a connection fails, it's not trivial to say what went wrong.

• If the add-on is not installed then no content script is injected into the page. The consumer has no way of directly checking if the script has been injected and also the page script and content script are not always loaded in the same order and this is why the content- and page-script (aka the consumer library) first exchange ping messages. If no such message reaches the page-script the add-on is not installed.
• The background script checks if the page has been allowed access. It currently doesn't fail when the page has no access but rather buffers the messages and forwards them to the native script if and when the user grants the page access. It doesn't always work, but in some cases, this means that the ssb-content is shown as soon as the user grants access without needing the page to be reloaded. The background script could send back a message telling that permission has not been granted. This would make the API of the consumer library a bit more complicated as it would indicate why the request is still pending.
• If access is granted but the background script fails to get an answer from the native host there is often some helpful output on the browser console (not in the page console) that indicates either that the native host is not installed or that it is installed but failing because sbot isn't running (stderr of native host). However, I found no way to get these messages in the background script.