Issue with enabling BetaFeatures
Closed, DuplicatePublic

Description

When attempting to enable a BetaFeature (e.g. TwoColConflict) from the user's preferences panel upon clicking save the page reloads with the once selected BetaFeature now deselected and still disabled.

This phenomenon can be seen here during selenium tests for TwoColConflict: https://integration.wikimedia.org/ci/job/mwext-mw-selenium-jessie/6581/artifact/log/Two%20column%20edit%20conflict%20help%3A%20RevisionSlider%20tutorial%20is%20not%20present%20after%20it%20was%20dismissed%20once.mp4

It also occurs on my local development environment shown below:

  1. Mediawiki Version: 1.31.0-alpha (1bb9a22) 03:01, 4 October 2017
  2. BetaFeatures Version: 0.1 (edfd490) 20:31, 30 September 2017
  3. TwoColConflict Version: 0.0.1 (a30c5f3) 09:23, 4 October 2017
  4. https://github.com/addshore/mediawiki-docker-dev

The issue seems to only occur on fresh installations of mediawiki, therefore, it doesn't appear to be causing problems on the production server. Since, I use mediawiki-docker-dev for my local environment I periodically use new installations and thats when the issue was first spotted. This issue does not appear to be TwoColConflict specific and occurs with other BetaFeatures as well.

Restricted Application added a project: TCB-Team. · View Herald TranscriptThu, Oct 5, 11:42 AM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript

+1 I can reproduce this, but only after I pulled core.

Andrew-WMDE updated the task description. (Show Details)Thu, Oct 5, 11:52 AM
Addshore added a comment.EditedThu, Oct 5, 11:52 AM

A quick git bisect tells me that the following commit in core is where the issue starts for me:

7ab57ba290f670847f981d5fc2c79339f1d4844e is the first bad commit
commit 7ab57ba290f670847f981d5fc2c79339f1d4844e
Author: Chad Horohoe <chadh@wikimedia.org>
Date:   Tue Oct 3 14:26:18 2017 -0700

    Stop stubbing StubUserLang

    Stub objects are confusing as heck and are a performance optimization
    that really aren't fit for the modern era. They were designed to avoid
    loading the actual code from the disk back in the days when bytecode
    caching wasn't always gonna be there.

    It's 2017. If you're using HHVM, you've got a bytecode cache. If you're
    using any reasonably recent version of PHP then you've got the opcode
    caching enabled by default in basically every distro-related build.

    Nothing actually relies on this object being a stub (that'd be silly),
    so only references are basically things force unstubbing (also kind of
    silly) the object. Once remaining code referencing this in extensions
    are all cleaned up then we can remove the class itself.

    Change-Id: I15df24aeeb729e8e764792daa933377f35042fab

https://gerrit.wikimedia.org/r/#/c/382067/

Cause is likely the same as in T177478, it basically affects all user preferences.

Elitre added a subscriber: Elitre.Thu, Oct 5, 4:04 PM