As user Selenium_user on beta labs enwiki, I have set my preference to opt-in to VisualEditor several times, but the preference then gets reset to default (opt-in not set) after a period of some hours.
This causes failures in the browser tests and I wonder if it is a risk in the production environment.
Version: unspecified
Severity: major
The Selenium_user on enwiki has the following preferences right now:
["visualeditor-enable"]=> int(0)
["visualeditor-enable-experimental"]=> int(1)
["visualeditor-betatempdisable"]=> int(0)
So VE is actually disabled.
Maybe some test is disabling the option while other set it? Tests relying on VE should probably set the user preference through the API before the test run.
I have just enabled VE manually in beta labs for Selenium_user. I suspect it will become disabled soon.
Is it possible that the automatic run of update.php (or whatever updates the db) would un-set that preference?
I am wondering, isn't it that the default is to disable the opt-in preference on enwiki now? Thus if the Selenium test rest the user preference, it would end up opting out of VE :(
Can you try in your test to explicitly set the user preference?
What led me to suspect it is:
0.2789 6.0M Start request POST /wiki/Special:Preferences/reset
HOST: commons.wikimedia.beta.wmflabs.org
HTTP HEADERS:
X-REAL-IP: .... # Some IP address at saucelabs
X-FORWARDED-PROTO: https
...
REFERER: https://commons.wikimedia.beta.wmflabs.org/wiki/Special:Preferences/reset
COOKIE: ...centralauth_User=Selenium+user .... commonswikiUserName=Selenium+user...
See also "Update how VisualEditor's experimental config works" https://gerrit.wikimedia.org/r/#/c/84433/ which got deployed on beta on Sep 18th.
hashar@deployment-bastion:~$ mwscript eval.php --wiki=enwiki
return $wgDefaultUserOptions['visualeditor-enable'] ;
0
$
So you could add an exception in CommonSettings-labs.php or InitialiseSettings-labs.php to override that value for beta and make sure VE is always opted in.
this really should not be happening for any test:
0.2789 6.0M Start request POST /wiki/Special:Preferences/reset
thanks for pointing that out.
ULS tests are doing it:
tests/browser/features/support/pages/reset_preferences.rb
Last indexed a month ago
1
2
3
4
class ResetPreferencesPage
include PageObject
include URL
page_url URL.url('Special:Preferences/reset')
Ruby
tests/browser/features/step_definitions/common_steps.rb
Last indexed 4 days ago
59
60
61
After('@reset-preferences-after') do |scenario|
visit(ResetPreferencesPage)
on(ResetPreferencesPage).submit_element.click
Great! Now got to find a fix, ideally the VE feature should set the optin preference. I am not sure whether you have support for that already.
And sorry for the delay investigating this issue :/
The fix is to not do a global reset of preferences for the shared test user. :-)
We will have the ULS tests create a user of their own.