Ok, we have a workaround for T245793 (thanks @Mooeypoo!). New issue: there's a race scenario with Popups to insert the new skin preferences section directly underneath skin choice section. I can't think of a way to handle this scenario in the current architecture except:

As I was staging this change for review, I uncovered a radio alignment regression affecting wide-screen Firefox JavaScript users only. The issue is reproducible on the stock Special:Preferences page by simply infusing the skin section. E.g., OO.ui.infuse( $( '#mw-input-wpskin' ) ):

Estimated asynchronously at an extra-large.

Removing Olga as assignee. I think the carryover was just a clerical error.

o/ @ovasileva, this task is ready for estimation and timely given @nray's T239258 work.

PR is merged so I hope this task is done.

PR is merged so I hope this task is done.

@phuedx, I've left a comment for you in code review regarding preference conversion. This still "needs work" but is pending your feedback so I'm moving over to code review and assigning to you temporarily

Thank you, @phuedx!

Config patch is up. I've submitted a revision of the hooks patch that adds tests for the different branches.

@matmarex, sorry if this doesn't make sense but do you think there's a chance https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/541597/ could be contributing to this issue?

This needs discussion on approach with @Jdlrobson and the other devs.

@phuedx, we add the link to the sidebar via MediaWiki:Sidebar on each test wiki, correct? Is it ok that that this is modern Vector-only link? The mocks say that clicking the button just takes to the appropriate Special:Preferences section so I don't think we need anything extra like JavaScript, right?

Clarified in the meeting that JavaScript isn't necessary so option 3 is MediaWiki:Sidebar + hooks only.

3
Adding a link to Special:Preferences#mw-prefsection-rendering in PHP. Use JS to trap the user clicking the link and use the MediaWiki API to opt them in/out.

@phuedx, we add the link to the sidebar via MediaWiki:Sidebar on each test wiki, correct? Is it ok that that this is modern Vector-only link? The mocks say that clicking the button just takes to the appropriate Special:Preferences section so I don't think we need anything extra like JavaScript, right?

Thank you @jijiki, @MarkTraceur, @thcipriani!

@polishdeveloper, looks good! Just reframing the above into concepts to make sure I got it:

I've added some skin preferences section display logic to Core as hide-if only works for field elements not sections.

@Anomie, that seems to be the approach taken by all (?) of Wikibase.

Can we generate SVGs as a build product like we do in Popups? This allows for developers to have a development friendly version that is built by automation into the shipped user version.

@Tgr, let me know if this doesn't make sense and feel free to edit!

@Jdlrobson, this work was tougher than I anticipated but @Jdrewniak has done well. I think the outcome is very good and practical.

In my opinion this was the skin's right.

I think it could be valuable to separate the ideas of application entry points and UI appearance-only changes. (I'm not sure if it makes sense in MediaWiki for the latter to include content styling too.)

^Neat! It doesn't look like this preference even displays unless the skin preference has been saved!

@AronManning, I think a good place to start would be FeaturesManager.php in MobileFrontend and the contents of the features subdirectory. An example mode implementation would be the AMC UserMode (this class represents advanced mode on mobile--the name is a relic from when it was called Advanced Mobile Contributions) and an example feature would be the standard and advanced menus. More details in T242835.

I think we can use something like https://phabricator.wikimedia.org/source/mediawiki/browse/master/resources/src/mediawiki.less/mediawiki.mixins.less?view=raw (unless you know a better URL). Related discussion in Vector.

@AnneT, eek, I'm not seeing that load either! I do see MenuOptionWidget.

Hey @Jhernandez! Point taken but of course the integration won't be perfect or frictionless initially. As I understand it, FAWG and Web will be iterating on the initial solution well beyond this RFC so there will be opportunity to uncover integration complexities (such as the ones you noted) that would arise from any choice and I'll be bold enough to say that I'm probably more optimistic than you that we'll figure them out :]

I can repro the issue in the Chromium device emulator on Vector per the description:

Hello @AronManning! (Sorry for the slightly redundant reply.)

Hi @AronManning! Per the outcome of T234907, development is already underway in Vector itself. My understanding is that this approach will allow us to minimize development costs. The existing experience (now called "legacy") will be carefully preserved via a user preference (the subject of this task) and feature manager.

I was thinking that the same changes could be made to at least Minerva which it looks like you did. Thank you!

T158181 sounds like a nice objective. For this task specifically, I like @Jdlrobson's generic hover proposal much better than what appears in the description.

I discussed this task with @pmiazga, mostly about how it relates to T237635, and the configuration changes and the approach proposed. We think this work will be pretty loosely coupled from the feature manager but it would be nice to deliver legacy and v2 "modes" in the initial (Vector) feature manager patches whenever they come (Piotr is hoping for next week). No other concerns regarding approach but Piotr has some ideas about using the BetaFeatures extension, when available, in conjunction with the $wgVectorDefaultSkinVersion config to start more users on v2 that he'll be discussing with @ovasileva but that can be decided independently of this task.

The shield should cover the whole article surface and be translucent (opacity: 0.6)

The opacity of the reference drawer shield appears to be .5. Is this correct @Jdlrobson, @Jdrewniak? Otherwise LGTM.