Using the SAFE Browser dev tools, (Sources) the /artifacts/bundle.js file is shown as having the same contents as index.html and reporting the error on the <!doctype html> line. However, ./safe cat retrieval of the bundle.js file using its xor-url outputs JavaScript as expected.
Perhaps you need to load the site on the browser using the FilesContainer xorurl instead: safe://hnyynyz31hqc4os8oq59b1r4rmckamdf19idhgowcafz3cbe9xz1qzxk4abnc ?
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.
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.html file 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
