Is there any reason you proposed {{#~|user|date}} as opposed to {{#~:user|date}}? The latter would be implementable in an extension without parser modifications, by registering a parser function named ~. I understand the reasoning behind naming the parser function ~ instead of sig or something, so that it doesn't have to be localized, but was the colon-vs-pipe thing deliberate or an oversight?

Unfortunately my first attempt at this patch did regress (un-fix) T225668, but I've now found a way to fix both. Thanks @Etonkovidova for verifying.

This patch doesn't regress the fix for T225668 on my iOS 11 test device, but since that bug was reported against iOS 10, we should test it on iOS 10 before merging. It doesn't make much sense to fix the mobile site on Firefox while breaking it in iOS Safari, because the latter has way higher market share on mobile.

As @kostajh correctly pointed out, the display: block rule (overriding display: flex) on the module divs added by rEGRE6b461b1c3a10: Start: fix iOS 10 layout issue is what causes this. But removing that rule presumably regresses the iOS bug that it was fixing, so I'm not sure if there's a way to fix both. I'll try.

Even when viewing the mobile start module without device emulation, it looks pretty messed up in Firefox:

As a consequence, all of these changes are missing from https://www.mediawiki.org/wiki/MediaWiki_1.34/wmf.21#Core_changes

Yes, sorry for causing confusion by reopening that bug without closing this one.

This was fixed by the fix for T229271, and should start working once the "ask a question" buttons start working again (i.e. when https://gerrit.wikimedia.org/r/534238 is merged).

Scheduled for deployment in today's evening SWAT window (23:00-00:00 UTC)

All these dependencies make (some) sense, except ContentLanguage depending on ResourceLoader, which doesn't make sense.

See also T231701 for why this was reverted.

The patch was reverted by https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GrowthExperiments/+/533620 because it crashed for comments more than 30 days old.

In T107610#5443335, @Anomie wrote:

Or do we want one table that's shared by all wikis? That would make Flow's existing cross-wiki architecture not be broken if something ever tries to actually use it.

In T226130#5411968, @kostajh wrote:

• Clicking the notification doesn't do anything. Ideally (@Catrope or @Mooeypoo might have other preferences for this), clicking the notification would open up the notifications panel

Yes, I think opening the notification panel when the little notification bubble is clicked would be a good idea.

I discussed this a little bit with @kostajh and @Tgr. Summarizing my comments here.

It seems likely that that bug has the same root cause as this one.

getRequestedLanguage(): get the code of the requested output language. Based on the user's preferences, but may be overwritten per request. Avoid binding against the heavy Language class, though.
getRequestedSkin(): get the name of the requested skin. Based on the user's preferences, but may be overwritten per request. Avoid binding against the heavy Skin class, though.

What's the benefit of not binding against Language/Skin? There should probably be some sort of global-ish way to instantiate these and share/reuse those instances, because having to call Language::factory( $context->getRequestedLanguage() ) in 100 places would be very annoying and also inefficient.

This discussion inspired me to write patches for Graph and Kartographer that make their API modules retrieve the graph/map JSON blobs from the ParserOutput object in the parser cache, rather than from the page_props table. This avoids issues with gzipping the data stored in the page_props table and it getting truncated if it's too large despite that. See also T98940 and T119043.

And in case (2), I agree that we should show the help panel as normal, and fix whatever instrumentation bug is causing the events to be logged incorrectly. Many popular articles are semi-protected (require 10 edits and 4 days, or some variant thereof) and some are fully-protected (only admins can edit), so it would be pretty normal for a newcomer to try to edit a protected page.

Re case (1): if the user is blocked sitewide, they also won't be able to post on the help desk, because a sitewide block blocks them from editing any page (except their own user talk page). If the user is subject to a partial block, they may or may not be able to post on the help desk depending on the details of the block (and also, a partial block that blocks them from the help desk may not block them from editing the page they're currently on!).

(While you're at it, the damaging model isn't great either: it's not able to identify damaging edits with 60% precision or higher.)

In T225563#5406110, @SBisson wrote:

Have you seen anything like that before?

I have, and in the past it's been tracked down to extremely skewed inputs from the labeling campaign. I think the first version of the arwiki goodfaith model was built from a data set that had <1% of the edits labeled as bad faith.

I think subprojects is the best way to go here. @JTannerWMF agreed to do this.

There's no real connection, as far as I can see, between XSS and personal information, or between XSS and autocomplete. I don't understand why a browser extension trying to prevent XSS would disable autocomplete. The default value for autocomplete is on, and it makes little sense to explicitly set autocomplete="on" on almost all form fields. In addition, MediaWiki already sets autocomplete="on" on almost every <form> it generates, so there's no reason to also set it on each field (except for browser extensions messing with things, but I don't think it makes sense to design around those).

In T98940#5420537, @Yurik wrote:

@Catrope thanks for tackling it! I always thought parser cache is non-persisted, so if a page does not get any edits in 2 months, the relevant data might not be there?

In T119043#5324471, @daniel wrote:

This is a potential use case for T227776: Generalize ParserCache into a generic service class for large "current" page-derived data

This patch doesn't fully address this issue, but it makes the API module pull the graph data from the parser cache (where it was already being stored) rather than from the page_props table. However, this still has the API module using the ParserCache entry for the canonical ParserOptions, and it's possible to construct pages (most of them pathological examples, but some real-world ones) that have graph JSON that vary on the ParserOptions. So we might still want a way to access hash->definition mappings for hashes that appear in a non-canonical rendering of the latest revision of a page. Perhaps we could encode the ParserOptions in the Graphoid URL, or have some other way of identifying which parser cache entry to use.

Yes, combining Kartographer with FlaggedRevsOverride causes some problems. We'll still enable Kartographer on your wiki if you want it, but you should know about this bug so that you can make an informed decision.

Setting this one aside for Jazmin to work on over the Wikimania hackathon

I null edited https://nl.wikipedia.org/wiki/1870-1879 , and the photo of Aletta Jacobs changed from 220px to 260px. Unfortunately a null edit is required to trigger the update, a purge is not sufficient. That's OK though, removing the largethumb template from an article would also involve editing it.

@Krinkle, @Ciell and I discussed this at Wikimania, and we decided that it would be best not to remove 200 and instead just change 250 to 260. That way the default size index changes (from 4 to 5), but that's less disruptive than what would happen if we removed 200 in the middle: someone whose preference was e.g. 300 would see it change to 400, and I don't even know what would happen to users whose default was 400 (their size index would become invalid).

Should this change be made only on mobile, or only on desktop?

This task is only for mobile, but the CSS rule would apply to both mobile and desktop. Should this change be made for both mobile and desktop? It seems to me that the ratio between the font size of the number and the font size of the text to the left of it should be consistent between desktop and mobile (right now it's 1:1 on both).

There's a letter-spacing: 0.02em rule on these because you asked for it here: T218966#5130398

You asked for both the font-size: 0.85em and letter-spacing: 0.02em rules here: T218966#5130398.

There's a letter-spacing: 0.02em rule on these because you asked for it here: T218966#5130398

Specifically, I think it would be good to sketch out how we would implement some of these things (at least "maintenance template" and "newest articles", as you say), and especially what kinds of new storage we would need (database tables, caches, etc.).

We should check if this still happens in production. The latest patch would have changed how the error is reported in Logstash, we should now search for "Job push failed".

It sounds to me like we just need to do the usual threshold configuration, like in the commit Aaron linked. So we just need to do each of the subtasks.

In T229235#5387097, @MMiller_WMF wrote:

@kostajh -- how common is this? What percent of users are not getting a mentorship module?

I believe this FOUC is part of MobileFrontend's relative timestamp handling, because the "Last edited 24 days ago" label at the bottom of the user page behaves the same way.

This bug is very obviously visible if you open e.g. the "ask your mentor" dialog on the mobile site in a desktop browser at full size (without device emulation). The OOUI dialog doesn't cover the whole screen (because the screen isn't small enough to trigger that behavior), and you get this:

The attached patch fixes this by changing the way the impact module uses column layouts. Right now, the "Monitor views" and "You have not yet created" labels take up the entire width of the module, and then the "Views from recent edits" and the pageviews number are in a 2-column layout (where the left column is as wide as possible, and the right column as wide as necessary). With my patch, the entire module is a two-column layout, with all the text in the left column, and the number in the right column (bottom-aligned). This means that we don't get weird display issues when the number is taller than the "Views from recent edits" text, and hacks fighting those display issues is what made it hard to bottom-align the number in the first place.

This is also reproducible in English, you just have to make the screen narrower so that the "Views from recent edits" text wraps:

It appears that a simple way to fix this would be to add 2600 (the ID of the Topic namespace) to the 1, 3, 5 list in the code snippet quoted in the task description.

I can't reproduce this on beta labs. It was probably fixed by something we did in the past 6 weeks.

In T132084#5348539, @AVasanth_WMF wrote:

While we could potentially get away with one notification being sent to relatively new editors, retroactively notifying editors might cause some stir we aren't prepared to handle at the moment.

The first stack trace is from a deferred update scheduled from EchoHooks::processMarkAsRead() on read requests with a ?markasread=123 query parameter. If writing from deferred updates on GET requests is not allowed, how are we supposed to schedule a write when we notice that it's needed in a GET request? Do we submit a job to the job queue?

(2) A protected page has 'View source' option for users who cannot edit protected pages. Clicks on 'View source' won't trigger impression event.

Patch was merged, job is no longer failing

Perhaps this could be a good onboarding task for @Tgr ?