In T318458#9743655, @Dreamy_Jazz wrote:

Does the textbox appear on the right of the dropdown on Special:Block for you? The reason I ask is that the dropdown and textbox were largely copied from the Special:Block code (with some modifications), so I am wondering if this also occurs for that page.

@Dreamy_Jazz On Vector and Vector 2022 the text input does not appear below the dropdown:

I have tested code folding on several browsers on LTR and RTL wikis. I have mostly been checking that the folding/unfolding functions and that the wikitext is not modified in the process.

I cannot reproduce the bug in the description.

In T349506#9713787, @Dreamy_Jazz wrote:

For QA please check that temporary accounts on beta wikis still works as expected. For example:

1. The format for temporary account usernames is ~YYYY-X, where X is an integer and YYYY is the current year
2. Users which start with ~2 or * are marked as temporary users.

I can confirm T359584#9657841.

I have taken a sample of global blocking logs from the production metawiki database from different years and put them in my local database. I don't see any exceptions in the logs. The log lines in Special:Log look OK to me and the links work.

@Dreamy_Jazz a log_title of Contributions/71.107.128.0/18 leads to a log entry of ...globally blocked 18... where "18" is a link to "Special:Contributions/18".

In T361924#9714387, @Tchanders wrote:

Testing notes

This should just need regression testing with $wgCheckUserEventTablesMigrationStage = SCHEMA_COMPAT_WRITE_NEW | SCHEMA_COMPAT_READ_NEW; set.

In T339914#9714017, @Dreamy_Jazz wrote:

For QA I would suggest checking that Special:Investigate and Special:InvestigateBlock still work, and that a link from Special:CheckUser to Special:Investigate still exists that says Try out Special:Investigate.

I can no longer reproduce the bug.

I suppressed all the log entries on my local wiki and then I did a "Get actions" Special:CheckUser request for a username, IP and temporary user. I could not find any references to suppressed usernames for any log entries.

In T30684#9714133, @Bhsd wrote:

@dom_walden Does CodeMirror stop functioning after the error? Sorry, I am unable to reproduce it on my MacBook Firefox, so I would like to learn more about it.

When doing a global unfolding on https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Fox&action=edit I saw the below error. I have only seen it happen once so far. Browser was Firefox 115.

A few observations:

The two snippets in the Acceptance Criteria appear to give you an editor with syntax highlighting like CodeMirror.

The behaviour appears consistent with acceptance criteria.

I don't know if I can test this locally or on beta. I will move it into Done. I guess we will see events being recorded on grafana when this is deployed.

The <br> tag here is not being fully nested in the .cm-bidi-isolate span https://en-rtl.wikipedia.beta.wmflabs.org/w/index.php?title=Br&action=edit

I find it hard to tell where the cursor is, especially in Firefox or Chromium. Safari is a bit easier to understand. But I am not used to RTL editing.

@MusikAnimal Is it supposed to look different in Firefox/Chrome compared to Safari?

I hid all the entries in logging, revision and archive tables and did an ApiQueryCheckUser on all users and IPs in cu_changes. I then searched the API responses for any usernames in the actor table.

I have been making various requests to action=query&list=checkuser on my local wiki and have not seen this warning.

I set all the log events to have the same edit summary (which is easily searchable), hid all the log event edit summaries and did an ApiQueryCheckUser query for all the users and IPs in the cu_changes table. I then did a search for the edit summary. I could not find any references to it in any of the API responses.

Comparing responses from the API before and after this change, the only difference I see is in the "summary" returned by the actions request type.

I have checked that column exists on MariaDB and SQLite3.

I checked the new table on MariaDB and SQLite3.

In T231075#9684972, @JWheeler-WMF wrote:

@dom_walden do we need any designs to serve up a more useful error message? I'm not sure if there are any existing patterns we can leverage

In T341827#9684813, @Dreamy_Jazz wrote:

In T341827#9684762, @dom_walden wrote:

The wikitext markup for links is not being preserved (e.g. [[User:Admin|Admin]] is being shown as Admin).

Is this in the text in the summary value?

A few observations so far:

A few observations:

