Replace the class names for the page actions icons with the new class

I ended up taking a no-JS approach. Let's see what folks think.

@alexhollender, sounds good. Updated QA (note: patch not yet merged).

This is currently using the "info" icon in wikimedia.ui. Change it to use "infoFilled" and check with Alex that the icon used matches the attachment. If it's not we'll need to update the icon in OOUI (out of scope for this task).
DO NOT put a new SVG icon into the Minerva repo.

@alexhollender, hm, since the toolbar is already grey maybe we need to use a translucent background. Something like:

@Jdlrobson via discussion:

@pmiazga, given your experience, I think you're in an ideal spot to review this change. I refactored some of the "loose" page permission checks into the MinervaPagePermissions implementation as it seemed quite appropriate. What I'm most unsure of is if any special work is needed when adding new permission actions (a special config in skin.json). (I'm not sure why this is configurable.) The distinction from the plain old "EDIT" action was needed as some parts of the code only care whether the page content model is editable and others care whether the active user can edit.

LGTM. Tested on https://en.m.wikipedia.beta.wmflabs.org/wiki/User:ShreyasMinocha/URL_Hyphenation_Demo?useskin=minerva on an emulated device.

@zeljkofilipin, I'm getting "Your trial period has ended. Upgrade now..." messages again :[ Can you take a look?

From @Jdrewniak: what happens if we just disable the RC filter ResourceLoader module?

Maybe we can start by only showing the labels at maximum width. Another option mentioned was show the labels below the icons so there's more room for wrapping.

Visit http://localhost:8181/wiki/Special:History/Foo?action=history on a mobile device.

@pmiazga and I are no longer able to reproduce this issue locally with or without the patch.

Ok, I think we want something like this then:

@Nirzar, please weigh in on Design's requirements when you can.

Back to @alexhollender.

@alexhollender, should we update the notification drawer shadow?

I've been poking around in the Echo extension which I haven't developed in previously. These are my recommendations for how to proceed with this task but I'm unsure if the changes are wanted or if we're the best team for them given component responsibilities:

Thanks @Lea_WMDE, @WMDE-Fisch, and @thiemowmde!

I think the download button might be the only special case as it's added by JS. IIRC, the ToggleList menu entries are otherwise stock Minerva UI Icons that already include a (currently) hidden label that could be unhidden on CSS breakpoint.

@alexhollender, there are three icon colors currently AFAIK: progressive (blue), constructive (teal), and black. The recommendation in the description is to change progressive for read notifications only (a fourth color). Should the others be changed?

I think I missed this. Do we want to make the notification drawer shadow match while we're at it? (Currently it's a hard outline.)

SVGs are updated in https://gerrit.wikimedia.org/r/531713. It sounds like @Jdlrobson and @Jdrewniak are exploring the sizing.

@thiemowmde, friendly ping on this task. We're moving this out of our sprint board but please note there is a patch (just a revision of your original submission) ready for your consideration when you have the time: https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Popups/+/488098/. Thank you!

Per discussion: not a priority. Moving to backlog. We'll know more once AMC has been out for a while.

Per discussion: moving to kanbanana (needs analysis). To analyst: please decide whether to keep this as a single task or split it into four. Once the task has been analyzed, it will need an estimate as per usual. We think this is still in scope for AMC.

@Nirzar, please weigh in on Design's requirements when you can.

@Jdrewniak, just following up from the meeting: do you have what you need to QA?

@nray, @Jdlrobson, do we want to do more analysis here? What do you think about moving this to blocked on others? We can close it if it the issue isn't seen after a week.

This functionality is currently disabled for the user and overflow menus as it was for other elements on mobile:

Is this device specific or am I misunderstanding? This seems to work ok on the Chromium emulator and Android:

I'd be very interested in the status of this ticket too! I followed @SBisson's V8Js approach for implementing an isomorphic skin proof of concept. I was amazed at how easy it was and how little code it took! I think the benefits of being able to execute the same code both server and client side are difficult to overstate so it would be awesome to provide this functionality for interested skins and extensions.

