I thought that crash is only when opening the dev console? aren’t you able to load the site correctly?
As a tip, if you upload your files/website onto the shared vault it’s easier to troubleshoot as we can fetch the exact same files and using the xorurls you share, just mentioning if you find that convenient for reporting issues in the future.
Yes true, that is when opening the dev console. index.html does load, from looking at the title on the tab, however I can’t verify the loading state of the JS/WASM resources without the dev console.
Thanks for the shared vault offer.
Having figured out a workaround to this bug I can finally confirm that that is the solution.
When loading the XOR-URL of index.html in SAFE Browser, the contents of the JS file are reported to be the same as index.html, generating the syntax error.
When loading the XOR-URL of the FilesContainer containing index.html, the contents of the JS file are as expected.
I would consider the file handling when directly visiting index.html to be a bug in SAFE Browser. I briefly searched the repo’s issues and did not find it reported. Please tell me if I missed it.
Moreover, FWIW having read the entire SAFE CLI user guide I believe additional documentation would be helpful. A table describing the default handling of the various container types by official SAFE programs would be helpful.
For example, the behavior of SAFE Browser to automatically retrieve index.html of a FilesContainer.
The documentation contains:
e.g. the SAFE Browser would be automatically fetching the
index.htmlfile from it and rendering the website to the user.
While the behavior is intuitive and reasonable it should be directly and explicitly documented. If it is documented elsewhere, perhaps in a more general SAFE architectural document, that should be linked to.
Yes, i suspected that was the issue, and I don’t think that is bug, when you are fetching the index.html using its location the browser or any client app you use for that doesn’t have any clue that file is linked/contained from another content like a FilesContainer (in fact it could be linked/contained from more than one FilesContainer), the index.html xorurl is a direct link to the content of the file but nothing else, not even its name or other metadata, so there is no folder hierarchy that could be found/realised from that xorurl by any app or the network.
On the other hand retrieving the index.html through a path from a FilesContainer, the client knows there is a hierarchy/structure and where the file fits into it, so it can resolve a relative or absolute path link found in the content of it. I’m not sure if it’s clear enough, please just ask if not, I’ll try again.
About documenting this behavior, i think it shouldn’t go into a CLI doc but perhaps the browser doc, so I’m with you we are probably missing a place where to start documenting this type of things. However, this in the future won’t be even defined by the browser or app you are fetching the content with, as the default entry to a site shall/will be defined in the RDF content itself, so what we have now is a temporary thing until we have RDF, at that point a browser app will have to look at what it’s defined there as the default entry page, which was defined by the app which wrote the content, which in turn may have been chosen by the user.
I believe I comprehend your point that by accessing the index.html file directly, there is insufficient context to know from where to resolve the linked JS file. IIUC, I would argue that if a linked file cannot be resolved, it should be handled differently. For example, under Network in dev tools the status code for the JS file is 200. That gives a false impression that the file location was resolved and its contents loaded.
Wouldn’t handling it as a 404 be more intuitive and correct?
I would think so yes, it should be closest to whatever happens on any other browser for links not found, let’s wait fro @joshuef comments/knowledge about the situation in the browser for this scenario, as he for sure knows how unresolved links are handled by it.
Yeh, this is a bug. It’s returning the same file as attempting to resolve it at the xorurl, but we only find that same file. So it’s currently returning it, whereas we should probably 404. This is a bug in our resolution logic. Can you file an issue for the same please @anon78698497 
As for documentation, yup, we should have some. It’s not been a priority as things browser/API side are still far from complete.
If you fancy taking a crack at documenting things in browser-land, PRs are super welcome!
We do have this document though it’s largely reflective of the old APIs. I’ll dive in now to remove what’s irrelevant, but if you wanted to note your findings on web development, that’d be the best place for it 
Edit: Quickly updated the docs to remove old refs in the current pending pr: https://github.com/maidsafe/safe_browser/pull/1152, in this commit.
I won’t have a quarantined box suitable for using Big Tech services for several months unfortunately.
I will be when the above issue is addressed.
@anon78698497 can you republish your site after the testnet wipe please 
also, what OS are you on?
I’ve only published it to the local vault. Would you like for me to publish it to the shared vault?
macOS 10.14.5.
Yes please 
You can reproduce it with this safe://hbhybydrr6htazoz7e7iho6nn9rooshfbiayo6bsm6xzjnksoktf1h6qii
FYI @anon78698497 https://github.com/maidsafe/safe_browser/releases/tag/v0.16.0-alpha.0 should work against the CLI.
It doesn’t have any fixes for anything else in there yet though (and also is alpha, so may not be super stable).
@bochaco looks like this isn’t a purely browser based issue,
safe cat safe://hbhybydrr6htazoz7e7iho6nn9rooshfbiayo6bsm6xzjnksoktf1h6qii/artifacts/bundle.js returns the same.
(will make an issue for this in safe-api). We should be 404ing since there can be nothing relative on the ID.
FWIW in testing 0.16.0-alpha.0 I’m frequently observing the error
The SAFE Browser was not able to connected the network.
whereas in the 0.15.x series I don’t recall having seeing it.
Correction, testing with the 0.15.x series, it’s also exhibiting that behavior.
Rather than being an issue with SAFE Browser it’s possibly with the updated CLI. With the updated CLI I’m managing authd through it using auth install; auth start; auth login --self-auth.
I’m a bit lost here, is this issue about not being able to connect anyhow related to the OP? in any case the browser connects directly to the network for fetching data, so it’s irrelevant what you are doing with CLI and/or authd at that point. The only problem you have with connectivity in relation to CLI is if you are changing the network configuration file with CLI and/or running/not-running a local vault. Can you please detail the exact steps you are making to get the connectivity issue? I suspect you are running a local vault which sometimes is stopped and you try to connect with the browser to?
No it’s not. My intent was to share information in context however I should probably create a new topic for it instead. I’ll search SAFE Browser’s repo issues and if it’s not been reported I’ll create a topic with answers to your questions.
This topic was automatically closed after 60 days. New replies are no longer allowed.