I am not sure if there is really a need for it. It would not likely be used by normal users in normal circumstances except by advanced users (during testing). This may cause performance issues in browser when there are too many sites. Either way I really don't really see the need for an inputbox in the preferences page to customize the timeout. New users may get confused and unknowingly break the GW. If a there is really a need for this, a hidden config should be implemented and it would need to be manually added to the global.js.

@IKhitron are you having any problems with the current setTimeout value? I am curious to know why you need to jump to 600000ms.

Do not care how. And there can be a hardcoded minimum of 7500. But one can't use live updates on mobile with this value, exactly from the same reason I can't use rcfilters.

In T245312#5886320, @Masumrezarock100 wrote:

@IKhitron are you having any problems with the current setTimout value? I am curious to know why you need to jump to 600000ms.

Just answered why.

In T245312#5886321, @IKhitron wrote:

But one can't use live updates on mobile with this value, exactly from the same reason I can't use rcfilters.

Honestly I mainly use mobile and I never ran into any problem when using GW. The problem is likely either with your connection or browser. GW users are expected to have a fast enough internet connection since it mostly render the watchlist client-side. You also said that you are having trouble with filters in RC feed, which is a built-in Mediawiki feature with cross-browser compatibility. I suggest you to move to a fast connection.

Exactly. Not all the users have money for fast connection or for enough data usage limit. I have 4G on a good Galaxy, and clicking on Refresh makes the global watchlist disappear for 3 to 25 seconds. And I have only 10Gb montly, so I can't spent it for api calls every 7.5 seconds, when I do not need this data more than once in 10 minutes.

And about the rc-filters - the mobile need reboot after a couple of minutes.

In T245312#5886349, @IKhitron wrote:

Exactly. Not all the users have money for fast connection or for enough data usage limit. I have 4G on a good Galaxy, and clicking on Refresh makes the global watchlist disappear for 3 to 25 seconds. And I have only 10Gb montly, so I can't spent it for api calls every 7.5 seconds, when I do not need this data more than once in 10 minutes.

My 4G smartphone has a fast connection too and mobile data is fortunately too cheap where I live. I have all the quota I need for mobile browsing. 😁
Clicking on the "Refresh" clears up the whole screen and starts loading from the beginning. I do not know much about what error you are seeing could you describe it step by step? You get a timeout error, then what happens? Sorry, I couldn't reproduce this from my end.

No error. Just takes time and resources. I do not ask to fix the script. I understand it needs all this, because of many api calls. So all I ask is an opportunity to change the number.

Hmm, so I am assuming something like this happens.
GW live updates feature timesout because of slow connection. GW gets stuck because of it. Then either automatic refresh happens or you click the "Refresh" button. (which one?. I need answer) It consumes too much data because of too many API calls.

If my assumption is correct, I suggest you to do the following before enabling Live updates. Mark sites as seen that only contains uninteresting/useless watchlist results. GW only fetches unseen results, so it won't have the burden to load those uninteresting results again upon a refresh. Hopefully this can save some of your time and data. As for other issues, we can sort something out.

Again, I do not search a solution for global watchlist or for rcfilters. It happens with every heavy script. Just a way to configure the number. I already made a local version of global watchlist settings to avoid usage of global.js. I really do not want to have a local version of global watchlist itself just for this number.

I'm thinking something along the lines of Twinkle's hidden config settings - when not set, they are ignored and sane defaults are used; when set, they override the defaults; user only interacts with them by manually editing the settings

Fair enough.

But Masumrezarock100's idea about a mnimum is very good. If somebody will set it to 5 milliseconds it will blow up the script.

In T245312#5886501, @DannyS712 wrote:

I'm thinking something along the lines of Twinkle's hidden config settings - when not set, they are ignored and sane defaults are used; when set, they override the defaults; user only interacts with them by manually editing the settings

+1. It would be helpful for testing the script to find bugs and debugging. These type of settings should be hidden to prevent new users from unknowingly breaking GW.

In T245312#5886524, @IKhitron wrote:

But Masumrezarock100's idea about a mnimum is very good. If somebody will set it to 5 milliseconds it will blow up the script.

You'll only know it exists if you ask or look through the source code - there won't be a field on the settings page. But sure - minimum of 1000 (1 second)?

In T245312#5886496, @IKhitron wrote:

Again, I do not search a solution for global watchlist or for rcfilters. It happens with every heavy script. Just a way to configure the number. I already made a local version of global watchlist settings to avoid usage of global.js. I really do not want to have a local version of global watchlist itself just for this number.

Fair enough. GlobalWatchlist.js is pretty big in size I gotta say. If we make it a gadget, it will be automatically and significantly minified by ResourceLoader during shipping, meaning it will save some data.

In T245312#5888660, @DannyS712 wrote:

It'll be awhile before I'm motivated to do this, because I'm not planning to use it myself, but if anyone wants to submit a patch please do so:

