To second what Michael said, the issue that Elena found has been fixed.

@KStoller-WMF Yes, I should have moved this task into the current sprint when I started working on it. Thanks for catching that.

Hi @EAlbizzati-WMF, did you mean to link your pull request to phabricator task?

@EMcFarland-WMF - a super minor issue: when the warning about invalid password is displayed, the eye icon is still visible (and functioning). Do you think it's worth to address it? I did not find any other instances of that issue, i.e. "Confirm password" field seems ok.

@Anirudh_KK Sounds good! We look forward to seeing your progress.

Hi @Anirudh_KK, thank you for working on this. I discussed the task with other members of Growth engineering. Rather than silencing the warning, we think it would be better to upgrade the extension to node16. You’re welcome to start working on the upgrade. Please let us know if you have any further questions.

Hi @Urbanecm_WMF, the homepage displays as "Hello, $username!" rather than displaying as "Homepage." Could you please confirm that the current display is desired? I expected it to display as "Homepage," but I am not sure what is desired.

In T430698#12095076, @Etonkovidova wrote:

In T430698#12094692, @DMburugu wrote:

The email change appears similar to the V1/V2 changes to me when I checkout beta

@EMcFarland-WMF does this query parameter that appears tied to an experiment in the url affect the form? experiments[0]=we-1-8-account-creation-no-desktop-benefits:unsampled

@DMburugu - the email field verification should be done for both - v1/v2 account creation form and the non-treatment account creation form since now it is in MediaWiki core and the default experience.
experiments[0]=we-1-8-account-creation-no-desktop-benefits:unsampled is for hiding the text on CreateAccount page - "Wikipedia is made by people like you." etc

Hi @Arpitajain28, here is what I see on my local machine at http://localhost:8080/w/index.php?title=Special%3AHomepage&namespace=0#/homepage/impact when I enable dark mode and mobile view.

Hi @Urbanecm_WMF, I'm doing chores and this error occurred 118 times in the last 24 hours. I'm not sure it's truly resolved? I'll add this to our list of discussion topics for when we sync early next week.

Hi @Arpitajain28, thanks for working on this. Here's a screenshot that demonstrates the line I saw while doing a review.

Just chiming in to say that I also observed this error when doing chores today. There were 2,742 occurrences in the last 24 hours.

@Michael Thank you for closing this task! I appreciate it.

@Michael Shoot, sorry, I should have brought this up in a refinement session. Kirsten had suggested that during our upcoming sprint review meeting, we discuss ending the Mobile Account Menu Experiment. I'd suggest we hold off on declining this task until after that conversation.

Hi! Is there any ongoing work on this task? I am seeing something similar pop up in builds in 2026.

Hi, I wanted to update this patch after we had a growth engineering team discussion. This work is dependent on Michael's in progress work to support non-cache splitting experiments for account creation, linked here https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikimediaEvents/+/1286930. (I will update my patch's commit message to make the dependency apparent.) As a group, we agreed that the exposure event should occur once users get to the create account page, and not when users open the popover. I'll remove the send event code from my work on the popover. Finally, my patch currently uses the experiment as the third param in the methods called to start the ClickthroughRateInstrument. That won't work anymore, because of not being able to get the experiment from the promise. Instead, a new instance of the experiment class would be needed.

Although I don't think that adding templates from different wikis will actually work.

Today, there is only one code path in production that disables the sitenotice, which is the CentralAuth extension (source) when logging-in on auth.wikimedia.org.

I read through your reasoning and the linked code search results. I think your reasoning makes sense, but I'd like an engineer who was on the team when ValidationStatus was introduced to double-check this.

Hi, please disregard Change #1283709, which was linked to this task. I had multiple phabricator tasks open and accidentally copied the wrong task into the Bug: field. My mistake.

Hi @Etonkovidova, thank you for QAing this. I thought that for Special:CommunityConfiguration/GrowthSuggestedEdits, we wanted the user to be able to enter custom input. See https://phabricator.wikimedia.org/T398428#11619504. Please let me know if I am missing something.

I looked at Sergio’s patch and I don’t think it would interfere with impression data. Since the impressions are logged in extensions/CentralNotice/resources/ext.centralNotice.display/index.js in reallyRecordImpression, and since that script doesn’t run when wgCentralNoticeMaxCampaignFallback is set to zero, it shouldn’t be a problem.

Hi @Krinkle, thank you for the feedback. I discussed it with Martin in a 1:1 and wanted to follow up here, too.

I discussed this task with Dennis in our 1:1 yesterday. We agreed that I can resolve this task.

Just for context, I was doing chores today and found that this error message had occurred 89 times in the last 24 hours. Here's a link to the dashboard. https://logstash.wikimedia.org/goto/d3be486735651762e4b918ef0d7271fd

I am resolving this after discussing it in a 1:1 with @DMburugu.

Thanks, Anne! This was really helpful. I think showing the names initially only when the component mounts, and then clearing the menu when the item is selected, would make sense. I will try that and reach out with any further questions.

Thank you for debugging this, Sergio! I am taking a look now.

I would support updating the we-1-8-mobile-account-menu experiment to show both permanent/temporary account creation rates.

Hi, I'm following up on a comment on patch 1253392. I don’t think patch 1253392 surfaced this error, because I can’t see a way in which those changes would have removed or changed $item['href']. Let me know if you have any other questions, thanks.

Re: the third AC, design okayed the changes via slack. Here's a link to the relevant thread. https://wikimedia.slack.com/archives/C02F2C8UUF4/p1774624224253229