In T311799#8042985, @Func wrote:

I can't reproduce this on beta meta, you may open another page to avoid possible browser cache.

It works fine on betameta.

This is really odd. When I run mw.user.options.get('wllimit') (on betacommons again) it returns 250, even after successfully changing it to 300 in Special:Preferences.

I checked "Disable cache" in the web developer tools and refreshed the page. No difference.

In T311799#8043006, @AlexisJazz wrote:

It works fine on betameta.

This is really odd. When I run mw.user.options.get('wllimit') (on betacommons again) it returns 250, even after successfully changing it to 300 in Special:Preferences.

So, the problem is the result of mw.user.options.get() being out of sync with actual preferences?
I can't reproduce any problem in either beta site though.

In T311799#8043015, @Func wrote:

In T311799#8043006, @AlexisJazz wrote:

It works fine on betameta.

This is really odd. When I run mw.user.options.get('wllimit') (on betacommons again) it returns 250, even after successfully changing it to 300 in Special:Preferences.

So, the problem is the result of mw.user.options.get() being out of sync with actual preferences?

Yes. I tried changing wllimit to 325 using the API and the new value shows up correctly on Special:Preferences but mw.user.options.get('wllimit') still shows 250.

I did test some preference settings recently, like trying to set preferences longer than 64K and/or with strange characters. I wonder if I somehow broke my account?

I can't reproduce any problem in either beta site though.

If you had my account you could.

I'd appreciate if a sysop could take a look at this - it's rather problematic for me as it prevents me from testing various things. At some point I'll try a preferences reset which may or may not solve the issue but would potentially also erase bug evidence.

If you test strange things and these options are still in the database it is possible that new saves for other preferences makes problems, because all preferences are handled at once, not only single preferences are stored.
If you know these preferences try to reset only these to the default value (just omit the "=lorem" part), maybe look at https://commons.wikimedia.beta.wmflabs.org/wiki/Special:ApiSandbox#action=query&format=json&meta=userinfo&uiprop=options to see some preferences
Or reset all at once (you can also reset only the userjs- options at once with the api)

To test if the save is okay set rclimit to an unusal value like 51 and go to action=history of a page with many revisions to see if the limit is 50 or 51 there to know if mediawiki itself would read the correct value. In that case the html is out of sync but the database used the new value. If that value is unchanged, it happens on save.
Maybe it is enough to set the signature to some value and look at the preview if that new value is shown.

(wiki) sysops cannot help here, maybe there are some stack traces in the syslogs

Whenever I try to edit a page (like https://commons.wikimedia.beta.wmflabs.org/w/index.php?title=Testing&action=edit ) I get the

Welcome to Wikimedia Commons
Anyone can edit, and every improvement helps.
Thank you for helping the world discover more!
Start editing

popup. I probably didn't notice before because I perform the majority my edits on any wiki using my script.

In T311799#8045356, @Umherirrender wrote:

If you test strange things and these options are still in the database it is possible that new saves for other preferences makes problems, because all preferences are handled at once, not only single preferences are stored.
If you know these preferences try to reset only these to the default value (just omit the "=lorem" part), maybe look at https://commons.wikimedia.beta.wmflabs.org/wiki/Special:ApiSandbox#action=query&format=json&meta=userinfo&uiprop=options to see some preferences
Or reset all at once (you can also reset only the userjs- options at once with the api)

It's not like I hadn't thought of that - I don't mind resetting my preferences.

But if I can make my preferences go FUBAR like this, anyone probably can. One faulty popular gadget or extension and thousands of users could end up with bricked preferences. That's before you consider the possiblity of actual malice.

This should really not be possible.

To test if the save is okay set rclimit to an unusal value like 51 and go to action=history of a page with many revisions to see if the limit is 50 or 51 there to know if mediawiki itself would read the correct value. In that case the html is out of sync but the database used the new value. If that value is unchanged, it happens on save.
Maybe it is enough to set the signature to some value and look at the preview if that new value is shown.

I changed rclimit using the API. I see 51 revisions on action=history but mw.user.options.get('rclimit') still returns 50.

(wiki) sysops cannot help here, maybe there are some stack traces in the syslogs

I'm a wiki sysop myself, I meant a server sysop.

Did the reset: api = new mw.Api; api.postWithEditToken( {format: 'json', action: 'options', reset: true } ).then( function ( data ) {}); and my preferences seem to work again. But I wouldn't consider this ticket "solved" with that, I really shouldn't have been able to brick my preferences like this.

I've saved a copy of JSON.stringify(mw.user.options) before the reset, but I'm not sure that's safe to share or would contain anything useful.

In T311799#8049190, @AlexisJazz wrote:

I've saved a copy of JSON.stringify(mw.user.options) before the reset, but I'm not sure that's safe to share or would contain anything useful.

I guess all options are equal to the default and there are no userjs-* options. Could you recall if there were any errors or warnings present in the console?

Maybe json encoded by PHP (/includes/ResourceLoader/Context.php#493) is not compatible to mw.Map() instance (which implemented mw.user.options) in js.

If you haven't reset the preferences, search for mw.user.options.set in the HTML of the page should find something interesting.

If there had been errors I would have probably mentioned them. There are indeed no userjs- options in the saved copy.

I seemingly bricked my global preferences on beta cluster, but already reset them as I can't analyze the problem from this side of the fence anyway.