Closed TheRankin closed 2 years ago
What is PWA-Chrome
?
I know what PWA
is (and Human does work as PWA, main demo actually does actually showcase that), but PWA-Chrome
does not ring any bells right now...
Btw, you still did not post browser inspector log as requested AND ignored what I already diagnosed in the discussion?
From the other thread, clearly whatever PWA-Chrome is, it's messing up environment detection as in Env
output in the log you see both browser=true
and node=true
. That messes up selection of best backend, but fallback works, so its a non-critical issue on its own.
There is no going around the fact that whatever PWA-Chrome
is, it's not loading *.bin
files correctly (again, HTTP Code 204 is a code OUTSIDE of my control, it comes between browser and server). This is a critical issue.
in VSCode you can launch a PWA-Chrome that is like a Guest Chrome where your settings exist only in that mode (like when you login into another user in Chrome), mostly used for debugging
launch.json
{
"configurations": [
{
"name": "Launch Chrome",
"request": "launch",
"preLaunchTask": "npm: start",
"type": "pwa-chrome",
"url": "http://localhost:1234",
"webRoot": "${workspaceFolder}"
}
]
}
I use this mode for web development (like Reach, Angular, etc) so in this case, I guess if someone tries to implement Human and is running the dev-server on PWA-Chrome in the VSCode launch, they will get this problem without understand 'why?'
Well, actually is just the launch mode, because I get the same problem on webpack
Issue with incorrectly detecting Node is due to fact that VSCode runs as ElectronJS
process which creates process
namespace which normally doesn't exist in browser environments
This is now fixed in the main branch, but that was not a critical issue (result was that Human
was attempting to use incorrect backend, but then fall back to default works anyhow)
Core issue is HTTP Error code 204 "No Content" when downloading *.bin
files which comes between browser and Parcel
dev web server
I cannot reproduce that as it works correctly on my system - this is likely a WebPack
config issue, possibly a race condition where WebPack
is not ready to serve binary files by the time that browser tries to load them
Closing as user environment setup specific
the problem happens in both parcel and webpack🤣, but I guess they actually don't generate that problem, just the browser environment
Most likely it's the same problem - they are both extremely slow and dev server has not yet processed binary files for serving by the time browser requests files.
To prove, set baseModelPath config option to load models from my git pages instead.
Well actually in both cases the models are static, parcel and webpack are not touching the models/
folder, the only change is on the web files, both ignore the models/
folder
we can have a theoretical discussion but the fact is that HTTP code 204 is not normal. just try something like this to rule out (or confirm issue) webpack/parcel http dev server as root cause:
config.baseModelPath = `https://cdn.jsdelivr.net/npm/@vladmandic/human/models/`;
with that link works properly on PWA-Chrome
with config.baseModelPath = './models/'
is downloading the file with a save-as dialog
so its proven - your webpack
or parcel
are serving binary files incorrectly in a way that it confuses pwa-chrome
could be mime-type issue or something else, but in either case not related to human
code
Yes, in that case I guess is the serving files
Discussed in https://github.com/vladmandic/human/discussions/225