Thanks to @zeljkofilipin 's work today we got a daily job running the Mobile Frontend tests on the beta cluster today. Hurray!
However, I still want to edit/write/find a MobileFrontend test that works properly on the beta cluster so that this job doesn't just fail every day.

For anyone willing, the string that needs updating on translatewiki is this one:
https://translatewiki.net/wiki/Wikimedia:Portals-language-name/pi

To expand on Jon's point, The reason that there's a flicker on the focus event is because when you click the search box in the header, what actually happens is that a new overlay is created that looks like the header (i.e. SearchOverlay) and the focus is shifted from the first search box to the second overlay search box.

And also View.js mixes in OO.EventEmitter, so technically all our components use that :P

The patch above removes the "targets" from the extension.json file.
I think what was happening is that since the targets were set to "mobile", they weren't being loaded on Minerva desktop.

@alexhollender it looks like this change is live in production. Do you want to verify this change? ( I ask since it's primarily a design issue).

@Pablo-WMDE thanks for your interest here. As you probably guessed, the reason downloadPageAction and others do not use an official Minerva API, is because there is none!

To expand on that a little bit, I did some preliminary research on the front-end implementation of this feature. The parts of this feature that I focused on were: the HTML/CSS & accessibility.

I think the patch above solves the issue for the most part.

The best thing here would be not to collapse the sections at all as screen readers take headings as one possible navigational jump target already. But given technical obstacles that seems out of reach.

Same behaviour with the beta toggle.

@Pablo-WMDE Good point! Adding ID's on the li level seems useful and cleans up that :nth-child in the jQuery, and probably make the CSS more resilient too. This shouldn't be too difficult to add, I'll try to get something out soon.

come to think of it, I don't think the profile icon in skins.minerva.icons.images.variants is being used in either it's original black or the white variant.I think if we change the profile icon to grey, we could remove the skins.minerva.icons.images.variants module entirely.

I've looked into the clock icon usage, and even though it has a grey variant, I don't think the original black icon is actually used anywhere. However, the black version is still being loaded for the skins.minerva.icons.images.variants module.

matrix being used: matrix(-1 0 0 1 203 0)
Here we rotate the entire map 180 degrees. This puts the pokey in the bottom left/top left corner and given its a mirror image,

You now need 2 (nested) elements if you want to make a h2 a button.

@hashar thanks for the tip about the bug parameter! I didn't fix the issue with the multiple bugs on one patch you mention above, but it did make the queries faster. That issue is caused primarily because I'm mapping the patches to tasks 1:1 here, (Array.find) when it should be mapping to an array of tasks (Array.filter).

To be honest I'm surprised the overlay works in Vector at all. It's my understanding that the Overlay component was designed to work with Minerva and MobileFrontEnd, and as far as I know, it's never been used outside of this context.

@Volker_E I can speak to the button vs link.

also w. regards to @Volker_E duplicate patch T217632, the example infobox

There also seems to be a case where a caption is rendering with centered text and padding already, e.g. https://en.m.wikipedia.org/wiki/Cam_Weaver. which I do not understand.

hey @Edtadros , I don't think I know of a simple way to test using cached HTML, but 2, 3, 4:

2. The map gadget - you have to be logged in to wikipedia, then (on desktop) under preferences -> gadgets -> check "Add map popups to coordinates in the mobile website" - then switch to mobile, and pages with locations should have the gadget.
3. Yes, right-most :)
4. I think this can be checked by a developer on a local machine, since it involves changes a MediaWiki config file and seeing if the change takes effect.

Since this is in upcoming, maybe we can change the color of the links to a better blue as well while we're at it? T217660
..reads @alexhollender commend above, oh! yeah. I'll mark that task as duplicate...

I'm adding the Minerva tag since this change can be made to the reference drawer in Minerva. I think Wikimedia-ui-base has an appropriate blue we could use.

I've been poking around this issue today, and it seems like exiting early in _resizeEditor leaves the editor in a wonky looking state (half the screen blank where the keyboard would be)
but that does fix the issue.
Removing the input event-binding in postRender however, does not fix the issue, which seems strange to me, because it suggests that event is still firing, but I'm not sure where (on setContent?, I don't see the event in the logs, so I'm not sure if the root cause is really _resizeEditor).

FYI I deployed this change today (Monday, March 4 2019) and IMO I think it looks pretty good!
The font-change on Mac/iOS/Android is very subtle, but I think the changes on Windows (from Arial to Segoe UI) and on Linux is more noticeable.

Apologies for the breaking change. Didn't realize Wikidata made such significant header modifications.
The changes were made to give more flexibility to the page-actions menu (and potentially the header as well) and fix some of the unintuitive HTML structure.