In T232594#5711599, @ovasileva wrote:

To confirm - the latter would still mean that only logged-in users would view the changes? If so, that's fine - we don't plan on having separate configurations per wiki

Blocked on SuperHappyDevTime meeting

@olga just to confirm, we want to enable both this task and T232652: Add History to article toolbar for all logged-in users on all wikis/projects. We're trying to decide on the best direction and we're considering two options:

• adding a loggedin mode, then these feature will be available to all logged_in users
• remove the feature flags, and make those two features an integral part of the MobileFrontend/Minerva.

/cc @ovasileva @alexhollender is it something we should worry? It's marked high and it's not in progress for 2 years.

The patches above tackled moving the Echo stuff out of Minerva skin (moved related notifications code to Echo extension). There is no defined contract between Minerva and Echo, only a not documented hook SkinMinervaReplaceNotificationsBadge. This approach is also valid but before I can signoff this task we need to:

• document the SkinMinervaReplaceNotificationsBadge hook
• remove Echo from .phan directory_list config as it's not required any more.
• removed unused EchoNotifUser class from SkinMinervaTest
• the mobile-frontend-user-newmessages in qqq.json says Tooltip for new messages on the users talk page (if no Extension:Echo installed).", now it can be anything other than Echo, would be nice to update this message
• resources/skins.minerva.scripts/menu.js still has some Echo handling. Do we want to move it? It uses hooks, so most probably can stay, I just wanted to highlight this.

Logged-in users

A/B testing logged-in users is straightforward. We can easily do that on the server-side, and there is no need for any caching layer changes as all logged-in users requests skip cache.
The only required work is the backend (PHP) work.

The Special:MobileOptions has different UI and serves different purposes. But the preferences are still stored in the user preferences table, therefore it's possible to store those without deprecating MobileOptions page. Now it requires some research on how GlobalPreferences extension picks up which options to store as "global" and then decide on which part of code we need to update.

The link to search pages created on mobile device for English Wikipedia: https://en.wikipedia.org/w/index.php?hidebots=1&hidepageedits=1&hidecategorization=1&hideWikibase=1&namespace=0&tagfilter=mobile+edit&limit=50&days=7&title=Special:RecentChanges&urlversion=2

@Milimetric do you still see this issue?

There is small issue with this task. The AMC switch is a part of Mobile Preferences, it's not visible on the Special:Preferences page, thus most probably it's not stored as a global preference

The problem is that in some scenarios we get an event with malformed URL. The statsv client looks like it's correct, the code that triggers MinervaClientError event also has no trace of anything that would cause malformed event. The issue can be related or to the browser itself or to some code in maps feature. From @Jdrewniak description it looks like this happens only after Maps widget causes the CORS error.

/cc @alexhollender @ovasileva this is most probably something we can do under the AMC work, not sure if we have time for it.

@mobrovac can you take this task and push it forward?

@Zoranzoki21 could you specify what exactly is missing? Do you mean that some content is missing, or just a border around some controls.

@mobrovac @Pchelolo Is it possible that the Restbase endpoint is serving an outdated extract" If I remember right it has some caching built-in.

@JoeWalsh is it something Product Infrastructure could look at ?

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