• The username field spans the entire page.
• If the dropdown overflows the page and has a scroll, if you use the keyboard to select it does not scroll down
• Going to Special:Block/1.2.3.4 does not prefill the form.
• It does not look quite right on Minerva (I think this is in part due to T353759)
  
• The dropdown is not in the Figma spec, so I don't know exactly how it should look. It looks the same as it does on OOUI, which I guess is OK.
• Home and End don't work as described in T310556.
• The API request to api.php?action=query&list=allusers is the same as OOUI except it uses origin. I don't know if that matters.

In T358804#9673104, @MusikAnimal wrote:

Per T357795 it's deployed on all wikis on Beta. Would it be helpful to keep at least one wiki still running CM5?

@MusikAnimal I cannot see any difference between CM5 and CM6 on beta. Am I doing something wrong?

@HMonroy I put $wgUseCodexSpecialBlock = true; in my LocalSettings.php and went to Special:Block.

In T361021#9665651, @Dreamy_Jazz wrote:

Suggested QA steps for a WMF production wiki (such as testwiki):

1. Attempt to create a account with the prefix ~
2. Verify that the username is considered invalid and you cannot create an account.

The reproduction steps didn't work for me as described. After removing the block, you cannot then change its local status. If it was disabled and you try to re-enable it, you see The user (0:0:0:0:0:0:0:1) you entered is not globally blocked and the corresponding row stays in global_block_whitelist (indefinitely?)

I don't think I have anything to add here, so I will move this to Done.

I have checked that new and legacy global block log entries appear correctly (e.g. links correct, information displayed). I have tested for IPs, named accounts and temporary accounts.

In T316856#9659602, @JWheeler-WMF wrote:

@dom_walden are you still able to reproduce this issue, and does it only happen on RTL editors?

