Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add self-learning suspend timer #616

Open
quantuumsnot opened this issue Oct 26, 2017 · 4 comments
Open

Add self-learning suspend timer #616

quantuumsnot opened this issue Oct 26, 2017 · 4 comments
Labels

Comments

@quantuumsnot
Copy link

quantuumsnot commented Oct 26, 2017

Noticed that not a single one of drop-down "minutes" options are working for me (my reading time is between 5min and hour-hour and a half, so this doesn't save traffic, only memory for a given N minutes). Is there a chance to add an automatic simple suspend timer based on mean tab defocus time?

@deanoemcke
Copy link
Collaborator

deanoemcke commented Nov 3, 2017

Can you give a bit more information on your proposition? Like some examples perhaps?
I do not understand what you mean by:

so this doesn't save traffic, only memory for a given N minutes.

And I also dont see the relationship between how long you spend on a focussed tab, and the time it should take to suspend a tab in the background.
Why would you want these two things to be the same?

@quantuumsnot
Copy link
Author

quantuumsnot commented Nov 3, 2017

I'll try ...
From a user's perspective it's cool to have the feature to automatically lower the CPU/memory usage when there's no actions in the browser or only one tab is active. Better UX, but the "issue" with this approach is in the average suspended time of inactive tabs. Users like me almost always read many and long articles combined with a shorter ones - expressed in time it is between 5-10 minutes to an hour in reading. This time doesn't help when in the middle of reading the user must switch to another tab to quickly check more info. What happens after that is the following:

  1. That another tab is already suspended, which leads to some pause (1-2 sec) before it reloads automatically and eats the same traffic again (people on mobile internet/platforms have traffic limit, which is unknown how much MB left they have). I propose it will be better to cache on the hard drive each suspended tab
  2. Sometimes this auto-reload doesn't work, in my case I should manually click, which is additional workflow breaker (especially for noob coders like me). But if the tab reloads I must again scroll to the page's area of interest
  3. Sometimes the page in the suspended tab is not reachable (for example connection issues on both sides), and if there's a information in some degree of importance for the current work of the user, he or she cannot proceed it. This is somewhat fixable with opening last known Google or WebArchive's page cache ... And yeah, it's possible to white-list all those pages, but because the user don't know information from which page is more usable, white-listing all new opened pages always means he or she must read them before deciding that. Also there are two clicks - usually long mouse travel to click TGS icon > Never suspend ...

So, I am proposing to add option to choose suspended time based on collected average suspended time per tab, plus enhancing it using classifier based on the type of the page (there's an exception, for example programming articles are from micro-size to a huge novel). This is possible with check for a specific words in <title>, or if there is another standardized section which explains what information the site provides

@deanoemcke
Copy link
Collaborator

  1. please refer to this open issue: Save suspended page locally #265

  2. this sounds like a bug (not always auto-reloading). Most probably it is caused by this issue: Suspended tab doesn't automatically unsuspend after closing another tab #519
    Also, there is already a feature that auto-scrolls to the same location on the page before the tab was suspended. so you shouldn't have to rescroll down like you are doing. This is a bug if so, and should be reported in a separate issue.

  3. this sounds like a repeat of issue 1? you would like to save the suspended tab contents saved to disk so that you can do an offline reload? that would make it irrelevant whether the page had become unreachable.

I'm sorry, but I am still not seeing exactly what issue you are trying to solve. The points you raise (1,2,3) do not relate to the tab suspension timer. Are you suggesting that the time to suspend should be based on how long a the user has a specific tab focused (while unsuspended)?

I can't see the relationship between the time a user spends READING a tab, and the time it should take for that tab to be suspended automatically in the background. Just because I have opened a tab that I will spend 10 minutes (on average) reading, does not mean that that tab should be automatically suspended after looking at OTHER tabs for 11 minutes..

@ossilator
Copy link

i think the general idea would be automatically clustering tabs and not suspending any while any tab in the cluster is focused.
however, that would require quite an insane effort to implement, so i'd defer to explicit grouping - by window, as proposed in #818. wontfix?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants