If the browser operation is interrupted abruptly, the Server will only see that the streaming connection is broken; hence, it will close the Session in short time, as soon as it tries to write something (possibly a keepalive packet).
In principle, it is possible that an intermediate node keeps the connection open even if the browser has closed (and becomes itself the client, on behalf of the browser). We currently don't handle this case and the Server keeps streaming until the content-length is consumed, but it doesn't seem to be a common case.

If the browser is interrupted while no request is under processing (for instance, in polling mode, between two subsequent polls), the Server is totally unaware and will keep waiting for a client action and will close the Session after the related timeout.

Upon session closing, notifySessionClosed is invoked on the Metadata Adapter.
If wantsTablesNotifications had returned true for that session, then notifyTablesClose is also invoked, before notifySessionClosed, once for each currently subscribed table.
If the involved unsubscriptions cause some item not to be requested by any client, then unsubscribe is also issued to the Data Adapter for each of them. All the latter calls are concurrent with one another and with respect to the Metadata Adapter calls.