You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Nov 15, 2017. It is now read-only.
Repository navigation
This repository was archived by the owner on Nov 15, 2017. It is now read-only.
This hasn't been relevant so far since you have been releasing new versions very frequently. But as you mentioned some days ago, "the pace at which features are added will markedly slow down". As it is a sure bet that many HTTPSB users will not remember to manually update those lists at regular intervals this could lead to outdated lists particularly for unexperienced users or users who use HTTPSB as a mere adblocker.
That's why I think that an automatic update mechanism for those lists becomes important in the foreseeable future.
Alright, I've put in the required infrastructure and required code hardening (we do not want users to be left without protection if update fails).
Now what is left is a recurrent check of remote assets to see if an update is required. One thing which bothers me is that when we reload all the assets, memory footprint baseline go up, and as far as I can tell this is not because of any memory leaks but simply how the browser works.
One can see this by repeatedly forcing a reload of ubiquitous lists by making one-line changes in the "Your block rules" text area. Memory baseline of HTTPSB will go up without going back to its boot baseline after garbage collector does its work.
I picture a user leaving his browser open for days, many updates occurring, etc. Eventually this could lead to scary memory footprint figures I imagine. I am not looking forward for scary reports of HTTPSB being a memory hog... That the browser doesn't return all released memory is out of my control.
One solution is to force a reload of the extension after assets are updated, but then this raises another issue which is that all temporary changes will be flushed, and all opened tabs will have their matrix content being emptied while the user might be in the middle of something.
You're right, I am not fond of yet another setting.
I think the once-per-week update is a good compromise. I will go this route. I forgot to mention there is now code in there which will cause the updates to be downloaded if needed when the extension launches, as this is a safe time to do it -- updates are done before loading the assets, so memory baseline should not be affected.
So this means if somebody always quits the browser before one week has elapsed, auto-update will never kick in while the browser is used, updates will occur only at launch time.
Activity
will be needed for #334
hardening update code for #334
more work toward #334
gorhill commentedon Jun 14, 2014
Alright, I've put in the required infrastructure and required code hardening (we do not want users to be left without protection if update fails).
Now what is left is a recurrent check of remote assets to see if an update is required. One thing which bothers me is that when we reload all the assets, memory footprint baseline go up, and as far as I can tell this is not because of any memory leaks but simply how the browser works.
One can see this by repeatedly forcing a reload of ubiquitous lists by making one-line changes in the "Your block rules" text area. Memory baseline of HTTPSB will go up without going back to its boot baseline after garbage collector does its work.
I picture a user leaving his browser open for days, many updates occurring, etc. Eventually this could lead to scary memory footprint figures I imagine. I am not looking forward for scary reports of HTTPSB being a memory hog... That the browser doesn't return all released memory is out of my control.
One solution is to force a reload of the extension after assets are updated, but then this raises another issue which is that all temporary changes will be flushed, and all opened tabs will have their matrix content being emptied while the user might be in the middle of something.
Bit of a dilemma here.
gorhill commentedon Jun 14, 2014
You're right, I am not fond of yet another setting.
I think the once-per-week update is a good compromise. I will go this route. I forgot to mention there is now code in there which will cause the updates to be downloaded if needed when the extension launches, as this is a safe time to do it -- updates are done before loading the assets, so memory baseline should not be affected.
So this means if somebody always quits the browser before one week has elapsed, auto-update will never kick in while the browser is used, updates will occur only at launch time.
this concludes fix to #334
gorhill commentedon Jun 15, 2014
Fixed with latest check in. Will be in 0.9.8.0.