You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The terminate method only has an effect on a presentation connection whose state is connected.
I think a common scenario for calling terminate is when the controlling browsing context is about to disappear or when the user clicks on a button, to clean things up, regardless of the current application state.
This is what we try to do in the test suite for instance, so that subsequent tests start from a clean "no on-going presentation" state. However, since terminate only works on connected presentations, terminating a presentation no matter what turns out to be more complex that simply calling terminate, leading to code such as:
// Try to terminate the presentationconnection.terminate();// If state was "connecting", previous call did nothing,// wait for the "connect" eventconnection.onconnect=()=>{connection.terminate();};// If state was "closed", we need to reconnect first. This will return a// presentation in "connecting" state. Previous event handler will eventually// take care of it if it's the same "connection", but it may not be.if(connection.state==='closed'){request.reconnect(connection.id).then(c=>{c.onconnect=()=>{c.terminate();};});}
I'm wondering whether the user agent could take care of some of that complexity, ideally so that developers can end up with a simple connection.terminate() call. This would require relaxing the terminate algorithm so that:
It also applies to connections in the connecting state. The user agent would wait for the underlying connection to become connected.
It also applies to connections in the closed state. The user agent would attempt to reconnect the underlying connection before it terminates it.
The latter change may be more problematic, and it seems reasonable to expect applications to deal with connections in the closed state themselves. The former change seems easier and useful. If both changes are in place, developers can just issue a call to connection.terminate() and be done with it. If only the former change is in place, developers would have to write something like: