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

@thiemowmde, I've revised your patch (https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Popups/+/488098/). Please review the latest changes when you can.

Scrolling indicator — it would be great to communicate to the user that there are more menu items offscreen/blow. When the menu is first opened the scrollbar should appear then quickly fade out, indicating the additional contents below (it seems like sometimes browsers do this by default - need to investigate further)

I've submitted a simple patch that adds a scrollbar as needed but more work is needed for fancy fade in / out scrollbars. This remaining work is available if someone wants it. @Jdrewniak, are these practical to do in CSS or is JS necessary?

@alexhollender says it's ok to remove menu resizing logic so we can remove the JS and the min-height.

Do we think the dynamic resizing on small screens is important? I'd love to drop that resizing JavaScript and this min-height CSS if document scrolling can be used instead.

Thanks for the through notes, @nray.

I think this could be as simple as adding the following rules:

I like this task and hope we do it and that it's simple. If it's not simple, it may not be worthwhile since the main menu doesn't have many items in it.

@alexhollender, this looks nice to me! I think just morphing this task to your latest designs probably makes the most sense. We can then consider splitting it up after discussing implementation concerns.

LGTM

@Jdlrobson, @pmiazga, what is the intended behavior of the page actions overflow menu in Minerva desktop mode

I think we resolved this?

I'm still unclear what the expected behavior is. Should we show the page actions overflow menu or not in Minerva desktop? Here's the current behavior:

AC1 H, J

This is a legit bug. I can repro. I'll investigate Monday.

Fixed and available on BC.

I went through the test for every mode.

Thank you @Edtadros. Outstanding work as usual.

I would love to have one-click log outs. Fixing this bug as a side-effect would be great but I think we'd need to show the log in button then in the main menu which might make this messier.

AC4

I was wrong about this. I guess the Sandbox is the only new link since contributions was already in the AMC main menu. This link is actually in top of Vector, not the sidebar like I said originally. Sorry for the confusion.

Looks good on BC

Being bold. @Edward's been testing and we've been developing without this.

@Edtadros, I've updated the description to include testing vectors. I'm guessing this is our #1 priority or somewhere near the top. I've tried to keep it brief but comprehensive. If I've failed to elaborate sufficiently or you have questions, please ping me! GrowthExperiments instructions forthcoming.

I'll write QA steps tomorrow. Thanks @alexhollender, @Jdlrobson, @pmiazga <3

This was due to a bad rebase. I'll follow up.

This still looks funny to me. @alexhollender please make sure everything looks ok to you in AMC and default modes.

@alexhollender, the user avatar outline seems a little thick to me.

This was due to a bad rebase. I'll follow up.

I've rebased all the patches and have been addressing feedback. The following patches are awaiting review:

Current task status:

• Made a bunch of refactors Piotr asked for. More needed.
• Feedback from Jan not addressed yet.
• Icon updated.
• Latest changes up https://readers-web-stephen.wmflabs.org/wiki/Foobarbaz

We discussed this ticket in the Frontend Standards meeting today (/cc @Mooeypoo). This task only lists problems encountered in MobileFrontend components but the sentiment from Volker, Eric, Ed, and Jon was that this problem is actually much broader to frontend development and any solution to these issues would probably be wanted elsewhere, so we should be mindful of that.

@alexhollender: latest is on staging https://readers-web-stephen.wmflabs.org/wiki/Foobarbaz.

@Mormegil, thanks!