Patch is reviewed, but not merged yet as we don't want to merge something that would have to wait a week before deploying. This change is ready to be merged and deployed and we're waiting for a deployment window. cc @DAlangi_WMF

To follow-up on headers:

Let me leave it as a note - for MediaWiki and Wikimedia we already have pretty good diagrams provided by @Krinkle

In T166610#7561366, @TheDJ wrote:

Couldn't we just look for blur on the window object ? Or alternatively https://developer.mozilla.org/en-US/docs/Web/API/Page_Visibility_API but i don't think visibility is the right one here actually, because it's about the active window/tab, not even about visibility I think.

Using old phab account for the last time, just to confirm that it is me.

Marking as "declined" - the icon is added on the client side, before adding "download" icon system has to verify the print feature availability, thus it's is not possible to do that during page render

I'm tempted to mark this as "won't fix" and resolve it. Another approach would be always adding the "Download" icon on the backend, and then hide when a device does not support printing. But this again would cause the "flicker" for all devices that we think do not support printing - eg all other than Android plus older Android/Chrome versions.

I'm not sure if there is anything we could do about it. The Download icon is injected on the client-side (via Javascript) as we need to test browser capabilities for printing the page down.
Older browsers (Android >= 5 and/or Chrome >= 41) do not support print, therefore we cannot show the download icon (downloading on mobile is handled by "print to pdf' functionality). The download button is not present
in the HTML until Javascript fully kicks, then we check print support[1] and if that returns true, we add the "download" icon to the menu.

In T234907#5760708, @Bawolff wrote:

In fact, i believe at one point this sort of subclassing was explicitly recommended in the docs somewhere

I just wanted to highlight that we need to take precautions while working on the Vector skin. Some popular 3rd party skins/extensions depend heavily on Vector. For example Hydra developed/used by Gamepedia has HydraSkin, and the SkinHydra class extends SkinVector ( source code: https://gitlab.com/hydrawiki/skins/hydra/blob/master/SkinHydra.php ), therefore any bigger changes to SkinVector might break their sites.

@alexhollender why do we need two different views, equally spaced and aligned to left/right?. Can we just have a one style for all possible cases?

Tested on Beta cluster - works as expected

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

@ovasileva 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.