Tested on https://en.m.wikipedia.beta.wmflabs.org/wiki/User:Teststephen.

Given that AMC may be deployed to all users in time, do we want to remove this link instead?

@alexhollender, this change seemed like a nice improvement to me so I merged it. If there are any issues on your end, please let me know.

• When $wgEnableCanonicalServerLink = true, <link rel="canonical" href="http://localhost:8181/wiki/Foo"> is included once on mobile pages regardless of $wgMFNoindexPages or $wgMobileUrlTemplate state.
• When $wgEnableCanonicalServerLink = false and $wgMobileUrlTemplate is unset, the canonical link is not included on mobile pages regardless of $wgMFNoindexPages state.
• When $wgEnableCanonicalServerLink = false and $wgMFNoindexPages = 'foo':
  • When $wgMFNoindexPages = true, the canonical link is included once on mobile pages.
  • When $wgMFNoindexPages = false, the canonical link is not included on mobile pages.

I've modified them, hopefully correctly and they show that Special:MobileMenu had ~15k total pageviews last year. Of those, ~4.7k pageviews were Opera Mini visits.

@phuedx, identified some flaws in these queries: no pageview filter and no accounting for 1/128th sampling. Updated queries:

• Total pageviews is ~4.2k sampled, ~540k unsampled.
• Opera Mini pageviews is ~1.5k sampled, ~192k unsampled.

Should we give the menu a max-width?
+1 to max-width. Please take into account that the logout button is right aligned aside of users with possibly a very long user name.

I've changed the max-width from tablet (600px) to a min-width of 250px that feels a lot lighter to me. Let me know what you think.

@ovasileva, ^fix

I tested this on https://en.m.wikipedia.beta.wmflabs.org/wiki/Dog. LGTM

Merge is still pending and is not ready for QA.

From the ticket, it's my understanding this bug impacts IE11 and iOS < v12. From the compatibility table, it's my understanding that we provide grade C support iOS >= v7. I don't know what version of desktop IE we support, so I picked IE11. With the regex, (iPhone OS [789]_)|(MSIE 11), it's my understanding that this bug impacts up to .002% of the 1.9B pageviews recorded in the last year and that this number will only decrease. Given our other priorities, I think it's unlikely that this issue will be fixed before these devices disappear completely so I'm regretfully declining this task. /cc @ovasileva @alexhollender @phuedx, please reopen if this is a priority.

@phuedx posted some nice queries specific to the page in question. I've modified them, hopefully correctly and they show that Special:MobileMenu had ~15k total pageviews last year. Of those, ~4.7k pageviews were Opera Mini visits.

For what it' worth, this same technique is used in Vector. On Readers Web we're fond of saying YAGNI (You Ain't Gonna Need It) to get rid of piles of code and complexity. Given our resourcing, we don't need this.

Possible duplicate of T220889.

Could we also consider moving the Wikimedia-specific instrumentation for the main menu into the WikimediaEvents extension?

I think this was done in T228681 but could be mistaken.

@Jdlrobson, after re-reading my comment, I realized I could have worded it much better. I apologize as I didn't intend my response to come off as flippant. I've added some more detail below and we can dig into this in our 1:1 tomorrow as needed.

The JavaScript load is a separate issue that never got addressed and is orthogonal to this. It would be trivial to disable the click handler for JS users... This page is meant for users such as those using Opera Mini.

Yes, I see this page on slow connections when I tap the menu so that's part of this issue too.

@alexhollender, visible changes are here: https://readers-web-stephen.wmflabs.org/wiki/Foobarbaz. I'm looking into a test failure but need your blessing on the visual changes.

I think 1) the usability win and 2) reduced tech debt are more than justification enough:

Adding @alexhollender and @Volker_E in case they want to make adjustments to other parts of MobileFrontend

A quick cleanup will also be necessary in mediawiki-config.