@Dreamy_Jazz If I hide or suppress the log entry target, if I login as another user who only has local sysop rights I still see the link to local status which includes the hidden username/IP. This user would not normally have the right to see hidden/suppressed entries (they aren't a suppressor).

Passing the data feed from the description into ipoid, it returns:

{"@timestamp":"2024-03-26T11:09:07.493Z","ecs.version":"8.10.0","log.level":"error","message":{"err":"Error: ipaddr: the address has neither IPv6 nor IPv4 format: 5eb65739-071a-4fd3-b3dc-4-adb5bab9b01"},"trace.id":""}

In T354643#9657190, @Dreamy_Jazz wrote:

IP addresses should have already shown in that table, so I guess that is an okay difference. My guess is that the difference could have been caused by T359962.

In T360072#9638418, @Dreamy_Jazz wrote:

For this task I would suggest testing that no changes are observed in the functionality and in what data is returned by the API. This is because this change should have made no changes to the returned data or API interface.

In T354643#9638430, @Dreamy_Jazz wrote:

For this ticket I would suggest verifying no changes in the data returned by Special:CheckUser when running a Get actions check is observed. This is because the change for this ticket should have no user-visible changes.

In T358869#9644541, @Dreamy_Jazz wrote:

Moving to 'Needs QA' for QA to double check that this has been fixed now.

I cannot change the global block status of Drwpb1 on enwiki beta: https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Special:GlobalBlockWhitelist&address=Drwpb1

In T291821#9645629, @Driedmueller wrote:

I would also present and discuss a thing i also noticed, when i tried to reproduce the alternating surplusses between 0 and 1.7053025658242404E-13.
The reason for this behaviour lies in the incapability of PHP to do correct arithmetic operations on floating numbers.
A famous example of this is in PHP: 0.1 + 0.2 = 0.300000000000004.

For the requests Special:ListUsers?username=text&editsOnly=1 and Special:ListUsers?desc=1&editsOnly=1, the MediaWiki\Pager\IndexPager::buildQueryInfo query takes about 50ms in read-new and about 30ms in read-old (according to the logs). Curiously, this discrepancy only happens while logged out. While logged in, both read-new and read-old queries take about 20ms.

I used this script to call the ApiQueryBlocks API with a combination of different parameters (including bkusers, which I understand triggered this problem). I then extracted from the MW logs the line starting [rdbms] ApiQueryBlocks::execute which includes the query and the time the query took to run.

@tstarling If I make a request with a bkusers parameter which includes both usernames and IPs/ranges and the username, IPs and ranges are not blocked (or the username does not exist), I see this exception:

{
    "error": {
        "code": "internal_api_error_InvalidArgumentException",
        "info": "[a6349b72d293f0ea1b55adac] Exception caught: Wikimedia\\Rdbms\\Platform\\SQLPlatform::makeList: empty input for field bt_id",
        "errorclass": "InvalidArgumentException",
        "trace": "InvalidArgumentException at /var/www/html/w/includes/libs/rdbms/platform/SQLPlatform.php(245)\nfrom /var/www/html/w/includes/libs/rdbms/platform/SQLPlatform.php(245)\n#0 /var/www/html/w/includes/libs/rdbms/platform/SQLPlatform.php(678): Wikimedia\\Rdbms\\Platform\\SQLPlatform->makeList()\n#1 /var/www/html/w/includes/libs/rdbms/database/Database.php(3334): Wikimedia\\Rdbms\\Platform\\SQLPlatform->selectSQLText()\n#2 /var/www/html/w/includes/libs/rdbms/database/DatabaseMySQL.php(730): Wikimedia\\Rdbms\\Database->selectSQLText()\n#3 /var/www/html/w/includes/libs/rdbms/database/Database.php(1342): Wikimedia\\Rdbms\\DatabaseMySQL->selectSQLText()\n#4 /var/www/html/w/includes/libs/rdbms/database/DBConnRef.php(119): Wikimedia\\Rdbms\\Database->select()\n#5 /var/www/html/w/includes/libs/rdbms/database/DBConnRef.php(351): Wikimedia\\Rdbms\\DBConnRef->__call()\n#6 /var/www/html/w/includes/libs/rdbms/querybuilder/SelectQueryBuilder.php(724): Wikimedia\\Rdbms\\DBConnRef->select()\n#7 /var/www/html/w/includes/api/ApiQueryBase.php(415): Wikimedia\\Rdbms\\SelectQueryBuilder->fetchResultSet()\n#8 /var/www/html/w/includes/api/ApiQueryBlocks.php(300): ApiQueryBase->select()\n#9 /var/www/html/w/includes/api/ApiQuery.php(705): ApiQueryBlocks->execute()\n#10 /var/www/html/w/includes/api/ApiMain.php(1946): ApiQuery->execute()\n#11 /var/www/html/w/includes/api/ApiMain.php(922): ApiMain->executeAction()\n#12 /var/www/html/w/includes/api/ApiMain.php(893): ApiMain->executeActionWithErrorHandling()\n#13 /var/www/html/w/includes/api/ApiEntryPoint.php(158): ApiMain->execute()\n#14 /var/www/html/w/includes/MediaWikiEntryPoint.php(199): MediaWiki\\Api\\ApiEntryPoint->execute()\n#15 /var/www/html/w/api.php(44): MediaWiki\\MediaWikiEntryPoint->run()\n#16 {main}"
    },
    "servedby": "b6a42289990f"
}

In T291821#9622678, @Driedmueller wrote:

Alternatively, it would be great, if there is may be another and more simple example ballot, with which the bug could be reproduced?

I set $wgAccountCreationThrottle and $wgTempAccountCreationThrottle to different values on my local wiki. I see that two different throttles are applied when creating a temporary user (i.e. editing while logged out) and when creating a named user via Special:CreateAccount.

@kostajh Should this task still be in review? I see one open patch.

In T291821#9619132, @Driedmueller wrote:

I tried again with dcbad8c and ba9476b58d2d (with patch given) and get the same results.

IPInfo appears to now be able to retrieve information about IPv6 addresses from ipoid.

I have imported revisions made by IPs via Special:Import and API:Import.

Tallying via the CLI on our beta environment, I am getting the same exception I was getting in T290027#7376288:

$ mwscript extensions/SecurePoll/cli/tally.php --wiki=votewiki --name=20_7_5000_425367464
/usr/local/bin/mwscript: line 27: 32355 Segmentation fault      sudo -u "$MEDIAWIKI_WEB_USER" $PHP "$MEDIAWIKI_DEPLOYMENT_DIR_DIR_USE/multiversion/MWScript.php" "$@"

In T291821#9595294, @Driedmueller wrote:

Hello!

I tried to reproduce the bug, but was not successful yet.
I checked out the state of the STVTallier algorithm from Aug 19, 2021 (https://gerrit.wikimedia.org/r/c/mediawiki/extensions/SecurePoll/+/712409) to make sure the bug has not been fixed meanwhile.

I have checked out Special:EditRecovery on beta in a couple of different languages (incl. RTL) and skins. I see the date changes depending on the language you choose (although I cannot verify the translated date is correct).

We appear to be recovering from duplicate IP errors without interrupting the import completely (i.e. other IPs in the feed are imported).

In T357675#9595051, @Dreamy_Jazz wrote:

In T357675#9595004, @dom_walden wrote:

@Dreamy_Jazz I have done all the testing I had planned to do so far. As this is still unmerged, should this task be moved back to Review?

@dom_walden, I had incorrectly tagged this change against this task. QA for the change still in review will be done in T358155.

I have found an example of a missing IP where there is a duplicate IP in yesterday's feed.

In T357675#9565627, @gerritbot wrote:

Change 1005621 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):

[mediawiki/extensions/GlobalBlocking@master] [Very WIP] Update GlobalBlockLookup for global account blocks

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

If the IP in the request to /feed/v1/ip/<ip> is invalid, it returns a 400 with response body "<ip> is not an IP address".

In T341228#9583535, @Dreamy_Jazz wrote:

Testing notes that I used to test this change which may be useful for QA:

In T354758#9590583, @kostajh wrote:

Maybe instead of ipaddr.js library, we should copy/paste mw.util.prettifyIP and make use of that in ipoid:

All looks good.

@STran I don't think IPInfo is retrieving information about IPv6 properly. With the below test data, if I make an edit as IP 2001:2::b706:5bd3:f2b:9e33 and look at the Special:Contributions, the ipoid data is all null. When I look in the logs I see:

[http] [2024-03-01T11:52:51+00:00] GET http://172.18.0.1:6927/feed/v1/ip/2001:2:0:0:B706:5BD3:F2B:9E33 HTTP/1.1 - 200 NULL
[IPInfo] ipoid results were not in the expected format: {"2001:2:0:0:b706:5bd3:f2b:9e33":{"ip":"2001:2:0:0:b706:5bd3:f2b:9e33","org":"Foobaz","client_count":0,"types":["UNKNOWN"],"conc_city":"","conc_state":"","conc_country":"","countries":0,"location_country":"IN","risks":["CALLBACK_PROXY"],"last_updated":1709293854,"proxies":["OXYLABS_PROXY"],"behaviors":[],"tunnels":[]}}

In T356923#9583459, @Dreamy_Jazz wrote:

I would suggest that no QA is needed for this ticket because the configuration value is currently un-used. Testing that this configuration value works as expected will be done in other tickets.

As a temporary user, I cannot access either Special:Preferences or Special:GlobalPreferences. Instead, I am taken to the login form.

I tested creating and modifying blocks and checking the data is correct in the database.

In T351435#9579076, @Samwilson wrote:

Do you get a notification when re-opening it though, at step 3? The new warning is within the same notification toast. If you click one of the buttons at that point, it'll disappear.

I see that the appropriate class mw-editfont-* is added to div.cm-content.

In T351435#9575384, @Samwilson wrote:

You have to have saved a new revision of the page after you opened it for editing, something like:

I cannot get the new message to appear when doing "Show preview" or "Show changes". @Samwilson how do you trigger this?

As this appears to be a change to how we deploy/build svgtranslate, I don't know if there is anything I can do to test this.

I don't see the warning on beta anymore. I hope that means it has been removed correctly.

Testing this on beta and inspecting the network tab, I see

• after recovering an edit a request to https://en.wikipedia.beta.wmflabs.org/beacon/statsv?MediaWiki.edit_recovery.show.by_wiki.enwiki=1c
• after discarding an edit a request to https://en.wikipedia.beta.wmflabs.org/beacon/statsv?MediaWiki.edit_recovery.discard.by_wiki.enwiki=1c