See  issue 868155  for some background on this.

you've lost me as to how crosh/Secure Shell could possibly support the life cycle API.

crosh, in Chrome's C++ code, launches a dedicated shell (/usr/bin/crosh) which in turn allows people to spawn any number of programs.  in dev mode, they could even run /bin/bash and then further spawn any process they want (and people frequently do).  it'd be _extremely_ complicated to try and track all of that state so we could kill it all to discard the tab, and if the user switched back, restore it all.  practically speaking, we can simply agree it's impossible and is never going to happen.  the CRIU group [1] has been working on this problem for a decade and still haven't fully solved it.
[1] https://en.wikipedia.org/wiki/CRIU

Secure Shell maintains a TCP/IP connection in a NaCl process.  without any browser support to maintain that connection when the tab is discarded, it's impossible to save/restore state.

looking at the lifecycle doc, the closest we might be able to get is Frozen.  if the tab is Frozen too long, the ssh connection will often be automatically broken by the remote side forcing the user to reconnect, and user attempts to use settings like KeepAlive wouldn't help (since the client is unable to send those periodic pings).

the fact that a user has launched crosh/Secure Shell in the first place is a pretty strong signal imo that they care about the session.  i could improve Secure Shell so that it sets autoDiscardable=true when the connection breaks (e.g. the remote side closes things or the network resets), but i'm not seeing much movement beyond that.

Yeah, the lifecycle API itself doesn't provide any functionality that would help with this. However, would it make sense to move the core logic to a service worker?

The intent of the lifecycles effort is to provide all the basic app functionality in a SW without needing a full renderer and a DOM, etc. If the connection and basic screen state lived in a service worker (or the background process of an extension), the dedicated tab could be discarded without losing state and connection.

if a worker has access to the same resources as the main app (i.e. networking), i think it would be feasible to implement that.  at the very least, we could have the connection/process be in a sep thread and let the hterm/scrollback be discarded w/out breaking the connection.

separating the scrollback would be a bigger undertaking, but would be feasible.

i don't think i'll tackle this for the existing NaCl design.  since we want to move to WASM, and that'll necessitate a bit of architecture rework, i'll try to fold that in at the same time.

i don't think service worker is what i want though.  isn't that more for dealing with network/offline requests ?  seems like a plain web worker is more in line with what we're after.

Yes, in your case a plain old web worker makes more sense. Also note that this is pretty low priority for now as the discarding API is a good work-around for now, and barring that, we can also put a blanket exception in place for chrome-extension:// urls.

it's not entirely clear from that summary page or the w3c spec ... this life cycle API only affects the main process right? web/service workers don't go through the same thing? if they're guaranteed to stay alive, it's worthwhile, but if they can get reaped too, then doesn't seem to gain much to support it.

Service workers are to stay alive, but they are event driven and not persistent (ie, they spin up occasionally to do some work). I'm not sure about web workers and the like. Agreed that if there's no additional persistence for workers that this doesn't offer any particular benefit and wouldn't be worth working on.

+panicker for input

Yes web workers will be (eventually) in the same lifecycle state as the parent page / frame and won't have special privilege to stay alive.

I agree that service worker does not seem suitable for this type of networking activity either.

<<if the tab is Frozen too long, the ssh connection will often be automatically broken by the remote side forcing the user to reconnect
What exactly is "too long", I wonder if our periodic unfreezing for frozen pages will suffice?

for regular TCP/IP connections, 5min would probably be the very outside of "too long" by default. it's possible for the network to be even shorter though which is what the ssh keep alive flag is for. if the user sets that flag, it's a pretty strong signal they don't want it being frozen longer.

if web workers are also going to be killed, then I don't think it's possible to support the life cycle API. saving and restoring both ssh state and network connections is an extremely complicated project, and impossible without browser support (since it's going to close the socket on us, or we're not going to get the same handle again).

which means enforcing the life cycle API on the ssh app (or really any app that wants to maintain a network connection) is going to break it and users are the only ones who suffer.

I was referring to making it resilient against freezing (and resuming when user revisits), I understand that handling discarding is very complicated (and likely not worthwhile).

If we have a sense of how frequently the network access is needed (eg. every 10s or every 1min or whatever) it might be worth considering how freezing heuristic could accommodate it.
Currently tabs are unfrozen ~6s every 10mins (or something) which is likely not sufficient.
  

yeah, 6s every 10min won't work.  that might not even be long enough to finish processing network requests let alone UI updates.  10s/1min should be good enough today.  we should be able to extract the rate the user wants though via the ssh keep alive settings and pass that back up ... somehow.

i hesitate making suggestions for API changes that involve calls only available to extensions as there has been a drive to do a PWA with WASM.