The mobile app ticket for this is T328943

Change #1064496 had a related patch set uploaded (by TheDJ; author: TheDJ):

[mediawiki/extensions/MobileFrontend@master] Option for using native lazy loading of images

https://gerrit.wikimedia.org/r/1064496

Change #1064477 had a related patch set uploaded (by Krinkle; author: Krinkle):

[mediawiki/core@master] qunit: Replace slow mw.messages reset with empty object reset

https://gerrit.wikimedia.org/r/1064477

@Krinkle and @Jdlrobson I did some testing and I was able to force Safari to load the native lazy images, using a onbeforeprint handler and setting the loading property of each img to 'eager'. I can also just remove the loading attribute and this too seems to load the images. I had tried this in the past and it wasn't working back then., so possibly some improvements have been made by Apple.

Change #1062104 had a related patch set uploaded (by Krinkle; author: Krinkle):

[mediawiki/libs/Timestamp@master] Implement fake-able hrtime(), deprecate microtime()

https://gerrit.wikimedia.org/r/1062104

Change #1052668 merged by jenkins-bot:

[mediawiki/extensions/CentralNotice@wmf_deploy] Merge branch 'master' into wmf_deploy

https://gerrit.wikimedia.org/r/1052668

Change #1053999 merged by jenkins-bot:

[mediawiki/extensions/Popups@master] instrumentation: Avoid `user.sessionId()` if possible, since it sets a cookie

https://gerrit.wikimedia.org/r/1053999

Change #1053998 merged by jenkins-bot:

[mediawiki/extensions/Popups@master] actions: Remove unused `sessionToken: user.sessionId()`

https://gerrit.wikimedia.org/r/1053998

Change #1052668 had a related patch set uploaded (by Jforrester; author: Jforrester):

[mediawiki/extensions/CentralNotice@wmf_deploy] Merge branch 'master' into wmf_deploy

https://gerrit.wikimedia.org/r/1052668

Re-tagging for triage. Up to team to triage accordingly. (I'm cleaning up an old note pad, this isn't time-sensitive or related to me.)

Currently my Wikidata watchlist is loading fairly slowly (~8-13s backend response time) and it's spending a lot of time (~25%) for these queries (in Linker::getRollbackEditCount). I've captured such a request in xhgui.

In T63007#9192707, @Krinkle wrote:

In T63007#9192636, @Izno wrote:

[…] but |namespace=-1 also would fit how special pages are dealt with (if that isn't already supported).[…]

namespace=-1 should already work indeed. The reason I suggest also supporting specials as an action is because a number of gadgets enhance the functionality of wikitext textareas, which appear on action=edit in many different namespaces, and on special pages like Special:Upload. action=edit would mean we (correctly) avoid loading the gadget on page views, but also (currently) makes it impossible to load on Special:Upload. namespaces=0,-1 would correctly load both on edit page and upload page, but would also load during page views. From a routing perspective, special pages are the equivalent of action="" or action=null, but to avoid hardcoding that or locking into no other possibilities in the future, I was thinking action=specials could represent that for completion within the Gadgets extension.

Bluntly marking this as invalid given our mw-on-k8s migration, using sockets is not an option for the time being

Change #1036311 had a related patch set uploaded (by Ladsgroup; author: Amir Sarabadani):

[mediawiki/core@master] DNM: Measuring impact of some improvements

https://gerrit.wikimedia.org/r/1036311

Questions from @Bmueller:

• What are the dependencies (code, and/or people)?
  • "Categories" are a fairly small feature. It builds on general platform concepts like JobQueue, DeferredUpdates, and utility functions, but I don't think this task requires changes to other components or feature behaviours. As such, while not exactly standalone, I'd say it has no code dependencies that we need to be mindful of in this context. In terms of teams, the feature is unowned. The task does not require making behaviour changes besides obvious bug fixes, so no controversial decisions or indirect product impact expected there.
• What is the impact of this?
  • Sustainability: the current implementation is needlessly complex and redundant and yet still seeems to regularly produce inaccurate counts. It is prune to production errors and load problems. e.g. T352628: Fatal exception of type "Wikimedia\Rdbms\DBTransactionSizeError", per @Ladsgroup above.
  • Product experience: The most prominent use category counts, where the number itself is imporant/sensitive, is Wikipedia maintenance categories, and similar "meta" categories on other wikis. The counts are often used to power templates, gadgets, and bots to know when a particular kind of issue has more than 0 articles affecting it. The problem is often that the category will either be zero when it shouldn't be or above zero when it should be zero. To clarify: The problem is not e.g. when a category containing 100+ items and the number being off by a few, which would not be a big problem in that case. We have ~15 duplicate bug reports about this at the moment, dating back several years.
• What would it cost to fix? TBD.