User Details
- User Since
- Oct 4 2016, 5:18 PM (338 w, 17 h)
- Availability
- Available
- LDAP User
- Pmiazga
- MediaWiki User
- PMiazga (WMF) [ Global Accounts ]
Thu, Mar 9
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:
Tue, Mar 7
Thu, Mar 2
Feb 17 2023
Feb 10 2023
Let me leave it as a note - for MediaWiki and Wikimedia we already have pretty good diagrams provided by @Krinkle
Feb 6 2023
Feb 3 2023
Jun 4 2021
Feb 10 2020
Using old phab account for the last time, just to confirm that it is me.
Jan 6 2020
Jan 2 2020
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.
Dec 30 2019
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.
Dec 24 2019
Dec 23 2019
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.
Dec 19 2019
Dec 17 2019
@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?
Dec 16 2019
Dec 9 2019
Tested on Beta cluster - works as expected
Dec 4 2019
Blocked on SuperHappyDevTime meeting
Dec 3 2019
@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.
Nov 7 2019
Nov 6 2019
Nov 4 2019
/cc @ovasileva @alexhollender is it something we should worry? It's marked high and it's not in progress for 2 years.
Oct 24 2019
Oct 23 2019
Oct 22 2019
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.
Oct 17 2019
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.
Oct 15 2019
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.
@JoeWalsh is it something Product Infrastructure could look at ?
Oct 14 2019
Oct 11 2019
Looks good, on Monday I'll check couple things and then I'll resolve it.
Oct 10 2019
- 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.
Oct 9 2019
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).
Oct 8 2019
@ovasileva, @alexhollender
Is the Advanced mode provides improved access to talk pages, history pages, user tools, and other editing tool. message final?
Oct 4 2019
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
Oct 3 2019
Oct 2 2019
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.