terminal
terminal copied to clipboard
HeyPuter
Terminal not loading in some browsers
As reported by this user.
Chromium Version 123.0.6298.0 (Developer Build) (64-bit) from tip-of-tree developer builds today. On Linux.
Screenshot at https://gist.github.com/guest271314/94453a1f538df44be1623f75b0ed4b71
It would help if you didn't try to prevent inspecting the page.
There are several warnings and a couple errors thrown
v2/:4 WebSocket connection to 'wss://api.puter.com/socket.io/?auth_token=undefined&EIO=4&transport=websocket&sid=9uLAXMZ0SsMnkBVsAHNF' failed: WebSocket is closed before the connection is established.
bundle.js:10622 Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'setAuthToken') at window.main_shell (bundle.js:10622:28)
This means globalThis.puter is undefined, which is unexpected. Is it possible the Puter SDK doesn't work properly in this version of Chromium?
I still haven't been able to replicate this
I'm on Linux. Chromium Version 123.0.6298.0 (Developer Build) (64-bit) off tip-of-tree builds from a couple days ago.
Do you have any privacy extensions? The terminal uses canvas and it's known to be blocked by some extensions because some websites seem to abuse canvas (idk how they do it though)
Does this occur on the stable build of Chromium too?
(idk how they do it though)
AFAIK, WebGPL rendering and then analyzing GPU-specific behaviour. It's wild.
The terminal uses canvas
AFAIK, WebGPL rendering and then analyzing GPU-specific behaviour.
Why are you using canvas and WebGPL for this?
QuickJS and SpiderMonkey has been compiled to WASM for use as a JavaScript runtime in the browser - without using any images. See https://bellard.org/jslinux/ and https://github.com/mozilla-spidermonkey/sm-wasi-demo. node has even been compiled to WASM using v86 https://github.com/cemalgnlts/now.
Is the idea to send data over the network for this and render images that just look like a terminal and other applications?
Just use a <textarea> or something.
Why are you using canvas and WebGPL for this?
We don't do this; xtermjs does this. (edit: I don't believe xtermjs uses WebGL; I was mentioning that in different context; it does use canvas though)
Is the idea to send data over the network for this and render images that just look like a terminal and other applications?
phoenix aims to be a complete POSIX-compliant shell. We're still pretty far away from that goal but there's a clear roadmap. We're absolutely open to including javascript runtimes in Puter - one thing we need to do first is enable phoenix to run external commands (it will process script files but it doesn't retrieve commands from PATH yet)
Just use a
I understand where you're coming from, because it's just text right? The trouble is, terminal emulators are actually emulating the VT100, and getting consistent behavior across different browsers to emulate this in a textarea would be incredibly difficult, if even possible. I think xtermjs made a good choice using canvas.
Unable to reproduce on Version 123.0.6304.0 (Developer Build) (64-bit) from the chromium-snapshot-bin AUR package.
Can you post a screenshot of you writing to the terminal application and DevTools on Chromium 123?
I got it working launching a new instance without the flags I ordnarily have set. Now I'm going through the flags one by one to see which one makes your application not work.
$HOME/chrome-linux/chrome --user-data-dir=test --disable-gpu --disable-gpu-program-cache --password-store=basic https://puter.com/app/terminal
Looks like when --disable-features=ThirdPartyStoragePartitioning is set your terminal application doesn't work.
The following errors are thrown
https://puter.com/dist/images/ui-icons_444444_256x240.png
Failed to load resource: the server responded with a status of 404 (Not Found)
Uncaught DOMException: Failed to read the 'localStorage' property from 'Window': Access is denied for this document.
at new <anonymous> (https://puter.com/puter.js/v2:4:125721)
at https://puter.com/puter.js/v2:4:124377
at https://puter.com/puter.js/v2:4:129314
at https://puter.com/puter.js/v2:4:129318
bundle.js:10622 Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'setAuthToken')
at window.main_shell (bundle.js:10622:28)
Good catch! I had a suspicion that third-party "something" would be involved. Although it seems to be in the opposite direction I'd expect; third party partitioning enabled should be more restrictive right? We'll have to investigate this more but this was a huge help, thanks for finding that.
I dtarted using that flag because something changed in Chromium source code where I was embeddeding an iframe point to a browser extension in arbitrary Web pages and streaming data, see https://github.com/guest271314/persistent-serviceworker/issues/3#issuecomment-1407825606.
and getting consistent behavior across different browsers to emulate this in a textarea would be incredibly difficult, if even possible.
It's possible. Multiple ways. Just use the <textarea> as input, send the command on ENTER.
Here is one way to send arbtritrary commands from the browser to node (STDIN) and stream STDOUT https://github.com/guest271314/fs/blob/main/nodejs/fs.js. See the Deno and Bash versions in the repository.
Another way, that is specified, is using Native Messaging https://github.com/guest271314/NativeMessagingHosts.
Just use the
I could just as well say "just use xtermjs". The textarea input handling is still not trivial, considering:
ctrl+<left|right>works in a textarea, but the behavior (decision of where word boundaries are in particular) could vary depending on the browser or operating system. I suspect this could be manually overridden but with quirks in some browsers- some default behavior needs to be overridden; ctrl+c shouldn't copy, etc
- selecting text with the mouse in a terminal emulator typically does not affect the cursor position
Although it turns out performance is one of the benefits of using canvas, whereas I just assumed it was more the other things I just mentioned.
@jelveh this is the culprit (when the flag mentioned before is enabled):
v2:4 Uncaught DOMException: Failed to read the 'localStorage' property from 'Window': Access is denied for this document.
at new <anonymous> (https://puter.com/puter.js/v2:4:125721)
at https://puter.com/puter.js/v2:4:124377
at https://puter.com/puter.js/v2:4:129314
at https://puter.com/puter.js/v2:4:129318
puter.js should wrap every call on localStorage in a try...catch and assume that access might not be allowed. Although most people aren't likely to have this flag set, a page on chromium.org says this issue will also occur if the option "Block third-party cookies and site data" is enabled from the normal settings page.
It should be possible to render a real terminal in the browser. Chrome's Native Client used the <embed> or <object> HTML element to post messages between the nexe and the browser.
I'm skeptical of using images for text and arbitrary data streaming to the browser. However it doesn't look like this is intended to be a real terminal with host read, write, executable capabilities. That's my interest in terminals in the browser. That's what I've been doing using Native Messaging and other means.
Re
puter.js should wrap every call on localStorage in a try...catch
I would suggest substituting using WHATWG File System and using origin private system to write directories and files rather than localStorage.
Re
puter.js should wrap every call on localStorage in a try...catch
I would suggest substituting using WHATWG File System and using origin private system to write directories and files rather than
localStorage.
We're not using localStorage for that, Puter's API provides a filesystem powered by our backend technologies.
I see. I generally block third-party cookies and site data, too, in addition to --disable-features=ThirdPartyStoragePartitioning. Good luck with your project!
Chrome is getting rid of third party cookies anyhow so we're not relying on them anymore