SSH connection closes when in an inactive tab for too long |
|||
Issue descriptionChrome Version : 70.0.3538.22 OS Version: 11021.19.0 Secure Shell App version 0.8.45 URLs (if applicable) : What steps will reproduce the problem? 1. Use the Secure Shell extension 2. Establish an SSH connection to a server 3. Go to other tabs and do a bunch of stuff (time varies, maybe for 30-60 minutes) 4. Go back to the sshd tab What is the expected result? The SSH connection should still be active, and I should be able to use it What happens instead of that? The SSH tab does not respond to keypresses, indicating that the connection is no longer live. In order to resume working, I now need to refresh the tab and log in again. I specifically disabled "Auto Discardable" for that tab in chrome://discards. Please provide any additional information below. Attach a screenshot if possible. UserAgentString: Mozilla/5.0 (X11; CrOS x86_64 11021.19.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.22 Safari/537.36 Secure Shell App version 0.8.45
,
Sep 24
,
Sep 24
Yes, has the issue occurred at the point of the screenshot you provided? If so, this is related to freezing and not discarding, which is a slightly different feature. To double check the discard is disabled as expected, can you hove over the "View reason" text in the associated "Can discard?" column, and provide the text that is there?
,
Sep 24
Got it again, this time the status is "hidden". (This time, it was after switching my Pixelbook from using HDMI to the built-in output and then using gvc for 30 minutes). "Can protect" says "Tab has been protected by an extension".
,
Sep 24
Great, so we've confirmed that the discarding logic appears to be working correctly (zero discard count, can discard? says "no" for the right reason). If this is indeed from a period right after the extension stopped working then this is due to freezing not working as expected, and is another issue entirely. Can you confirm that the information you've provided is from a moment directly before or after the connection has been dropped? Also: we could try another experiment to force the issue: (1) Open an ssh tab and connect to something. (2) Open another tab to chrome://discards, and make sure the ssh tab is not visible (3) Force the SSH tab to transition to the "frozen" state from the chrome://discards UX. (4) Wait N minutes and switch back to the SSH tab and see if the connection is still up. Freezing basically stops processing all Javascript, so it could be that some piece of logic somewhere thinks the tab isn't responding and kills the connection. We actually wake the tab up on a 1% duty cycle, but we might need to refine that logic. Knowing the number of minutes N after which the bug produces could be helpful. (I've been doing this on a local machine and haven't managed to get the connection to drop. There might be other issues at play here, like the remote server configuration, or some OS specific issue. Having you run the same experiment could be helpful.)
,
Oct 1
Any news here? I haven't been able to repro locally...
,
Jan 11
This issue has an owner, a component and a priority, but is still listed as untriaged or unconfirmed. By definition, this bug is triaged. Changing status to "assigned". Please reach out to me if you disagree with how I've done this. |
|||
►
Sign in to add a comment |
|||
Comment 1 by sebmarchand@chromium.org
, Sep 24Owner: fdoray@chromium.org