Page MenuHomePhabricator

[1.42] Use Codex CSS components instead of mediawiki ui inside ULS dialog
Closed, ResolvedPublic4 Estimated Story PointsBUG REPORT

Description

After switching to Codex for our buttons, ULS is now loading redundant CSS for buttons and icons on page load. We should update the markup ASAP to use the Codex CSS components instead.

Use the codex-search-styles module for associated styles given it's already being bundled by Vector

https://doc.wikimedia.org/codex/latest/components/demos/button.html#css-only-version

Event Timeline

Jdlrobson updated the task description. (Show Details)

Change 932470 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/extensions/UniversalLanguageSelector@master] Use Codex styles for buttons in language overlay

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

I think we are getting closer to the tipping point where it makes more sense to start creating a new version of ULS using modern tech. We could sidestep the compatibility issues somewhat if we make the language selector component part of core (which ULS the extension can start using conditionally).

Having said that, we haven't budgeted time for that work.

Ack. https://gerrit.wikimedia.org/r/c/932470 should be a good interim solution as it shifts over some of the markup now. I've updated it to consider MLEB extensions and am open to other suggestions. The codex styles are already loaded on page load as render blocking CSS so this would slim the module needed to render the ULS disalog.

Change 937971 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/extensions/UniversalLanguageSelector@master] Don't load mediawiki.ui.button on page load

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

The above patch continues to load mediawiki.ui.button but loads in when ULS is clicked rather than on page load.

Change 937971 merged by jenkins-bot:

[mediawiki/extensions/UniversalLanguageSelector@master] Don't load mediawiki.ui.button on page load

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

Change 938922 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/extensions/UniversalLanguageSelector@master] Revert "Revert "Don't load mediawiki.ui.button on page load""

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

Change 938922 merged by jenkins-bot:

[mediawiki/extensions/UniversalLanguageSelector@master] Don't load mediawiki.ui.button on page load (attempt 2)

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

Jdlrobson renamed this task from Performance: Use Codex CSS components instead of mediawiki ui to Use Codex CSS components instead of mediawiki ui inside ULS dialog.Jul 18 2023, 10:45 PM
Jdlrobson raised the priority of this task from High to Needs Triage.

The above patch has done the minimum for us to pull mediawiki.ui.button off the critical path.
mw.loader.getState('mediawiki.ui.button') is now registered on https://en.wikipedia.beta.wmflabs.org/wiki/Spain so thanks for your help here!

We'll be deprecating the module soon, but I'm leaving that to the language team to prioritize the remaining work as and when they can.

Nikerabbit renamed this task from Use Codex CSS components instead of mediawiki ui inside ULS dialog to [1.42] Use Codex CSS components instead of mediawiki ui inside ULS dialog.Oct 2 2023, 11:43 AM

I've revised the patch https://gerrit.wikimedia.org/r/c/mediawiki/extensions/UniversalLanguageSelector/+/932470/ to work with MLEB and MediaWiki 1.41 so this doesn't have to be delayed until 1.42 for any technical reason.

Just noting this is likely a blocker for dark mode (WE2.1) as ULS will need to be using Codex for dark mode for the overlay to work under our current plans. In current roadmap this is planned for February Q3. If this is not possible we'll need to find an interim solution for making sure dark mode works with ULS.

If I understand correctly how patch set 12 works, it only depends on @wikimedia/codex-search, introduced in 87bd3c59c7b9 (1.39). If this is correct, the patch could be merged immediately, as per the MLEB policy, 1.39 and 1.40 are the two stable releases that should be supported. (Of course, code review could take some time, but hopefully much less than three months.)

If I understand correctly how patch set 12 works, it only depends on @wikimedia/codex-search, introduced in 87bd3c59c7b9 (1.39). If this is correct, the patch could be merged immediately, as per the MLEB policy, 1.39 and 1.40 are the two stable releases that should be supported. (Of course, code review could take some time, but hopefully much less than three months.)

While that is true, I think the codex-search included with MW 1.39 does not have some classes that are used in the patch. Eg: cdx-button-group (does not exist), cdx-button--weight-quiet (was this previously cdx-button--type-quiet?). If the class names are renamed, maybe the older names can be used as well?

@abi_ I setup a MediaWiki 1.39 instance with the above patch. Firstly there seems to be an existing bug in ULS - in that the language button has 2 icons when it is in the personal tools menu. I've left some details below as it's unrelated to this task (but you may want to open a bug) [1].

Screenshot 2023-11-14 at 4.03.10 PM.png (154×244 px, 5 KB)

