Configurable delay for automatic unsuspension

[ethans]

I want the unsuspend to be automatically when viewing the tab - but it should wait a couple of seconds before doing so (maybe make it configurable).

The reason being that if I'm just viewing all the tabs to see the titles - I don't want it to unsuspend immediately. Also, if you stand on a tab and click suspend - it suspends and immediately unsuspends.

[deanoemcke]

There actually already is a delay when switching tabs. However, it is currently set to half a second which may be too short for your purposes. The delay is intended to handle situations where a user is ctrl+tabbing through tabs to get to the one they want. Having this delay time configurable has been requested in another issue: #114

As for the automatic unsuspending of the current tab, that sounds like a bug that needs fixing. Do you mind if I update the title of this issue to reflect that bug, and leave the other open issue to deal with configurable delay times?

[ethans]

Sure, no problem.

The half-second is not enough. As I view that tab, I read the title to decide if this is what I'm looking for, and before I move to the next tab - it's being unsuspended.

Thank you

[deanoemcke]

Contrary to my comments above, I will leave this issue open as a feature request for a configurable delay time to automatic tab unsuspension.
I have created a new issue for the bug where you cannot suspend the currently focussed tab #274

[es6Test]

how do you set up automatic unsuspension?

[es6Test]

I don't like the extra click needed once you reach the tab

[deanoemcke]

@es6Test Check the option "Automatically unsuspend tab when it is viewed"

[pgarciacamou]

I think this is an excellent feature to have. Being able to modify the time it takes to unsuspend (the same way you can for automatically suspending tabs) is definitely a must-have. With so many tabs opened, it usually takes a few seconds to read the title shown by TGS (the great suspender) and know if that is the tab you wanted.

[liamjohnston]

@pgarciacamou but if you're taking the time to read the title before deciding whether you want to unsuspend or not, surely it'd be preferable to instantly unsuspend once you've decided you want it to unsuspend? i.e. clicking the tab / hotkey for refresh / hotkey for unsuspend.

Like if you had it set to 4 seconds, it seems like it'd be annoying if you identified the tab in say 2 seconds, but had to wait an extra 2 seconds for it to unsuspend...

[pgarciacamou]

@liamjohnston that is a fair point! Maybe having this would stress me out? Hmmm 🤔. Could that be avoided by having some type of UI progress-timer gradually showing the user the time left until reload?

You are a fellow FE dev, how do you have your settings currently? In my case, 20s to suspend (I love it suspending quick) and auto unsuspend. These settings work for me most of the time, except when switching modus operandum (viz. running out of coffee). Auto-unsuspend stresses me out because if I take 1ms more to know if that was the website I was looking for, I end up reloading possibly a heavy tab.

My suggestion is; if it is 500ms at the moment, why not allow the user to decide if they feel better with 501ms or 800ms, see what I mean?

[pgarciacamou]

Also, am I the only one that has "auto unsuspend" activated AND ends up reloading half of the websites when casually cruising through the tabs with the shortcut keys?

[liamjohnston]

@pgarciacamou [secret FED handshake]

I tried auto-unsuspend a long time ago and it wasn't for me. Other than that, I pretty much use the default settings! Though I could have a much shorter suspend timeout without it being an issue probably.

Each to their own though :D

Basically it boils down to the amount of settings on the screen. It's already grown a lot from its humble beginnings, and we don't want to cram too much in there. I don't think the demand warrants having another setting (unless this request gets a ton of upvotes I guess).

[pgarciacamou]

@liamjohnston

[secret FED handshake]

I didn't get it at first 😁

I don't think the demand warrants having another setting (unless this request gets a ton of upvotes I guess).

It was worth mentioning it, ¯\_(ツ)_/¯.

[deanoemcke]

I think there's room here to renegotiate the hard-coded delay before unsuspending a tab. The idea is that casually moving through tabs via alt+tab (or control+tab for mac) does not unsuspend all the intermediate tabs, only the one that you finally end up on. So the ideal delay time should ensure that none of these intermediate tabs unsuspend accidentally.

We need to keep in mind however, that some people will click with the mouse directly on the tab they want (or select directly via some other means such as command+number). These people will want that tab to unsuspend as fast as possible, as they know already that it is the tab they want, and any unnecessary delay will just be painful.

I'll add to this my own personal use of the 'automatically unsuspend' feature. I usually have it off, but sometimes i will switch it on when i'm working my way through a lot of suspended tabs one by one, usually closing each one as i go. In this use case, when i've closed the currently focused tab, the next suspended one automatically gains focus and unsuspends for me. As mentioned above, the shorter this delay is for me the better. This is exactly what I'm doing right now, as I work my way through all the github issues that need attention :P

[ossilator]

for ctrl-tabbing, the solution is (somewhat obviously) tracking the state of the ctrl key and unsuspending only once it is released, like the os' task switchers typically do with alt/meta.

an imo more usable alternative to speculative tabbing is getting a proper overview of tabs; see #560. but that doesn't impact the validity of the issue as such.