• Can be submitted as either a git patch/diff, or a fork on enwiki or meta (so that I can use Special:ComparePages)
• The config setting should not be added to a user's preferences if you are using the default
• The config setting should be kept when saving new settings
• No new field should be added to the settings page

I'd like to try, but I do not understand your explanation, it looks me contradictory. Do you mean I can't save the value but I must save the value? Actually, before this post I thought about window.* variable that the user can add to the global.js, and script initialization checks if there is a legal value, otherwise uses the default.

Imagine the variable is LiveUpdatesTimeout (or something like that, my imagination is lacking. I could not find a better name).

• The config setting should not be added to a user's preferences if you are using the default

If you are using the default value (which is 7500 milliseconds at the moment) of LiveUpdatesTimeout, no new config should be added to the global.js.

• The config setting should be kept when saving new settings

When saving settings using Special:BlankPage/GlobalWatchlistConfig, the script regularly checks for any error and replaces the old config with the new one. You need to make sure that GW doesn't consider LiveUpdatesTimeout as an invalid variable and doesn't remove it during the saving process of GW settings (from the settings page)

• No new field should be added to the settings page

The meaning of this part should be obvious.

In T245312#5889996, @Masumrezarock100 wrote:

The meaning of this part should be obvious.

Sorry, but it is not obvious. I believe you can see the architecture in your mind, but I can't see throw your mind, and this explanation just made it worse. For example, why to do something when saving the user settings, if this value is not a part of the user settings. What value should be validated at this point? And much more questions.

In T245312#5890016, @IKhitron wrote:

In T245312#5889996, @Masumrezarock100 wrote:

The meaning of this part should be obvious.

Sorry, but it is not obvious. I believe you can see the architecture in your mind, but I can't see throw your mind, and this explanation just made it worse. For example, why to do something when saving the user settings, if this value is not a part of the user settings. What value should be validated at this point? And much more questions.

Meh, you misunderstood. I was saying that the meaning of "No new field should be added to the settings page" is obvious. I will let Danny handle the explaining to you. I have never been good at explaining things.

I just quoted the last line. Not meant that my answer is to this line only.

My apologies for any misunderstanding I may have caused you. I will let Danny handle it.

No apologies are needed. I'm the stupid one here.

In T245312#5890122, @Masumrezarock100 wrote:

My apologies for any misunderstanding I may have caused you. I will let Danny handle it.

I'm afraid I don't really understand what you're asking. Where is the confusion?

• If the user has manually set a timeout by previously editing the settings, the timeout should be kept when saving again
• If the user has not set a timeout and uses the default, it shouldn't be saved to the settings

In T245312#5890782, @DannyS712 wrote:

• If the user has manually set a timeout by previously editing the settings, the timeout should be kept when saving again

The user cannot set a timeout by editing the settings, because there is no timeout field in the settings.

In T245312#5890832, @IKhitron wrote:

In T245312#5890782, @DannyS712 wrote:

• If the user has manually set a timeout by previously editing the settings, the timeout should be kept when saving again

The user cannot set a timeout by editing the settings, because there is no timeout field in the settings.

There is no timeout field on the settings page, but you can still manually set one

In T245312#5890833, @DannyS712 wrote:

There is no timeout field on the settings page, but you can still manually set one

Please describe the process, as you see it.

In T245312#5890834, @IKhitron wrote:

In T245312#5890833, @DannyS712 wrote:

There is no timeout field on the settings page, but you can still manually set one

Please describe the process, as you see it.

For you:

• Edit the global.js settings
• Save
• See that the specified timeout is used
• Go to the config page, and save new settings
• See that the specified timeout is still saved, alongside new settings

For me:

• Go to the config page
• See no field for a timeout
• Save the settings
• See that no timeout was saved
• Go to the watchlist
• See that the default 7500 is used

OK, but once again, if the user can set the new value in global.js only, why do you need to do something with settings at all? If there is a new value in global.js, it will be used on each browser refresh, otherwise it will not. Why do you need to keep it in user settings if you'll never use this setting?

In T245312#5890782, @DannyS712 wrote:

In T245312#5890122, @Masumrezarock100 wrote:

My apologies for any misunderstanding I may have caused you. I will let Danny handle it.

I'm afraid I don't really understand what you're asking. Where is the confusion?

I was asking you to explain it to @IKhitron, which you are doing now. I had failed to explain it clearly to him. I think real time chat (on IRC or Discord) is a better suited place for explaining to someone who is having trouble understanding the process.

In T245312#5890852, @IKhitron wrote:

OK, but once again, if the user can set the new value in global.js only, why do you need to do something with settings at all? If there is a new value in global.js, it will be used on each browser refresh, otherwise it will not. Why do you need to keep it in user settings if you'll never use this setting?

I think I understand the confusion. I'm saying it should be stored in the settings in the global.js, but not included in the settings on the GlobalWatchlistConfig page

I understand now. Thanks, I'll think if I can do it.