I'm making some amendments and this is how the ULS dialog now renders in Vector 2022 in 1.39 with the current patchset:

Screenshot 2023-11-14 at 4.22.52 PM.png (868×600 px, 36 KB)

and how it renders in Vector legacy:

Screenshot 2023-11-14 at 4.23.44 PM.png (826×2 px, 239 KB)

[1] Note about personal tools icon overlap

To replicate use the following config:

wfLoadExtension('UniversalLanguageSelector');
$wgULSPosition = 'personal';

This seems related to this hack and could be fixed by adding a :not( .mw-ui-button ) selector, scoping it to .skin-vector-legacy class or removing it. I'm not sure what it's purpose is.

/*
 * A hack to load the icon before the rest of the module is lazy-loaded.
 * Copied from jquery.uls.css with the path changed.
 */
.uls-trigger:not( .mw-ui-button ) {
	background: no-repeat url( ../../lib/jquery.uls/images/language.svg ) left center;
	// Let the SVG image fit without cropping or stretch
	background-size: contain;
}

I see most if not all B/C changes are because of the 1.39 support, not because of 1.40. Since 1.41 is expected to come out some time this month, which will mean that 1.39 support can be dropped, maybe it’s worth waiting for that?


F41506325 is not visible, please attach it to the task @Jdlrobson.

I see most if not all B/C changes are because of the 1.39 support, not because of 1.40. Since 1.41 is expected to come out some time this month, which will mean that 1.39 support can be dropped, maybe it’s worth waiting for that?

As per https://www.mediawiki.org/wiki/Version_lifecycle#Versions_and_their_end-of-life; it might happen in December 2023. Either way, I think it might not be too much work to just do some quick test with MW 1.39 and 1.40.

abi_ set the point value for this task to 2.Nov 20 2023, 2:40 PM

I'm adding this task to the quarter. Low priority for this sprint, but will work on it in December in case we can't get to it in November (current sprint).

[1] Note about personal tools icon overlap

To replicate use the following config:

wfLoadExtension('UniversalLanguageSelector');
$wgULSPosition = 'personal';

This seems related to this hack and could be fixed by adding a :not( .mw-ui-button ) selector, scoping it to .skin-vector-legacy class or removing it. I'm not sure what it's purpose is.

/*
 * A hack to load the icon before the rest of the module is lazy-loaded.
 * Copied from jquery.uls.css with the path changed.
 */
.uls-trigger:not( .mw-ui-button ) {
	background: no-repeat url( ../../lib/jquery.uls/images/language.svg ) left center;
	// Let the SVG image fit without cropping or stretch
	background-size: contain;
}

Thanks, I'll file a separate bug.

Thank you! December sounds great!

The changes in the patch are deployed on: https://language-mleb-legacy.wmcloud.org/core/index.php/Main_Page (MW 1.39) and can be tested there. I noticed a minor issue: the input settings radio button flow out of the container:

image.png (538×1 px, 74 KB)

I don't see this issue with MW 1.40. This can be tested on: https://language-mleb-stable.wmcloud.org/index.php/Main_Page where the patch changes are also deployed.

This can be fixed by adding position: relative to .cdx-radio. I've updated the patch to do that but haven't deployed the change on the MLEB legacy instance.

abi_ changed the task status from Open to In Progress.Dec 5 2023, 3:25 PM
abi_ claimed this task.
abi_ reassigned this task from abi_ to Jdlrobson.
abi_ updated Other Assignee, added: abi_.

Change 932470 merged by jenkins-bot:

[mediawiki/extensions/UniversalLanguageSelector@master] Use Codex styles for buttons in language overlay

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

Wonderful! Thanks for prioritizing this @abi_ and @Nikerabbit ! This will be a huge help in us working on dark mode next quarter.

I had to revert the patch because of T353071. I'll post a new patch shortly.

Change 981199 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/extensions/UniversalLanguageSelector@master] Use Codex styles for buttons in language overlay (attempt 2)

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

With the latest patch: https://gerrit.wikimedia.org/r/981199, an issue I'm noticing if I directly open the input settings on page load:

uls-codex-2023-12-18-2023-12-18_09.29.30.gif (846×1 px, 620 KB)

abi_ changed the point value for this task from 2 to 4.

Change 981199 merged by jenkins-bot:

[mediawiki/extensions/UniversalLanguageSelector@master] Use Codex styles for buttons in language overlay (attempt 2)

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

This change surfaced this existing bug: T353850

@abi_ Please reopen if you think more QA is needed from our side.