See below output of successive runs of the WikimediaMaintenance/createExtensionTables.php script:

$ docker-compose exec mediawiki php extensions/WikimediaMaintenance/createExtensionTables.php mediamoderation

In T350116#9365050, @gerritbot wrote:

Change 977680 merged by jenkins-bot:

[mediawiki/core@master] EditPage: Remove unnecessary extra check for blocks

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

I cannot reproduce the exception either on beta (MariaDB) or locally (SQLite).

@tstarling Drawing attention to T352310. Is there a migration stage we have to do on beta?

In T344942#9362959, @STran wrote:

This is expected behavior for now. I think we'll have a discussion later on about historical data/updating IP information.

In T351869#9362394, @Samwilson wrote:

I'm trying to replicate this but can't yet. Do you think it's related to T351821: Edit Recovery interaction with browser data recovery? It sounds like it's not seeing any difference between the 'original' data and what's now stored, probably because it's got the wrong idea of what 'original' is.

In T343089#9279268, @gerritbot wrote:

Change 967683 merged by jenkins-bot:

[mediawiki/core@master] Edit Recovery: only save when form contents has changed

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

I have raised T352028, but I wonder if we should just move the current bug back into In Development?

This also happens after you close and restore a tab (ctrl+shift+t). I am still investigating.

@STran @Tchanders We don't appear to be updating the tunnels if their type changes. This could affect what is returned by the /vpn endpoints. Is this OK?

I can no longer reproduce the error from the description.

In T350500#9343794, @kostajh wrote:

Could probably skip QA? cc @dom_walden

In T344942#9118302, @Tchanders wrote:

@STran I'm not making this a deployment blocker, because I don't believe we are using these values to begin with. Is that correct?

I notice we are doing arrayCompare for client.countries, which seems wrong as they are integers. https://gitlab.wikimedia.org/repos/mediawiki/services/ipoid/-/blob/main/output-sql.js?ref_type=heads#L120

In T344703#9341678, @Niharika wrote:

@dom_walden can you confirm if this bug still persists?

I tested this along with T349826.

Some examples of multiple block messages on beta and locally.

I think I have done with this for now.

@MusikAnimal I did a bit of testing of this on Friday and found a few potential bugs. In order of importance (in my opinion):

• There are circumstances where clicking on "Review link" will take you to the blocked url instead of opening the "Insert link" dialog.
  • This happens when you move or delete the link you just inserted before clicking "Review link".
    • e.g. type a link, see the popup, before the link type "[", click "Review link"
  • Having the blocked url as the href of the "Review link" seems vulnerable to me. A user might open it in a new tab. I also don't know if all browsers/devices will behave the same way when you click on it.
• If the blocked URL is not the first thing on the line, after clicking "Review link", the URL automatically entered in the "Insert link" dialog is incorrect.
  • e.g. type foobar <blocked URL>, click "Review link", in the "Insert link" dialog the URL will be "foobar <blocked URL>"
• The popup only appears if the URL starts with http:// or https://, even if you add it after.
  • You can make a legit link with just // (e.g. [//<blocked URL>]). If you try to publish this, AbuseFilter will stop you (at least on beta). Perhaps we should maintain functional parity.
• If there is already a popup and you trigger another popup, it flashes in the top left.
  
• If copy and pasting, only warns if the blocked URL is just before point.
  • e.g. copy and paste foobar <blocked URL> foobaz, you will not see a popup
