“app.webFetch is not a function” with safe_browser built from source


#1

I have been setting up a private development network (for those who haven’t seen my numerous other support threads…) with the current status:
-5 vaults (had 8 but strange issues showed up until I cut them down to min_sec_size)
-Pre-built Peruse and WHM (using custom crust and routing files)
-Created public ID and website, uploaded sample info

When I attempt to build from source (pretty much followed the readme line by line with fresh checkout) then copyied in crust and routing files I am unable to browse my test safesites.

Why would this happen when building from source but not with the prebuilt browser binary?


#2

This could again be down to uri registration. If that were failing the app never receives its authenticated state.

Does running xdg-open safe-auth://something trigger your built browser instance?


#3

Ahh, xdg-open, the bane of my existence it seems.
I have attempted to reset everything by:
rm ~/.local/share/applications/maidsafe*
(manually clearing relevant mimeinfo.cache entries)

For whatever reason I end up with the following when launching the browser:
“xdg-open: file 'safe-bmv0lm1haw” …" does not exist" (this value is now listed under the authenticator entry in maidsafenet-ltd-safe-browser.desktop )

My system default browser is Chrome, but this also launches firefox (as well as running xdg-open safe-auth:test)

Sadly, this feels like it is becoming a Linux support issue rather than maidsafe, it is confusing as to why firefox is stepping in when it isn’t even the default browser nor defined in the .desktop entries.


#4

I also get this error with the pre compiled version for OSX:

It works on version 0.6.0 that I still have. I tried to remove Library/Application Support/Safe Browser folder but with no result.


#5

You may need to remove 0.6.0 @Yerontour. OSX and its url binding can be fickle.

(We’re looking at alternatives to this IPC process, as it is truuuly a pain :expressionless: )