Change 654894 had a related patch set uploaded (by Thiemo Kreuz (WMDE); owner: Thiemo Kreuz (WMDE)):
[mediawiki/extensions/VisualEditor@master] Allow users to enable VisualEditor if their prefs are bogus

https://gerrit.wikimedia.org/r/654894

New information: It's related to MediaWiki-extensions-GlobalPreferences.

When I try to use the API to set my "visualeditor-enable" preference on dewiki to 1, I get "Option 'visualeditor-enable' is globally overridden. Validation error for 'visualeditor-enable': not a valid preference." I have to do my API hack on meta.wikimedia.org (where the global preferences are stored). When I try to do this I get "Option 'visualeditor-enable' is globally overridden", which is another GlobalPreferences message. The message is unclear. What it actually means is "error, this doesn't work, please use the globalpreferences API instead". When I do this I finally, finally fixed my issue.

I can reproduce this. To put it simply: if you visit a wiki where visual editor is a beta feature and set it to disabled in global preferences there [1], then visit a wiki where it is a normal preference, the visual editor will not show up regardless of that normal preference. (You can fix this without using the API by visiting the other wiki again and changing your global prefs, but this is not obvious, see also T199258.)

For example, try it on https://en.wikinews.org/wiki/Special:GlobalPreferences#mw-prefsection-betafeatures – note that to reproduce the bug, you need to tick the first checkbox to use a global preference and untick the second checkbox to set the preference's value to disabled, like this:

A few things about this are surprising to me:

• GlobalPreferences will expose the values of preferences that are not supposed to exist on the current wiki, if they have global values set
• MediaWiki in turn will expose these non-existent preferences in mw.user.options etc.

My first idea was to change the behavior of GlobalPreferences, but after investigating, I don't think it's a good solution. While you can determine whether a preference exists (by checking if UserOptionsManager::getOptionKinds() returns unused), this actually works by generating the whole form as it would appear on Special:Preferences, and is probably somewhat slow. I wouldn't want to do this on every request. We probably can't change the behavior of MediaWiki for the same reason.

Even without GlobalPreferences, you can probably also run into this issue when VisualEditor's config is changed from a beta feature to a normal preference (like in your initial guess). MediaWiki will actually clear out the values for non-existent preferences, but only when the user submits the Special:Preferences form (DefaultPreferencesFactory.php#L1797-L1798), so this bug could still affect you until you do that.

I definitely don't like your idea of displaying the beta feature preference if it's not supposed to appear on that wiki ;)

So, after rejecting the bad ideas, I think this should be fixed by making VisualEditor not check the beta feature preference if it's not supposed to exist on that wiki. Right now the code trusts mw.user.options.get( 'visualeditor-enable' ): ve.init.mw.DesktopArticleTarget.init.js#L558 (and there are also a few places in PHP code where we use this, which probably are also affected).

Or, maybe we should use just one preferences key for enabling/disabling the visual editor, which acts as a normal preference or beta feature depending on the config, instead of having 'visualeditor-enable' and 'visualeditor-betatempdisable' available on different wikis. This would probably require some kind of migration.

Change 659301 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/extensions/VisualEditor@master] Ignore user prefs for enabling/disabling VE which are not settable

https://gerrit.wikimedia.org/r/659301

In T271434#6750077, @matmarex wrote:

So, after rejecting the bad ideas, I think this should be fixed by making VisualEditor not check the beta feature preference if it's not supposed to exist on that wiki. Right now the code trusts mw.user.options.get( 'visualeditor-enable' ): ve.init.mw.DesktopArticleTarget.init.js#L558 (and there are also a few places in PHP code where we use this, which probably are also affected).

The patch above does this. While working on it (which involved updating all of the places where we use 'visualeditor-enable' or 'visualeditor-betatempdisable'), I found a few other issues with how our preferences work: T273177 T273188 T273189 (and submitted separate patches for them as well).

Change 659326 had a related patch set uploaded (by Thiemo Kreuz (WMDE); owner: Thiemo Kreuz (WMDE)):
[mediawiki/extensions/GlobalPreferences@master] Improve "option is globally overridden" error message

https://gerrit.wikimedia.org/r/659326

Change 659326 merged by jenkins-bot:
[mediawiki/extensions/GlobalPreferences@master] Improve "option is globally overridden" error message

https://gerrit.wikimedia.org/r/659326

Change 654894 abandoned by Thiemo Kreuz (WMDE):
[mediawiki/extensions/VisualEditor@master] Allow users to enable VisualEditor if their prefs are bogus

Reason:

https://gerrit.wikimedia.org/r/654894

Change 659301 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] Ignore user prefs for enabling/disabling VE which are not settable

https://gerrit.wikimedia.org/r/659301

QA steps: T271434#6750077

In T271434#6822886, @matmarex wrote:

QA steps: T271434#6750077

Ok.
Went to this URL: https://en.wikinews.org/wiki/Special:GlobalPreferences#mw-prefsection-betafeatures – checked the first checkbox to use a global preference and unchecked the second checkbox to set the preference's value to disabled.

Then visited a wiki where it is a normal preference (Assuming en wiki has that normal preference) and was able to load VisualEditor.