Page MenuHomeMiraheze

GlobalPreferences functionality is broken since MediaWiki 1.37 upgrade
Closed, InvalidPublic

Description

Problem: I just noticed this last night, trying to resolve an issue with setting a local exception to my global preferences on Meta Wiki, but essentially, prior to the MediaWiki 1.37 upgrade, when you set your preferences to be global via Special:GlobalPreferences and went to Special:Preferences, any preferences set to be global were greyed out unless you checked the checkbox to set a local exception to the global preference. Now, though, the options are not greyed out, and when I supposedly reenabled options globally via Special:GlobalPreferences, they were not enabled on Meta Wiki despite not having any local exception set.

What should happen: In Special:GlobalPreferences, there are two checkboxes for each preference. The left-most option sets whether a preference is to be global or not; the second sets whether the given option is to be enabled or not. When the left-most option is enabled or set to true, that option should be greyed out in Special:Preferences, unless a local exception is set.

Event Timeline

Dmehus triaged this task as High priority.Dec 31 2021, 18:09
Dmehus created this task.
Dmehus moved this task from Backlog to Short Term on the MediaWiki (SRE) board.
Dmehus edited projects, added MediaWiki; removed Configuration.
Dmehus moved this task from Backlog to Bugs on the MediaWiki board.
RhinosF1 edited projects, added Extensions; removed MediaWiki.
Unknown Object (User) moved this task from Backlog to Deployed Extension Bugs on the Extensions board.Dec 31 2021, 18:18

I did a quick check and I see one grayed out. Testing further.

If it's legacy vector, that's known.

RhinosF1 changed the task status from Open to Stalled.Dec 31 2021, 18:21
RhinosF1 lowered the priority of this task from High to Normal.
RhinosF1 added a project: Test Me.
Unknown Object (User) changed the task status from Stalled to Open.Dec 31 2021, 18:25

This doesn't really warrant "stalled" unless it's waiting on external action.

It's definitely reproducable. I don't think it's a Legacy Vector issue, as that's what I use on the Wikimedia wikis, and don't have this issue there. I suspect it's a missing configuration on Miraheze.

Observe the following screenshots:

2021-12-31 11_22_44-Window.png (796×1 px, 69 KB)

^ Special:Preferences on Miraheze, despite Special:GlobalPreferences having been set

2021-12-31 11_23_11-Window.png (796×1 px, 75 KB)

^ Special:GlobalPreferences on Miraheze

2021-12-31 11_19_28-Window.png (800×1 px, 77 KB)

^ Special:Preferences on Wikimedia, with Special:GlobalPreferences having been set. Note: this is what Miraheze used to have, assumed to be prior to MediaWiki 1.37 upgrade. Note also this what should occur

2021-12-31 11_22_07-Window.png (807×1 px, 88 KB)

^Special:GlobalPreferences on Wikimedia, Note: this is what Miraheze used to have, assumed to be prior to MediaWiki 1.37 upgrade. Note also this what should occur

2021-12-31 11_20_54-Window.png (796×1 px, 77 KB)

^ Another view of Special:Preferences on Wikimedia. Note: this is what Miraheze used to have, assumed to be prior to MediaWiki 1.37 upgrade. Note also this what should occur

7012417A-81BA-4149-A2D6-CA4D62EAD7D7.png (2×1 px, 991 KB)

Doesn't happen for me

Not happening for you doesn't mean it's not reproducable and that it's not a problem.

Also, a couple issues with this. You're not using Legacy Vector, but as I said here, it's not that as I am using Legacy Vector on Wikimedia with zero issues. You're also using mobile version.

I'm in desktop mode.

I was hoping you were talking about a specific issue I'd seen before.

Yes you've got an issue but with no one else able to reproduce. It's a browser issue.

Can you please try another device / browser / without custom JS?

2 sysadmins have tried and failed to reproduce.

Please provide enough information so we can reliably reproduce this on a supported environment.

Dmehus reopened this task as Open.EditedDec 31 2021, 22:57

Reopening as it's a valid bug. As demonstrated, it exists, and the problem does not reoccur, in the same web browser, on Wikimedia.

Please do not reclose this, as I would like review by @Reception123, as Engineering Manager (MediaWiki), upon his expected return on 6 January 2022.

No harm in leaving open till or thereafter then. Thank you

You still haven't provided any version information never mind an environment we can reliably reproduce on that's supported. It's not something we can work on.

Unknown Object (User) added a comment.Dec 31 2021, 23:15

While I can't exactly reproduce myself, https://phabricator.wikimedia.org/T286271 seems like the same issue you are experiencing?

John closed this task as Invalid.EditedDec 31 2021, 23:15
John subscribed.

I have attempted to reproduce this as well, with no success.

Please provide as much information as possible regarding environment to assist in investigating the problem. Do not reopen this task without providing this information.

If the above bug linked also sounds very similar, this is an upstream problem which they are already aware of.

While I can't exactly reproduce myself, https://phabricator.wikimedia.org/T286271 seems like the same issue you are experiencing?

Yeah, that's the issue, but that doesn't make it an invalid bug. That shows it's reproducable. Oddly, though, I've not encountered this issue on the Wikimedia wikis, but I do encounter it on the Wikimedia wikis.

In T8554#172837, @John wrote:

I have attempted to reproduce this as well, with no success.

Please provide as much information as possible regarding environment to assist in investigating the problem. Do not reopen this task without providing this information.

Vivaldi	5.0.2497.32 (Stable channel) (64-bit)
Revision	4891cb2a30270ebb895cf22eb99642090bde0046
OS	Windows 10 Version 21H1 (Build 19043.1415)
JavaScript	V8 9.6.180.21
User Agent	Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.113 Safari/537.36
Command Line	"REDACTED" --flag-switches-begin --flag-switches-end --origin-trial-disabled-features=CaptureHandle --save-page-as-mhtml
Executable Path	C:\Users\REDACTED\AppData\Local\Vivaldi\Application\vivaldi.exe
Profile Path	C:\Users\REDACTED\AppData\Local\Vivaldi\User Data\Default

I did provide this information on IRC, but will provide this on here as well. I do suspect it's likely related to the upstream bug, but what I'm unclear on is (a) what's causing it and (b) why I'm personally not encountering the issue on Wikimedia wikis, but do encounter the issue on Miraheze. Anyway, perhaps this will be helpful in reproducing this.

Cheers,
Doug

Unknown Object (User) added a comment.Jan 1 2022, 01:41

While I can't exactly reproduce myself, https://phabricator.wikimedia.org/T286271 seems like the same issue you are experiencing?

Yeah, that's the issue, but that doesn't make it an invalid bug. That shows it's reproducable. Oddly, though, I've not encountered this issue on the Wikimedia wikis, but I do encounter it on the Wikimedia wikis.

That actually does make it an invalid Upstream bug I believe.

RhinosF1 added subscribers: MusikAnimal, Samwilson.

When I asked if you could reproduce on Chrome 96 after you gave me a user agent for chrome 96? You said no. And yes now it's an invalid upstream bug.

@Samwilson @MusikAnimal: you worked on that upstream, can you backport the fixes?

@Samwilson @MusikAnimal: you worked on that upstream, can you backport the fixes?

This is going to be tricky because there has been some major reworking of GlobalPreferences, some of which depends on code introduced in MW 1.38. But I think r751190 by itself should fix the issue you're describing (preferences aren't grayed out when they don't have a local exception). I've backported that as well as another low-risk patch. Try pulling and see if it works better now?