I can reproduce that

In T226143#5282620, @Isarra wrote:

Is minerva missing fieldset styles?

This change is correct, but most probably we should fix how the FlaggedRevs looks like on Mobile first (it's the only extension on production that uses SkinAfterContent hook to inject something to the page).

@Milimetric thanks for the log. Looks like parallel-lint is missing. Usually I work from vagrant environment, and vagrant has all required dependencies installed.
I'll analyze whats wrong.

The task description looks clear, I'm just not sure if the User subpages (example /wiki/User:Pmiazga/MyArticle) should get same treatment as user pages (eg: /wiki/User:Pmiazga).

@alexhollender @ovasileva just to confirm - couple questions:

@alexhollender @ovasileva the Contributions page loaded on Mobile looks bit broken on small devices:

@Milimetric could you explain whats wrong? are you getting any errors?

In T225213#5266247, @phuedx wrote:

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

Looks like in most places we use util.parseHTML() just to create a single element:

@Niedzielski yes, it's possible, and I thought about that use case when I was working on the Menu system. It's not available right now (because of YAGNI) but we can implement the support for submenus. On the backend we have sth like that:

I'll edit description, and leave reproduction steps

@Aklapper I think I know what's the issue, the Special:LogoutPage doesn't respect the mobile domain, it creates the logout link that points to the desktop wikipedia site.

@DIKW_Pyramid - the logout link on the MainMenu doesn't specify the domain, it shows only relative link to the Special:UserLogout page.

The T222630: Add wikidata item link to AMC overflow menu does exactly what this this ticket says - it adds a link to Wikidata item to new menu. The Advanced Mobile Contributions project is a feature set that will add more contributor features/capabilities to the mobile web experience. It's an opt-in feature, that will slightly modify the mobile web UI, and allow access to many tools (like adding Wikidata links).

@nray could you analyze this one?

This feature is available in "Advanced Mobile Contributions" mode, we're currently working on it. It's released only to couple wikis, not available on English Wikipedia yet. For more info please refer to T222630: Add wikidata item link to AMC overflow menu.

QA is blocked on availability of testable Wikidata item on beta cluster.
Once deployed to test prod, could be tested on testwiki: https://test.m.wikipedia.org/wiki/Wikidata

^ sorry, I edited the task and reverted changes by mistake

@Daimona it's 1 -> the MobileSite requires a valid user name or an IP. Showing contributions from an IP range is not supported.

@alexhollender @nray I don't think we should show wikidata link on the usernamespace - if required we can add it later. As @nray pointed, it's one line change.

Currently there is no nice and clean way to do it. Adding isSpecialHomePage() is not best approach, Minerva shouldn't be aware of any special pages from different extensions. Passing an option sounds like a small hack (as it won't be used anywhere else, only in that one specific scenario).

@MNeisler can we add the required = false to Destination? We want to track clicks on menu elements, some elements will not have destination, for example:

• clicking the Main Menu hamburger icon opens MainMenu, there is a Special:MobileMenu page that we could point to, but in near future we want to get rid of this page
• clicking the "more' icon on the Overflow menu, or clicking user icon to show User menu will not have "destination". Those are triggers for modals, when clicked browser will present a modal, not redirect user to a different page (even when no JS)

@Isaac yes, you're correct. Looks like I mixed up the documentation, pushing a fix shortly. Thanks for spotting this!

Hey @Lea_WMDE, sorry, I should be more transparent on the phab ticket. I kept the task in doing for some time as I wanted to work on the issue. Proposed solution caused some problems (If I remember right, system was sending an API request everytime link was hovered). Sadly I couldn't find time for it so I moved it back to "to do", to mark it that I'm not working on it.

Frontend architecture evolution

reflecting reality,looks like the QA steps are out of sync with AC.

It's ready to work on

Instead of adding new Hook handler to the Wikibase Client we will use the link injected into the Sidebar. Wikibase client already uses the BaseTemplateToolbox hook to inject Wikidata link. There is no need to implement another hook, to add the same thing just in different option.

The issue was fixed by @D3r1ck01 - thanks for your contribution.
I reviewed the patch and did QA - moving to Ready for Sign off on kanbanana board.

In T223204#5247958, @alexhollender wrote:

@pmiazga good catch. This is an issue on mobile and desktop. Also, if you expand the filter, add some criteria, then click "Show results" the filter closes when the results are shown. Ideally the filter would remain expanded in that case.