It seems it's broken again.

I have seen this almost every day now, for weeks. Here is the most recent one: https://gerrit.wikimedia.org/r/514495.

18:21:39 1) Rollback with confirmation should offer a way to cancel rollbacks:
18:21:39 element (".mw-rollback-link .jquery-confirmable-button-no") still not visible after 5000ms
18:21:39 running chrome
18:21:39 Error: element (".mw-rollback-link .jquery-confirmable-button-no") still not visible after 5000ms
18:21:39     at elements(".mw-rollback-link .jquery-confirmable-button-no") - isVisible.js:54:17
18:21:39     at isVisible(".mw-rollback-link .jquery-confirmable-button-no") - waitForVisible.js:73:22

https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-php70-docker/22363/console

That's a fascinating edge-case, thanks for reporting! I created T225083 to take care of it.

I had a quick look at the exception. I believe there is a misconfiguration in one of the filters on this wiki: https://commons.wikimedia.beta.wmflabs.org/wiki/Special:AbuseFilter?furtheroptions%5B%5D=hidedisabled. I don't know which. In other words, I believe this is not us, and there is nothing we can do to fix this in our codebase. To not make a badly configured filter make the AbuseFilter extension crash, that extension would need a fix/partly rewrite. This might be worth opening a separate ticket.

This task turned out to be pretty painful because of a multitude of unrelated failing tests. Here is a quick post mortem:

• A fix for the actual bug was found on May 18, but blocked for more than 2 weeks because of all the unrelated failures. We decided to force-merge https://gerrit.wikimedia.org/r/511025 on June 4.
• The HooksTest started failing, reporting a URL to contain an unexpected &ns120=1. 120 is the Item namespace from Wikibase. We suspect one or more Wikibase tests to leave the $wgNamespacesToBeSearchedDefault setting in a dirty state, but we never found this test. Maybe something in the WikibaseCirrusSearch codebase? Maybe @Smalyshev has an idea? We fixed it by removing an assumption from the AdvancedSearch test, see https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/AdvancedSearch/+/513089/4, later squashed into https://gerrit.wikimedia.org/r/511025.
• The browser test automatically selects "All" preset when selecting all namespaces from the list of all namespaces started failing for the same reason. Fixed via https://gerrit.wikimedia.org/r/514278.
• It seems something in OOUI changed. Before, a browser test was opening the file type selection drop-down by clicking it's little down-arrow on the right side. This started failing. Instead, the test clicks the entire selector now. See https://gerrit.wikimedia.org/r/514260.
• One test does a login and logout. Based on what we have seen in the video we believe the logout was not finished, making the next assertion fail. We added a delay for now, also via https://gerrit.wikimedia.org/r/514260.

Briefly discussed and estimated with the team.

• We do not want to split the test, but replace the API call with a mocked one.
• We suggest to store the JSON responses from the actual API calls in a series of files (e.g. in the existing tests/phpunit/res/ folder), and use these files in the mock.

I had a quick look at the patch, and it's a nice and helpful change. Unfortunately it seems to miss one thing. Why can't we run all these unrecoverable errors (user isn't allowed to upload files, bad file extension, duplicate file already exists) before the wikitext conversions? That's what I originally reported: The error message that asks to create a config page for the source wiki (that's a recoverable error!) should not appear before any unrecoverable one. Is there a technical reason this isn't possible?

There you go:

I would suggest not to call any code from the Popups extension (tagged as Page-Previews here on Phabricator, as well as Reference Previews). I would also suggest not to reuse the design from the Popups extension. I mean, there is not really anything wrong with this design. It still fits quite well with the current style guide. But it's outdated and much older than the current OOUI styles. Please stick to the OOUI PopupButtonWidget.

Is this a duplicate of T222441: TwoColConflict browser tests are flapping? Anyway, this got resolved with https://gerrit.wikimedia.org/r/511754. The failing test doesn't exist any more.

Resolved with https://gerrit.wikimedia.org/r/511754: the failing test doesn't exist any more.

When I need to know the file types a wiki accepts, I typically check https://commons.wikimedia.org/wiki/Special:Upload. It currently says:

Permitted file types: tiff, tif, png, gif, jpg, jpeg, webp, xcf, mid, ogg, ogv, svg, djvu, stl, oga, flac, opus, wav, webm, mp3.

We can easily do the same and just list all extensions.

@Lea_WMDE, may I ask why this tasks asks to remove "self, self2, and multilicense replacing placeholder"? The linked ticket T198609 doesn't help me to understand this.

I believe this can be merged as a duplicate of T223709: Namespace selection in AdvancedSearch is not respected any more, and is also already fixed via https://gerrit.wikimedia.org/r/511025. Unfortunately, the patch is blocked on failing tests.

I believe this is a duplicate of T223709: Namespace selection in AdvancedSearch is not respected any more, and already fixed via https://gerrit.wikimedia.org/r/511025. Unfortunately, the patch is blocked on failing tests.

When the patch is merged and deployed, we will have a surprising amount of entries in the database that is not accessible any more. This is not strictly a problem, just a bit sad.

• In case both URLs with and without the trailing slash have been submitted before, only the entry with the trailing slash will be used in the future.
  • If the entry with the trailing slash comes first in the database, this is fine.
  • But if the entry without the slash comes first, it's nicer, possibly shorter ID is gone.
• In case only the URL without the slash was submitted, it's ID is gone.