In T435981#12273063, @Jdlrobson-WMF wrote:

hey @Etonkovidova how can we reliably replicate this?

Tested on enwiki beta - the onboarding popover is currently present only for ato-created accounts (there is a separate phab task - T438376: [Reading List bug] For some new users who save an article for the first time, the success toast and popover pointing to Saved List do not appear)

The summary - the current behavior on enwiki beta:

Checked on enwiki beta (see the gif for illustration below) - the CLS score 0.038

Checked

• https://www.mediawiki.org/wiki/Global_templates/2024_MVP and https://www.mediawiki.org/wiki/Help:Locating_broken_scripts
• logged and non-logged users
• on Firefox 157, Safari 27, Chrome 153
• wmf.23

In T438376#12416634, @Jdlrobson-WMF wrote:

I suspect changes to T439637: Mobile CTA: Automatically save the article from which login/account creation was initiated may have helped. Can you check again now @Etonkovidova on the beta cluster (and then on test wiki on Tuesday?)

Tested on https://test.wikipedia.org/wiki/Special:WelcomeSurvey - all mapping for control groups seem to be correct:

Thank you for excellent instructions in T436210: Recommended reading exp: Instrumentation data verification!

Tested on enwiki beta de-1-3-1-specialhomepage-onboarding-ab-test: The enrollment for this experiment has been overridden. The following event will not be sent:

• page_visit does include non-empty action_context
• "page" includes reference to "namespace_id": -1 not explicitly to homepage. Should it be enough?

Moving to Test in Production to chen test2wiki wmf.24

In T439782#12397750, @Urbanecm_WMF wrote:

In T439782#12397415, @Etonkovidova wrote:

Thank you, @Urbanecm_WMF! Hmm... I didn't think about a mentor being active. Zilant1b is indeed inactive according to criteria on https://test.wikipedia.org/wiki/Special:CommunityConfiguration/Mentorship, and, still, the status is Active. Is it another problem?

