Checked on enwiki wmf.15

• the long title mentioned in https://phabricator.wikimedia.org/T414993#11580450 Lopado­temacho­selacho­galeo­kranio­leipsano­drim­hypo­trimmato­silphio­karabo­melito­...

before the fix	after the fix

• ʄ

Checked (along with T414993: Vector TOC in Sticky header is styled incorrectly and empty when changing viewports) the specific articles mentioned in the task

• https://en.wiktionary.org/wiki/Module:data_tables

• https://test.wikipedia.org/wiki/Äöü
• https://en.wikipedia.org/wiki/IPhone -

Done - checked on testwiki wmf.15

Testing notes: - the checklist below was checked on testwiki wmf.15; should be re-checked on enwiki (or a wiki where it'd be enabled during week of feb 16)

I was able to see the baby globe before on beta but now I ran into the following issues there.
Currently enwiki beta

• doesn't' show Birthday mode option in the Appearance menu:

• The TOC button/icon has a frame
• Sticky header looks exactly like attached design, with a full-length border/shadow

In T416744#11602590, @lwatson wrote:

Consider MenuButton keyboard navigation behavior.

• Tab key focuses on the button, not the items inside the expandable container
• When the expandable container is visible, focus remains on the button
• Up/down arrows to navigate next/previous item

In T415722#11608484, @aude wrote:

I found an issue with switching quickly between light mode -> dark mode -> back to light mode

• Start on a page with flashlight + click animation (e.g. balloon) and in light mode
• Click on the animation to start the extra click animation
• Switch to dark mode
• While flashlight animation is still playing, switch back to light mode
• The click animation (in light mode) remains playing, and when it stops then the dark-mode animation appears in light mode

Also, I think the click animation (balloons) shouldn't still be playing when I switch back to light mode from dark.

The issue seems specific to the patch https://phabricator.wikimedia.org/T417080

In T415288#11583402, @EMcFarland-WMF wrote:

Hi @Etonkovidova, I wanted to flag some unusual behavior related to this task. Today while I was pairing with Martin and working on my local master branch, which included this change, I saw an error when attempting to delete a namespace from Namespaces Control. The error message was "NULL value found, but an integer is required." I wasn't able to consistently reproduce the bug, and it may have been causing by forgetting to hard refresh after updating master. That being said, I wanted to highlight this scenario as one to test especially carefully during QA.

Thank you!

Checked on wmf.15 - the information message (not a warning is displayed):

Revise Tone quiz has been moved to the Help panel - checked on enwiki wmf.15 the overall behavior of the quiz as part of the Help panel; no issues

Checked on enwiki wmf.15 - all AC are in place.

Checked on enwiki wmf.15 - works as expected:

Checked logstash - message: '.experiment.coordinator' should be equal to one of the allowed values stopped @timestamp: Feb 9, 2026 @ 09:48:18.536 - https://logstash.wikimedia.org/goto/9ebfd5b81fc74ab76f8f072712f82a14

Checked on testwiki wmf.15 - a correct message is displayed after rejecting all add link suggestions "You've reviewed a suggestion. Thanks and keep going!"

Checked on enwiki beta and compared with the current TOC on desktop - looks & behaves as per the specs.

Checked on enwiki beta - looks as expected - no interaction with the TOC when it's hidden.

Checked on testwiki wmf.14 - the issue in the task description is fixed, i.e.

What happens?:
Template:CN is added as a chip. The text Template: remains in the input

Checked the pilot wikis (wmf.14) - Revise Tone task is present.

The error is not present - https://logstash.wikimedia.org/goto/59e0adad190f98d35355b94ca79f20e7; also no presence on Growth event validation board.

Checked on beta - both scenarios in https://phabricator.wikimedia.org/T415881#11575119 works as described. @ATitkov - special thanks for the QA steps!

The scope of the task is done. The final check should be made in wmf.15.

In T414944#11592921, @Jdlrobson-WMF wrote:

Okay I think this is all wrapped up now. @Etonkovidova can you confirm?

Checked on enwiki beta - the specs are in place:

@Cyndymediawiksim - I re-checked on testwiki wmf.14 and enwiki wmf.14. The behavior is different now, but the issue is still present - after declining Revise Tone, a user would see the suggestion again when switched to VE.

• • a user is on Revise Tone task
• a user clicks on Decline, selects the reason
• a user clicks on Submit - the confirming message appears -"Thank you for considering tone!"
• a user is in Read mode now
• a user clicks on Edit - and the editor cannot load. An editor loads only after re-loading a page.

Below is a gif showing those steps:

In T415346#11581647, @ATitkov wrote:

Thank you for the catch! This issue is reproducible on Safari. I will take care of it as soon as possible.

Just for reference, here is how it should look. The screenshot is from Chrome

Testing enwiki wmf.13 - actually, I could not find any examples of correct scrolling on mobile. Even when a highlighted section is close to the top of an article page, the scrolling didn't happen. I checked with different mobile options - Advanced mode, Expand all sections and even parsoid version, all those do not have any effect on scrolling. Firefox displays the following message in the Console: This site appears to use a scroll-linked positioning effect. This may not work well with asynchronous panning; see https://firefox-source-docs.mozilla.org/performance/scroll-linked_effects.html for further details.

Confirmed on enwiki wmf.13 - only user page tooltip is affected; Watchlist/Contributions still show the tooltips with shortcuts

Search field receives focus automatically, keyboard opens.

In T415677#11581622, @Jdlrobson-WMF wrote:

@Etonkovidova which browser? I don't see that behaviour on my Android device. Can you replicate the same issue in production en.wikipedia.org ? ie. is it a new or existing issue?

Scenario 1-3 have been checked - no issues (at this point only default baby globe is shown).

@ATitkov - on https://en.wikipedia.beta.wmcloud.org/wiki/Special:CommunityConfiguration/WP25EasterEggs v-if seems to interfere somehow with the paragraph display, rendering to a horizontal line or it's just to indicate temporary placeholders?

@Jdlrobson-WMF - the focus on the search field is fixed, but the second part of the What should have happened instead?- "keyboard opens" doesn't happen. Tested on iPhone, on enwiki wmf.13. As a result, a user sees the Search field as having focus, i.e. the cursor is there and the field has a highlighted border, but the field needs an additional click to bring up the keyboard.

Tested on beta - "learn more" link for 'Birthday mode' switch is displayed on both desktop and mobile- for @Sneha to review

enwiki beta desktop	design

Notes

• the Birthday option is placed as the last one
• the line spacing is rather tight
• when a user is not logged-in, the "Learn more" link is not present

• tested Accessibility with Chrome Dev tools - Lighthouse - wp25eastereggs-video-container will have audio?

The options for Baby Globe animations are present on Special:CommunityCommunication page - https://en.wikipedia.beta.wmcloud.org/wiki/Special:CommunityConfiguration/WP25EasterEggs

In beta ?mpo=minerva-toc-sticky:treatment` triggers Console error:
Uncaught (in promise) TypeError: can't access property "$el", stickyHeadingRef.value is null

In T413400#11569629, @matthiasmullie wrote:

In T413400#11567915, @bvibber wrote:

This acceptance criteria seems iffy still:

• TOC does not show when editors explicitly disabled it through NOTOC (e.g. Main page)

This was supposed to be done, but looks like I got some booleans messed up :p
Should now be fixed with https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ReaderExperiments/+/1235343

Checked on cawiki wmf.13 and hewiki wmf.13 - the fix is in place.

To document the present (wmf.12) state with the TOC:

Re-checking for ?mpo=minerva-toc-button:treatment and ?mpo=minerva-toc-sticky:treatment on enwiki wmf.12.

In T402422#11557593, @Cyndymediawiksim wrote:

Thank you @Etonkovidova for raising this. This behavior is expected given the current GE homepage/overlay architecture. The notification link targets Special:Homepage and the overlay opens based on client-side routing after load, so the brief homepage flash happens before the dialog is shown. Changing that would require reworking how the overlay is initialized and resolved on mobile, which would be a much larger change than this fix.

In T413404#11557254, @matthiasmullie wrote:

@Etonkovidova This is not enabled by default - it's part of the Minerva TOC experiment, which can be triggered through ?mpo=minerva-toc-button:treatment and ?mpo=minerva-toc-sticky:treatment. My apologies for not making that clear!

Thanks, @matthiasmullie!
Checked on enwiki wmf.12 for real user names with !, ?, and %characters in usernames with spaces before and after those characters. The issue is fixed.

@matthiasmullie, @mfossati - checked the desktop Mobile view and the real mobile device and got different results. Could it be that I misunderstood the requirements?

In T400550#11544372, @Cyndymediawiksim wrote:

@Etonkovidova, I’m not sure if it’s just me, but the attached images aren’t displaying on my end. I also tested this on enwiki beta, and the desktop message still says “Thanks for reviewing suggestions. Keep going!” which doesn’t match the A/C for the task: “You’ve reviewed a suggestion. Thanks and keep going!” On mobile, the message is “You’ve published an edit. Thanks and keep going.” I think both views need updates?

The last timestamp for the error - Jan 7, 2026 @ 17:25:02.362 (https://logstash.wikimedia.org/goto/26401480160e75e228f79004155a4f83).

Checked on wmf.12 - the error is not present anymore.

In T402422#11533733, @Cyndymediawiksim wrote:

I tested this on mobile(where the regression was happening) on test wiki and it looks like the issue was fixed by this patch: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GrowthExperiments/+/1216798.

@Etonkovidova could you confirm this?