Last modified: 2013-10-01 15:41:34 UTC
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.
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?
VisualEditor opt-in preference unset again overnight PDT Sept 27.
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.