No, it is a different threshold of activity (the exact definition is private, so I won't get into details here). The https://test.wikipedia.org/wiki/Special:CommunityConfiguration/Mentorship thresholds are not enabled (the checkboxes are unchecked), so they are currently not enforced. Hope this makes sense.

In T431349#12408813, @lwatson wrote:

@Etonkovidova - thanks for checking and flagging issue with title missing. In my opinion, the missing title shouldn't block carousel launch because the carousel caption only treatment relies on media viewer to display the full captions. I'll follow up after I take a look at the code.

Thanks, @lwatson - I agree. Below is my comment on the last case - all is ok; the task may be signed-off.

Thank you, @SherryYang-WMF! I did a quick re-check of the cases in https://phabricator.wikimedia.org/T431349#12387867

Tested on enwiki beta

• a non-logged user clicks on CTA on an article page

In T435525#12402866, @Sneha wrote:

@Etonkovidova we can pass the alignment as implemented even if it does not align with figma. Its a minor difference and we will refine things when we decide the scale. For the experiment it is okay.

When the user zero interests selected, show a prompt inside reading module for personalizing recommendations as show in the design.

Two minor points:

I checked enwiki wmf.22 - did not find any regression.

Tested on enwiki wmf.22/testwiki wmf.22 on 3G connection; Lighthouse (Chrome DevToolls) shooed no layout shift.

I've noticed that issue but thought it's acceptable behavior.

In T439782#12396585, @Urbanecm_WMF wrote:

In T439782#12395924, @Urbanecm_WMF wrote:

In principle, this should only affect users who do not have skipcaptcha?

Indeed. @Etonkovidova reproduced via Zilant1b, but that account is inactive, so ConfirmEdit ignores its skipcatcha right. My commit should fix it...for now (it's blocking any CommunityConfiguration edits rn). For normal users this shouldn't be very visible, given mentors/admins are generally active.

Checked on testwiki wmf.22.
Looks & works as designed:

In T440061#12391635, @Jdlrobson-WMF wrote:

Needs to be fixed on wiki.

Checked on enwiki wmf.22- both Revise tone and Add link structured tasks are present:

Checked on enwiki beta - all works as expected:

• anon user clicks on the bookmark icon and sees CTA

• click on Login or Create account redirect user to appropriate pages

Checked on testwiki wmf.22 by following the instructions in the QA strategy (in the task description)
Also ran a quick check on enwiki wmf.22.
All works as expected.

I just saw the bug on testwiki wmf.22 - https://test.wikipedia.org/wiki/MediaWiki:Redirectedfrom has
(Redirected from <strong>$1</strong>)

The issue is not present anymore on itwiki:

Checked on enwiki beta - for logged-is and logged-out users. The gifs in the table show that

• on enwiki wm.22 (the fix is not there yet) - watch the TOC - when a user scrolling an article gets to the end of displayed TOC items, then after that, as a user keeps scrolling the page, the TOC doesn't indicate on what item a user is.
• on enwiki beta(with the fix) , as soon as a user reaches the end of displayed TOC, items by scrolling the page, the TOC will also scroll to indicate the user's position on the page.

Checked on enwiki beta - the fix is in place:

Checked on enwiki beta & compare with current production on real device iPhone 11. It looks much better now, thx, @matthiasmullie!

Checked on enwiki beta - works as expected

• a mentor (who has assigned mentees) quits
• immediately the following query returns 0 assigned mentees:

https://en.wikipedia.beta.wmcloud.org/w/api.php?action=query&format=json&prop=&list=growthmentormentee&formatversion=2&gemmmentor=ET45

{
  "batchcomplete": true,
  "growthmentormentee": {
    "mentor": "ET45",
    "mentees": []
  }
}

• testing on testwiki wmf.22 was not possible due to T439782: [testwiki wmf.22] Special:QuitMentorship displays "Incorrect or missing CAPTCHA" preventing a mentor quit the issue seems unrelated to the scope of this task.

Checked on enwiki beta - those cases fixed:

• clicking on the scroll button doesn't display the error
• the scrolling is correctly scrols the page to the image

In T429417#12380821, @DMburugu wrote:

I'm not seeing any Add Link edits on the pages marked as "success". I'll wait for Elena to give a second opinion.

Checked wmf.21 - Link Recommendation task pool is stable (not declining) link; logstash Link Recommendation dashboard (link) looks good too.

Just got Runtime Exception error when enabling Special:Homepage in User preferences ([[ https://logstash.wikimedia.org/goto/96aa1e8b2b6737525e0bc74b4b637808 | reqId: 7dfe7254-7df4-45b8-90e6-78a9b9eb397e ]] I checked how often that error occurs - 422 hits in 7 days - https://logstash.wikimedia.org/goto/f23288a2b3063e485f91a5eec8414fb4

Checked on beta - the issue is fixed. The gif below shows the correct positioning of the interest selector overlay when the selector button is clicked:

Thank you, @lwatson! I saw the same on`enwiki`.

In T431349#12353142, @lwatson wrote:

Second patch 1344113 (Ie8e731) is ready for code review. It parses the multilingual title.

Expected behavior:

• If the language matches the reader's language, show the title in that language.
• If the title language does not match the reader's language, then show no title.

Unresolved examples from T431349#12350108 are now resolved:

Before (I08a664)	After (Ie8e731)

Checked on enwiki wmf.21 - the fix is in place:

In T439252#12374432, @matthiasmullie wrote:

@Etonkovidova both of these are parser egde cases.

The Triton image was indeed caused by an & in the filename, which legacy parser (urlencoded, %26) and Parsoid (plain &) both render differently.
The Earth image is because Parsoid does not resolve redirects in links (and can be different from the images), so it was looking for File:Earth-cutaway-schematic-english.svg, which is actually a redirect to File:Earth_cutaway_schematic-en.svg

Patch in CR for both.

Thank you @matthiasmullie! Re those edge cases - I was surprised how it was easy to find such edge cases. I still think that there are, not so many, but quite few of such cases present.

In T439252#12371821, @lwatson wrote:

I'm seeing issues scrolling to images with Parsoid now (legacy seems fine now). Tested on Berlin article on enwiki and found: (1) the section remains closed and no scrolling, or (2) if it does scroll then the scroll position is off.

Checked on testwiki wmf.21 - the issue is fixed:

• Android real device - the fix is in place

Note:the large font setting was turned on

• iPhone specific issues - I checked on real iPhone 11 and browserstack iPhone 14, 15

@Matthias - please review two specific cases ( https://phabricator.wikimedia.org/T439252#12365680 ).

In T439007#12365780, @matthiasmullie wrote:

Works for me, but I was never able to replicate the weird smaller-image thing that Justin had seen, so would be nice if @JScherer-WMF could take another look at this one to confirm!

Checked on two real devices - Android and iPhone - the scrolling looks as expected.. Browser emulators display a mixed behavior; real devices present a much better scrolling.

Testing notes:

• test on testwiki https://test.wikipedia.org/wiki/Triton_(moon)?useformat=mobile&useskin=minerva&useparsoid=0 . Watch for the Console error Error: Failed to locate carousel image File:Triton_orbit_&_Neptune.png

I successfully checked
✅ 1. Control Group (Default Behavior)
?useformat=mobile&useskin=minerva&mpo=image-carousel-retest:control

Following the instructions in the QA Steps on enwiki beta https://en.wikipedia.beta.wmcloud.org/wiki/Earth?useformat=mobile&useskin=minerva&mpo=image-carousel-retest:carousel-captions-only#/media/File:The_Mysterious_Case_of_the_Disappearing_Dust.jpg:

Thank you, @KSarabia-WMF for the instructions!

In T436872#12364262, @AAlhazwani-WMF wrote:

on my android physical test device (samsung galaxy a12) when we type a interest nothing happens. i need to press go/enter to trigger a search.

this does not happen in my android simulator (google pixel 9 pro).

In T436872#12363419, @AAlhazwani-WMF wrote:

i'm unsure if this will be addressed by the upcoming patch (https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GrowthExperiments/+/1343026) where we set a max-height for account setup dialog on desktop, it seems not. we should set the same max-height also for the interest dialog when it opens from the suggested edits/daily reads module so that there is no layout jump.

Testing note:

• to check the fix on enwiki beta, enter 'Mavetuna Image Carousel' as an interest. Currently, the infinite loading state will be presented:

@Sadiya.Mohammed_WMDE - when checking today wikidata wmf.21 (the patch https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GrowthExperiments/+/1329305 is supposed to be deployed to wmf.21), I did not see the labels displayed in the Impact module. Below is the screenshot from my test account:

It seems that @LMora-WMF is working on the issue - if it's been filed as another issue, feel free to close this task as duplicate.