thegreatdiscarder
thegreatdiscarder copied to clipboard
Prevent discarding tabs w/ unsaved form input?
Sorry if this has been addressed somewhere; I searched for an answer but couldn't find any.
Isn't there a way to prevent TGD discarding tabs with form inputs (like TGS)?
I am switching to Discarder and am really interested as well.
@deanoemcke if you point me to where the functionality is coded in the Great Suspender I can take a look and try to port it here, via PR. (no idea if I am able to do it, though 😅)
Also I'd like to see if I can add a couple of other features here.
The two projects have diverged quite a lot unfortunately. Out of curiosity, why have you decided to switch to Discarder? And did you know that there is a secret flag in the new version of The Great Suspender that makes tabs discard instead of suspend? If you go to the options page of TGS and change options.html to debug.html you will see a link to make this change. Perhaps the best thing to do with this project is refork TGS and make this hidden option a forced setting.
@deanoemcke Quick question what is the difference between suspended and discarded tab ? 🤔
Any advantages/disadvantages of one on the other ?
Regards :octocat:
@mikhoul
Discarding is chrome's native way of unloading a tab that it thinks is not important. it only happens when you're running really low on memory. if you focus on a discarded tab it will reload immediately. you cannot control what or when tabs will be discarded. Extensions cannot communicate with discarded tabs directly (via content scripts).
Suspending is the word I use to describe what I do with the Great Suspender. Which navigates a tab away from it's original URL to a local extension one. The local file that gets loaded in place has very little DOM and javascript running which essentially frees up a lot of memory and possibly CPU.
I can't say exactly how discarding works performance-wise but I suspect it does a pretty good job. The Great Discarder was supposed to leverage this native discarding ability but allow it to be customised as to what tabs get discarded and when.
But discarding has the downside of automatically reloading when the tab is visited. So it doesn't appear to be as useful to most people. Although it probably is actually better so long as you dont mind the auto-reloading functionality.
Out of curiosity, why have you decided to switch to Discarder?
I am a serial tab hoarder, with hundreds of tabs. My problem with Suspender is it makes Chrome unusable when doing operations over tens/hundreds of tabs. CPU goes to 100%, filled by TGS and Browser processes (not sure about all the operations that happen there).
I thought to take a look at the code, maybe profiling, and help with performances... but then via Github.com I stumbled upon Discarder, gave a try and saw the direct performance improvement; so in the end I didn't even look much at Suspender code 😅 Except the google analytics stuff; and being Discarder almost without it, I preferred it; without considering that it has an overall minor quantity of code to read/understand (that makes a difference, when I am willing/hoping to contribute 😜).
Also, I believe going for the native way is the best approach (even though your Suspended approach is a good and compatible idea; and sustainable in the future). So, again, a point more to Discarder.
And did you know that there is a secret flag in the new version of The Great Suspender that makes tabs discard instead of suspend?
I totally didn't know 😂 That's great!
Although trying to go to debug.html didn't work for me: ERR_FILE_NOT_FOUND
, even I can see it in the repo 🤔
Looks like I can't access other files than options.html, via direct URL (I am a noob with extensions, but maybe the manifest could need some additions?)
Perhaps the best thing to do with this project is refork TGS and make this hidden option a forced setting.
Dunno how much TGS and TGD differ in the code. I am always reticent in throwing away code that could be useful 😁 But if you feel you'll keep implementing discarding in TGS (or even giving it priority over suspending) then yes, could make less sense to keep duplicating work in here (even if TGD has the sweet part of being overall lighter)
ADD:
tried to clone TGS and "Load unpacked" it. With this I can access the debug.html page. With the the official extension from the Store I can't 🙄🤔
Would the cloned&loaded version retain my suspended tabs, if I leave that on and disable TGS that I got from the Store? If yes, I'll switch to it (since I could also play with the code)
Thanks for the explanation @deanoemcke
I love TGD I don't mind relaoding since Chromium is fast and I use a lot the context menu to put exceptions for short and long term.
You should put the latest version with context menu in the Chrome store, I've load it as unpacked extension but lot of users don't know how to do it.
Thanks again for this useful extension :octocat:
@Pictor13 the CPU usage issues you report are most likely due to a temporary bug in the latest release of The Great Suspender. It should be fixed within the next 24 hours (or less).
Not sure why you're having problems accessing the debug.html page on the webstore version. It should have no issues. Are you sure you're on v7 of the webstore copy of TGS?
As for the codebase between TGS and TGD, I'd like to say I'm confident that the TGS version should be more performant and have less bugs. I just tested out using the secret tab discarding feature of TGS and it seems to work really well. You can even combine it with tab suspension if you want, meaning that after tabs are suspended, they also then get discarded. It's a bit overkill, but at least it allows you to revisit a tab without it reloading (well actually the suspended tab reloads instead) and still gives you the supposed benefits of native tab discarding.
I think the ideal way forwards is to keep The Great Discarder as a fairly up-to-date fork of The Great Suspender, and maybe try to automate the process somehow of removing or disabling the features that are not applicable to this project.
@mikhoul As mentioned above, it would like to push a new version of this project to the webstore. But it will probably involve a new fork of the current TGS codebase.
@deanoemcke Yes I figured out the advantages of the combo suspended+discarded! 😄 It feels good, good compromise, and looks like the way to go. Would be great if that would even reduce the memory use by TGS itself! (have to check)
As an idea, the suspended page could also keep information about eventual state to restore; e.g. the position of playing videos (I think Chrome itself doesn't support it atm). Restoring page state is a concern where there could be improvements. Even though its difficult to cover all cases (like restoring state for a complex webapp) and is not direct responsibility of TGS.
I also thought about improvements of this combo, for when moving through tabs with CTRL+(SHIFT)+Tab: discarded gets reloaded on activation, but if the user is just skimming and passing quickly to the next tab, then the re-activated&suspended tab could be re-discarded, when it doesn't remain active. I can try to put down and try some code, and submit it to you to evaluate it.
Regarding the webstore version unable to access debug.html, I can't figure out why ... I'll backup my tabs and try to reinstall TGS (as info, I'm on Chrome 68.0.3440.106). Or just switch to the repo cloned version (I thought, maybe that's a limit of packed extensions?).
Btw I'll test the new version and the CPU usage. However, I noticed the repo bug, but except for that and its fix, I don't exclude that when loading hundreds tabs at once the CPU hog could be caused by other extensions (like Ghostery or AdBlock+).
About TGD, yes could make sense to fork and disable features. Not sure if it would be less work though. At that point it could be done (with some option flags) directly in TGS, without the hassle of maintaining two repositories rather than one (cause in the end they are two different version of the same idea/software).
Removed TGS, reinstalled from WebStore. Now I can access debug.html :) There's a little bug there: can click flags on top just once; to restore the previous value have to refresh the page and click again (not a big issue though).
@Pictor13 in regards to storing page state, yeah it's a bit of a tricky beast to tackle. i think that ultimately it's the job of the webapp itself to handle that. talking to google, i think they mentioned that they do try to handle some of that with the tab discarding. as for youtube video position, TGS has implemented that in the latest release :)
for the ctrl+tab issue when quickly passing through tabs, TGS has some detection where it won't consider a tab as 'focused' unless it retains focus for more than about 200ms. unfortunately, the reloading of discarded tabs does not have a similar feature and it's out of my control to change.
however, if you have the 'discardAfterSuspend' option set, you should notice that i have implemented something similar to what you have suggested. with that option set, after a tab gets suspended, it will then discard the suspended tab. if you then revisit that tab (either briefly while tabbing through or for a longer period of time) then tab will undiscard (which means reload into a suspended tab). BUT, once you lose focus from that suspended tab, it will RE-DISCARD itself. essentially undoing the reload that was caused by the tab focus and returning the suspended tab into a discarded state.
i hope that makes sense. it's a bit random to have both suspending and discarding enabled, which is why i've kept it as a hidden debug option. but it's fun to play around with :)
finally, in regards to the future of TGD. i did some re-reading of the code for TGD last night, and it seems that i changed it quite significantly from even the old version of TGS. most significantly, TGD operates as an event based extension as opposed to having a persistent background page like TGS does.
i'm not sure the best way to go forwards, as TGS has a lot of changes I'd like to port to TGD, but i'd also like to rewrite TGS to be event based like TGD is. :shrug:
perhaps letting both projects go completely separate ways is the best approach. i'll look into it more when i have the time.
also @cygvis sorry about hijacking this issue thread. in regards to your initial question, TGD currently does nothing to prevent the native chrome discarding behaviour from happening. Which means that if you're low on memory, it may well discard a tab that has unsaved form input.
the latest release of TGS has some new functionality where it will update the autoDiscardable
flag of a tab to prevent chrome from natively discarding it if TGS detects it has unsaved form input.
This functionality should be able to be programmed into TGD without too much hassle.
TGD operates as an event based extension
It will be better for CPU/memory since the "things" will run only when they are really needed.
Regards :octocat:
storing page state, yeah it's a bit of a tricky beast to tackle. i think that ultimately it's the job of the webapp itself to handle that. [..] as for youtube video position, TGS has implemented that in the latest release :)
Oh, didn't have the chance to try yet, but that's great! For the rest, yes, the webapp should maintain itself.
for the ctrl+tab issue when quickly passing through tabs, TGS has some detection where it won't consider a tab as 'focused' unless it retains focus for more than about 200ms. unfortunately, the reloading of discarded tabs does not have a similar feature and it's out of my control to change.
I didn't check your code yet, but I thought about having a (probably even longer) timer like you said and re-discard the tab. I think is doable with discarding too, but needs some decent heuristic (without being annoying to the user). I am interested in having such a future so maybe I'll play with TGS and spend some time (when I'll have it ^^) to try to implement/improve this behaviour if I get some nice insight.
however, if you have the 'discardAfterSuspend' option set, you should notice that i have implemented something similar to what you have suggested
Yes, I was pleased to see how suspension and discarding work nicely together. I'd say that its my favorite approach (even if it might feel hacky/dirty to other users).
BUT, once you lose focus from that suspended tab, it will RE-DISCARD itself. essentially undoing the reload that was caused by the tab focus and returning the suspended tab into a discarded state.
Because of the timer mentioned above? However, I think that's a fair/decent behaviour (I personally don't mind small reloads/unloads).
i hope that makes sense. it's a bit random to have both suspending and discarding enabled, which is why i've kept it as a hidden debug option. but it's fun to play around with :)
Yeah totally makes sense :) As I said it's my favorite behaviour; but I like dirty things 😅 And can imagine makes debugging less predictable.
i'm not sure the best way to go forwards, as TGS has a lot of changes I'd like to port to TGD, but i'd also like to rewrite TGS to be event based like TGD is. :shrug:
Yes I like more the event based way and I support the TGD-way; even if in my experience events tend to be more annoying to debug.
Anyway thanks for your amazing and passionate job. If I manage to prioritise my time I'd like to try some things and help with the extension(s). Atm I am busy trying (not directly on your extensions, yet) how can I load big (huge) tab-sessions without stalling the browser/CPU and make it work better with discarding. But that's OT and yes, I should stop making this issue so dirty ^^
To come back in-topic, @cygvis I can say that I saw sometimes the discarding to work good with inputs and restore their content; so there should be some minimal support. But maybe the loss is more when there are more complex inputs (WYSIWYG or other widgets) where is difficult to restore a correct value (maybe try the new deanoemcke version of TGS to see if plays as you wish).