• If the text of the link is a blocked domain but the actual link is not, still see popup.
  • e.g. [https://duckduckgo.com <blocked URL>]
  • Arguably a popup here is not so bad as the edit does not seem in good faith.
• Does not always work well with find and replace.
  • Not triggered if you do "Replace all".
  • If you do "Find next" and "Replace" one by one, the "Review link" does not insert the link in the correct place.
    

First time, I have to run node -e "require('./init-db.js')(true);". Any other combination of parameters returns the below exception. I guess this makes sense.

/srv/service/node_modules/mariadb/lib/misc/errors.js:64
  return new SqlError(msg, sql, fatal, info, sqlState, errno, additionalStack, addHeader);
         ^

So far, the only bug I have found is T348745. More testing will be done after the fix for that.

Probably no testing needed here. Will move to Done.

More testing of this will be done as part of T348992. I will move this to Done.

In T344463#9287523, @gerritbot wrote:

Change 965048 merged by jenkins-bot:

[mediawiki/core@master] Display all error messages for a CompositeBlock

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

In T345683#9279144, @dom_walden wrote:

@tstarling Since this change, when attempting to edit as an IP from an IP that is blocked and ip masking is enabled, the block message is duplicated.

In T341660#9287071, @Tchanders wrote:

The non-deterministic problem should be solved, so I'll close this in favour of the other task.

I can activate Phonos buttons with errors with enter and space.

In T348714#9278281, @HMonroy wrote:

@dom_walden I'm still having trouble reproducing this issue. I noticed that if I'm logged in as the same user for step 2 and 3, I don't get the conflict mentioned in step 5.

Does step 1 applies to both step 2 and 3? Or only step 2 needs to be logged in? Are you still able to reproduce this?

Many thanks!

In T345683#9267387, @gerritbot wrote:

Change 964610 merged by jenkins-bot:

[mediawiki/core@master] Multiblocks preparation in User::getBlock(), PermissionManager and BlockManager

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

I have found cases where this bug happens for /vpns as well. Importing the Spur feed from 20231017 and comparing /vpns and /vpn/NORD_VPN the former has a smaller number of IPs compared to the latter.

@HMonroy @TheresNoTime Did we want a tooltip or a help icon (i)? The task description and the user's comment suggests we want a tooltip.

Whitespace is trimmed when included in either the label or ipa parameter.

In T347869#9252400, @Samwilson wrote:

In addition to not loading Edit Recovery when undoing edits, I wonder if we would want to also delete any edit recovery data for the page — because if someone's undoing to an earlier revision it's pretty likely that they're not worried about any work in progress they have for that page. Although I guess they could have started editing, hit a conflict, then gone to undo the conflict so that they can save without any issues?

In T327966#9247230, @Etonkovidova wrote:

Yes, it can be a valid approach to Quickstart checklist too. One of my concerns for such a pre-set, detailed Quickstart checklist was that any specific instructions, e.g. - Use Chrome Lighthouse and report as a separate phab task any found defect might not suit to current needs of a specific team or a project.

In T327966#9221250, @Etonkovidova wrote:

In T327966#9216064, @dom_walden wrote:

https://www.mediawiki.org/wiki/User:DWalden_(WMF)/A11y_playbook_draft3

Current latest draft. I need help filling out the "Quickstart" section.

I think this section could have some general instructions (with references to different sections of the document). Here is an outline

• check with your team what (or if) a specific project/features need in terms of accessibility testing
• create a QA checklist for accessibility testing (and communicate it if needed to your team for feedback). Your QA checklist might include details about what approach/techniques you'll use)
• based on the above, the results of accessibility testing might be reported in phab task(s) or documented differently

In T344273#9243228, @Tchanders wrote:

@dom_walden The actual issues you found via testing haven't been fixed yet. Do you think we should wait for those to be fixed before further QA?

I think I found a way to reproduce the bug by setting this database trigger:

CREATE TRIGGER stop_insert BEFORE INSERT ON recentchanges FOR EACH ROW DELETE FROM logging WHERE log_id = new.rc_logid;

Every time a row is inserted into the recentchanges table, the associated row in the logging table is deleted. It might be a bit unrealistic, but it seems to reliably reproduce the bug in the parent commit.

I tested all the different combinations of visibility for a log entry.

The Checks done by this user link does not appear for temporary users and IPs. It does for regular users.

In T328995#9215238, @Dreamy_Jazz wrote:

I think everything else is okay so QA shouldn't be blocked for this task (let me know if I've missed something).

Current latest draft. I need help filling out the "Quickstart" section.

Another potential risk of this change is that every time an editor visits the Source Editor for a page Edit Recovery will save the current content (even if they don't make an edit).

@Samwilson I cannot get it to clear the indexeddb data when I click Cancel on the edit page, like it did before. Is that because it is triggering one of the events?

Special:CheckUser now correctly parses a variety of log parameters, including those that use the legacy log params such as global block and interwiki. I did not see any errors or warnings on the page or in the logs.

When attempting to login as a temporary user, I don't see any emails or echo notifications, nothing new in echo_event database, and in the logs I see:

[LoginNotify] Skipping recording failure for user *Unregistered 232 - can't authenticate

I see I can download today and yesterday's feed. The files are different sizes, so I assume they are different files. I cannot verify that the files are for the correct date.

Differences that I have observed so far between SCHEMA_COMPAT_READ_OLD and SCHEMA_COMPAT_READ_NEW:

1. Usernames, temporary usernames and IPs are links, have mw-userlink class and are wrapped in <bdi>. Before they were plain text.
2. Temp user links to special:contribs and has mw-tempuserlink class, so they are properly styled.
3. Many entries now have two log links (log | logs), for the Special:Log&logid=<log id> and Special:Log&page=<page or user> respectively.
   
4. Entries for group membership changes use the public(?) name for user groups, not their internal name. For example, it says administrator rather than sysop.
5. Entries for blocks have the expiry in a <span class="blockExpiry" title="‎infinity">indefinite</span>, which means you get a tooltip.
6. It recognises where a page is a redirect and adds redirect=no to the page's URL.
7. Entries of page suppressions show in full. Before they showed as (username removed) (log details removed).
   

I compared the HTML output of "Get users" with SCHEMA_COMPAT_READ_OLD and SCHEMA_COMPAT_READ_NEW for all the IP addresses I had on my local wiki. There were no differences.

The Inline toggle now has aria-labelledby, which refers to the <label>Inline</label> element.