Looks good, on Monday I'll check couple things and then I'll resolve it.

@ovasileva

• do we want to A/B test it per page or per the whole wiki?
• do we know what is going to be our population size/which wikis do we want to A/B test? (like do we want to test on 100 users, or do we want to test on multiple wikis on 100 thousand anon users/sessions).

@awight - I can see popups as a logged-in user who disabled Page Previews on the Preferences page. It happens when I hover a regular page link.

Moved to "Blocked on others" as it would be more valuable for the team who created Reference Previews to look at it (as it may be related).

@ovasileva, @alexhollender
Is the Advanced mode provides improved access to talk pages, history pages, user tools, and other editing tool. message final?

The problem is not Minerva, the problem is how/when MobileFrontend initializes FeatureManager. Just changing hook from RequestContextCreateSkinMobile to RequestContextCreateSkin won't help. The problem will be the same - The FeatureManager won't be initialized (won't send the hook).

So the problem is:

• The FeatureManager is a part of MobileFrontend.
• Feature registration happens when MobileFrontend kicks in (via RequestContextCreateSkin
• During RequestContextCreateSkin we trigger MobileFrontendFeaturesRegistration hook that allows Minerva to register it's own features
• because we use Minerva as desktop skin, the mobile mode doesn't kick in, thus code from RequestContextCreateSkin is not called, therefore Minerva doesn't register it's features

From my knowledge, readers-web-stephen is used and cannot be deleted. @Niedzielski is on sabbatical so he cannot confirm.

This issue happened twice and it's related to the deployment process. It happened exactly when a new branch was pushed to production and because of some reason PHP cached old AMCManager definition but used new ServiceWirings file, thus there was an inconsistency with the argument count. This did not happen again.

@nray yup, that's what I did.

I can confirm this is an issue on Beta Cluster - I cannot reproduce that on production Reference Previews are enabled on German Wikipedia, but everything works there.

@alexhollender everything is possible, but that's probably a new task. Also, please note, that the DownloadIcon is injected via JS, thus it may cause FOUC when we decide to change styling based on the number of icons in the toolbar.

@Alex I just want to confirm - those mocks are not in sync, right? We do not show a different toolbar for Android and iOS.

The highlight color can be modified by -webkit-tap-highlight-color,

• we can disable the highlight color for menu handles, but it will bring inconsistency between user menu and notifications menu, same it will bring inconsistency between icons on toolbar and the overflow menu
• set the highlight to given color - we will need two CSS rules, one for user menu (it's on dark background), and a second one for overflow menu (it's on white background). The ToggleList supposed to be a generic component,

but if we want to make it look nice we need specific styles based on where the menu trigger is located.

This task looks good to me and we can start working on it.

After Fix thanks extension works as expected

The logout icon on Firefox is misaligned:

I found a weird issue on Firefox (on production) - The logout icon is misaligned -

Ready to review.

thx @nray, @alexhollender this thing will be available to verify on beta cluster/staging env

Bumping sampling rate to 10%

@Edtadros can beta cluster, can be staging. Let's proceed with staging, please share the user name that has to be blocked,

text change is done in https://gerrit.wikimedia.org/r/#/c/mediawiki/skins/MinervaNeue/+/534596/ but the icon change is blocked on T230694#5466578. All overflow menu icons come from WikimediaUI. If we want to change the SVG to userGroups, first we have to add it to WikimediaUI.

/cc @Nuria @MNeisler

We're receiving ~15 events per minute (previously we were receiving ~100 events), I think that we can still safely bump the sampling rate to ~10%, but first, we need to understand why do we get an events spike from time to time.

Now we're tracking all clicks on menu elements (Main Menu, Toolbar, Overflow, User) with 0.01% sampling rate.
Previously, for the MainMenu only, we were getting ~80-100 events per 10 minutes, now we're getting less than 1 even per 10 minutes (see https://grafana.wikimedia.org/d/000000018/eventlogging-schema?orgId=1&var-schema=MobileWebUIActionsTracking&from=now-7d&to=now ). I'll bump the sampling rate by 100 (to 1%).

The only missing thing are translations (only if we want to promote those things into beta mode) - but I'm not sure if this is something we might do.

QA all possible configs, everything looks good, each config works well both standalone, and with other configs.

@Jdforrester-WMF sorry for the trouble. Thanks for the fix. Do you need any help with that?

sure, I'll check it

Task to disable this feature in two weeks is tracked in T231436: Turn off AMC outreach modal

Blocked on 1.34-wmf.20 release.

Also, please thing about different languages. English looks really nice, but I'm afraid that in other languages those labels can be pretty long. For example in Polish language "unwatch" would become "przestań obserwować" or "usuń z obserwowanych".

The Language icon title definition in i18n:

ok, thx for info

@zeljkofilipin this should be fixed now, can we resolve task once this goes to production? We're unable to reproduce it locally.

@zeljkofilipin yes, the fix got merged like 2 hours ago, but the CI is still processing it ;/