I'm recording here the result of feature testing in older browsers, based on the demo page at https://people.wikimedia.org/~krinkle/T178356.html.

This has caused CI jobs to fail, in for example, https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MathSearch/+/902490/ with:

I don't know the specific context here, but, I want to add that it is possible to wrap a command under the same name. Typically this is done by referencing the full path of the provisioned and executable from another shell PATH entry that has higher more local precedence.

In T180121#6191767, @Stefahn wrote:

This issue also happens with MediaWiki 1.34 (the lockdown extension still shows the old version number after uploading new files).

With the help of @tstarling, we determined the cause of these two separate issues.

In T203694#8351385, @gerritbot wrote:

Change 850151 merged by jenkins-bot:

[integration/config@master] Zuul: [mediawiki/core] Run standalone jobs

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

Opera Mini is a "proxy" browser, which is essentially an app that displays data from a remote cloud server where the real browser runs. As such, the JS interactions there are quite different and not as user friendly. We disabled our JavaScript layer in Opera Mini in 2013 (change).

@Tacsipacsi The announcement is not about browser support in the abstract. It is about the specific set of browsers we are removing support for in this task. I agree that people on certain operating system versions cannot migrate to a newer browser, IE6 being an important historical example.

@Quiddity This will go out next week. I suggest something like this:

Note to self: Import @Mabualruz 's patch to Gerrit and review/test accordingly.

Declining per the above. Instead re-opened T45668: Re-enable disabled Special pages on small wikis (wikis in small.dblist).

Based on my analysis T48098#8602507, I appears this change either no longer works or never worked. Re-opening as I believe it still makes sense to enable these on small wikis.

There's not much left, and what's there should arguably be moved off to Gerrit (or GitLab). There's a few things listed at https://www.mediawiki.org/wiki/Gerrit/GitHub. Anything not included can be added on a one-off basis, not worth the automation. I recently tried to fix the automation behind making that on-wiki list and it takes quite a lot of complexity to run and still has both false negatives and false positives because there are 1000s of repos under the org which all sorts of edge cases from different things we mirrored from Gerrit in different ways.

@CCiufo-WMF Sounds good to me. Note that this task is for dropping Modern support ("Grade A"). Basic support ("Grade C") is a next step and we'll make sure to wait with that until DST are ready for it. I see no rush on that one. That work is tracked under T288287, which is already marked as requiring the DST spike to complete first (T332716).

From a ResourceLoader perspective, I delegate largely to product teams to indicate readiness. I indentified stakeholders in this comment a few weeks ago:

Very nice!

@MoritzMuehlenhoff I believe this is something your team usually do, but not 100% sure. Feel free to re-route as needed!

Added to the task description:

As I understand it, this property is meant to expose headings that exist in the content. Similar to how e.g. edit section and other mechanisms work by section. It seems the tool in question is using this to find and validate a particular portion of the page. Both the API property and the tool in question are not documented or named in relation to a graphical interface for a table of contents. If we retroactively treat it as such, I expect a feature request will be filed to introduce support for exposing "section" information, in which case the property sections would seem like a natural fit, bringing us back to where we are.

The Wikibase code is using IDatabase::unionQueries(). It seems the Rdbms library currently doesn't offer any other way to run union queries.

Using http://ecomfe.github.io/est/fiddle/#version=2.4.0&autoprefix=false&est=false&autorun=false, it seems this was upstream less.js behaviour in 2.4.0 and changed to the current behaviour in 2.5.0, though seemingly without coverage by upstream's test specification, hence it was likely missed by less.php maintainers until now (noting that Wikimedia took over less.php maintenance in 2019).

Task description:

• Rescoped to not be never-ending but rather a specific major upgrade.
• Added a acceptance critera instead of "we did the task", which is undefined. Proposing to use the upstream test suite, like we do now.

From the task description:

[…] which is both good (no performance penalty) and bad (no 3d styling capability).