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
Users should be able to disable update checking, per-script #1423
Comments
But I don't see how extensions have the option to disable updating on a per-extension basis. Anyone? |
Whoops duh: in the "detail" view that you can only get to by double-clicking: the "automatic updates: default/on/off" radio buttons. |
I say we put a "Enable/Disable Updates" option in the context menu after "Find Updates". No sense using the detail view for this since we don't use it for anything else atm. |
I believe that the option on the detail page controls whether updates are applied automatically. I'm pretty sure that extensions always check for updates and there's no way to turn this off (unless there is some secret about:config option). Perhaps we should follow suit? What's the harm in just checking for updates? We could take the code you wrote for this issue and adapt it to turn off/on automatic updates on a per-script basis for #1442. |
The difference from my viewpoint is that is Mozilla, writing code that affects load on Mozilla's servers. In our case we're loading someone else's servers. And mostly userscripts.org, which AFAICT already struggles with load. So I'd like to add less, where possible. |
Since we plan on enabling update checking by default, most users probably won't take the time to turn it off or won't want it off so I doubt we would significantly decrease traffic with this feature. I also doubt update checking will put too much of a strain on userscripts.org. The majority of its past problems were cause by poorly written update checking routines in user scripts that would download the script source page (the actual HTML page not the .user.js file) every few milliseconds. At a minimum a script can only be automatically checked for an update once a day. That is a hard coded minimum. The only way around it is to edit the source and build GM yourself. When it comes to userscripts.org we only download the metadata of a script when checking for an update. For those who want to host scripts and keep bandwidth usage to a minimum, they can upload just the metadata (hell they could leave everything out except the I just don't think the small possible decrease in network traffic and bandwidth is worth the added complexity, both in terms of complicating the code and the complicating of our UI by providing the option to turn off/on automatic update checking and automatic installing of updates for each script. |
@sizzlemctwizzle, ... most users probably won't take the time to turn it off or won't want it off... This is probably true however taking this home... this script hasn't been updated since 2005 and still works in most situations... you'll also notice that the userid is no longer around yet the script still is... I can't attest to why the script hung around other than it does get installed and referenced in derivative scripts. In this instance I would absolutely want to turn off the automatic update check for this script since the ScriptWright has zero chance of updating the script at that scriptid. Other scripts that I use in my favorites towards the end of the list are rarely updated as well so I typically don't rely on any update mechanism other than USOs email notification. In general it's a good idea not to increase the traffic from the Clients perspective since data usage caps are increasing. to a separate url and point to it with
I was under the impression that this wasn't supported yet... is it? If the question/statement is "Why was this feature put in?" this is some of the reasoning why I like the availability of disabling script updates per script along with some scripts I, and many others, like to review before they are updated and put to use. |
@Martii I was under the impression that this wasn't supported yet... is it?As far as I know it's already supported. |
From: #1053 (comment)
The text was updated successfully, but these errors were encountered: