Page reload behavior in browser

[csik]

Hi, thanks as always for the help. I'm curious about page refresh behavior in a browser. When running Domterm, I can open multiple windows across browsers successfully, but if I reload one of the browser tabs DomTerm quits.

starting application: /bin/bash session:1 pid:8 pty:13
run_command /bin/bash after fork child:0
unable to find record matching 'favicon.ico' 14
HTTP connect from 172.17.0.1 (172.17.0.1), path: /favicon.ico

____________________________________reload in browser_____________________________________

unlink_tty_from_pty_only p:0x555d98740720 w:0x555d987412e0 t:0x555d987416f0
- close pty pmode:0
callback_pty LWS_CALLBACK_RAW_CLOSE_FILE cmd_sock:-1
exited application for session 1
sending signal 1 to process 8
process exited with code 1 exitcode:0, pid: 8
before maybe_exit status:1 exited:0 statis:0
maybe_exit 0 sess:0 cl:some
 -- [wsisrv|9|adopted] (9) 3.821s
tty_client_destroy 0x555d987416f0 conn#1 keep:0
client #:-1 disconnected
maybe_exit 0 sess:0 cl:none

This may be expected behavior but I wanted to check before asking my next questions. I'm not sure why it behaves this way rather than forking another child, for example.

[PerBothner]

Note you can explicitly disconnect a window from a session. In that case the state is saved in the server before the window is closed, and thn you can re-attach later.

The question then is how to detect and recover from accidental disconnect. I've mostly been thinking in terms of remote session, where you might lose a network connection. However, accidentally closing a window can be annoying locally, too. Reloading a window will effectively first close the window and hence the session.

If using Electron/Qt or simil;ar, "refresh" isn't an issue so dealing with this isn't a priority. For now I'd say "don't refresh the browser window" - it doesn't really make sense.

If theer are multikple open sessions, and you accidentally reload one, at we do want to be able to continue with the other sessions. If that isn't happening, we should fix it.

"I'm not sure why it behaves this way rather than forking another child, for example."

There is a tradeoff: What should happen to the domterm server when all clients and sessions are closed? Should the server exit, or keep running in the background, waiting for new requests? I think having the server exit makes it behave more like a normal terminal emulator, which has been a goal. A "keep-running" mode could be useful, but mainly as a public server, I think.

[csik]

Thanks for discussing this. Yes, I'm essentially trying to emulate a web site through the terminal and commandline; I had previously used Butterfly to do this but it was never very good at supporting multiple browsers and eventually atrophied. But I think this should be possible even with a normal terminal emulator approach.

Indeed, it does seem that if there are multiple tabs open now, one refresh doesn't kill the others, and all can refresh successfully if there is at least one tab open. This is nice because it also allows for a "back" (albeit stateless) functionality as long as one instance is open somewhere. I'll keep hacking at it. Is this the appropriate channel for asking questions about development and deployment?

[PerBothner]

I don't understand what functionality you want from the Back or Refresh buttons, except maybe graceful recovery from accidental pressing?

"Is this the appropriate channel for asking questions about development and deployment?"

I think so. There is a DomTerm mailing list, but it isn't used. maybe when I get more users ...

[csik]

Yes -- that is precisely what I'm interested in -- graceful recovery. Here's the timeline of how I got here, and why #97 and this are related: I was using chrome, and left-clicking any link would go to a new page. This would kill domterm. Pressing the "back" button would then get to an error page.

For my application (essentially a terminal-driven version of a web site) I'd like a) people to be able to click through with a _blankesque experience, so the original window remains open [perhaps ideally with some administrator control over how this works], and b) in an inadvertent reload or window close, be able to keep domterm available quickly.

Where we're at (thanks to your patience): 1) Ideally this direct navigation from left-clicking would not be an issue going forward. It works better in Safari and Firefox currently, but I'm guessing you'd want it working on all major browsers. 2) It might be possible at the least to spawn a headless session on the server along with the requested one for some period of time, if necessary, to keep domterm open if necessary. Or to keep a supervisor going.

I'm still very much in the dark about how I would deploy this -- would I want to set a max number of children for any one demterm instance? Create a domterm instance for each unique user and manage the equivalent of sessions? This would not be a very high traffic site... but I'm still learning a lot about the basics.