Testing for risk of regression, I tested a few special pages which used or inherited from IndexPager (which I think is all of them).

Testing for risk of regression, I tested a few special pages which used or inherited from IndexPager (which I think is all of them).

I ran a selenium script to check the correct data is in the revision popup for a small sample of articles from enwiki, eswiki and trwiki.

In T240585#5886223, @dmaza wrote:

@dom_walden I can't reproduce this as anymore as of 005ce473e11b7fae03643d71fa7f092ab318dd7d
Switching back to b8d4d55d8950 does shows the warning.
There was a lot of refactoring on the file that this was failing and it should be fixed now.

Searching just for IPs:

As with T242759#5916137, I looked at revision popups in different languages. I could not see any obvious problems with the padding.

In every language WWT supports I've looked at two revision popups (one for attribution percentage more than 1%, one for less).

• There is a new tab next to Preliminary check for Compare

In T238782#5914447, @Prtksxna wrote:

In T238782#5898063, @dom_walden wrote:

Also, I don't know if it is just my screen, but I don't find the dark background much darker than the other cells in the table.

Eek, this is a problem! While I can see the different grays in that screenshot we need to make sure that the contrast can bee seen on all types of screens. @dom_walden which screen are you using? Are the screenshots below any better?

The error message now looks like:

• Make WWT extensions discoverable & available to all users in Chrome/Firefox web stores (i.e., direct URL not needed)

I wanted to test that on Special:BlockList:

• No results (blocks) were missing or duplicated across pages
• The order of results was "correct".

Autoblock cookie remains after logging in as admin, but not applied. Remains after logging out (so user is blocked again).

In T238714#5898883, @Niharika wrote:

@dom_walden In my understanding, in current CheckUser, new account creations and other log entries are shown when someone picks the 'Get users' option, right?
If so, we got that covered under the Timeline tab.

• Results in the compare tab appear paginated with the highlights, filters and sorting working as selected by the user

Obviously there is no highlighting, filtering etc. to test yet.

Tabs seem to work fine.

In T239716#5898163, @Tchanders wrote:

@dom_walden Not sure to what extent this needs testing - it doesn't change the pagers, just how they're created. I checked the pagers are both still there and not doing anything odd.

1. For an input username:
   • IP addresses they have used
     • FYI note that this is limited to the past 90 days by our data policy limits so we won't find anything from before that

• If an IP and username looked up are in the same row, make both the IP address and the username bold with darker background.

I think I have tested this before, but with all the recent changes I guess it is as well to retest it.

I think the changes made to PreliminaryCheckService have been made obsolete by T244517. I don't think there is anything to test here.

The wiki column links to the User:$user page for the correct user and wiki.

Testing this on https://en.wikipedia.beta.wmflabs.org (version: MediaWiki 1.35.0-alpha (c664b4f) 17:32, 18 February 2020).

In T238961#5885739, @ifried wrote:

Hello @dom_walden and @Samwilson
There seems to be some confusion (and apologies if there was any!). From what I read in the QA notes: If the user has PRU option checked in Special:Preferences and you enter only their username. Normal PRU message: "Both username and email address are required to receive a temporary password via email."

Briefly retested muting and unmuting users on Special:Mute on enwiki. Also checked that I could use it to mute globally (when I set the option globally).

@dmaza When submitting the form, I no longer see the exception in the description.

After submitting the form, the preliminary check table appears on its own page.

@dbarratt On the preliminary check table, when I attempt to go to a previous or next page I get:

[3d583d0a95a869c404a8887a] /w/index.php?title=Special:Investigate/Preliminary_Check&limit=10&token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleHAiOjE1ODE2NzYwNTcsImRhdGEiOiJHVjRJNjArK2hobHZsaDl2Q1JOSGRWaWRkS1RVZE9NbWNGMytSSmE0NVlNNGFjXC82cEI3a0hMSEJ1Rk0zK0RMQWFSWG03UDJiSWc9PSJ9.qj1RfHQc0Il2WfiWP3rlJ0t77rT5p_IuUDXFGiATAQM TypeError from line 59 of /vagrant/mediawiki/extensions/CheckUser/src/TokenManager.php: Argument 1 passed to MediaWiki\CheckUser\TokenManager::encode() must be an instance of MediaWiki\Session\Session, instance of User given, called in /vagrant/mediawiki/extensions/CheckUser/src/SpecialInvestigate.php on line 120

I used a script to systematically cover every (valid) combination of username + email based on:

• Is the username/email blank
• Does the username/email exist on the system
• Does the username/email have PRU enabled
• Does the username have an email associated with it
• Has the username/email hit their password reset request limit (more than one request in 24 hours)

It is no longer there on my local version, CheckUser 2.5 (ed83bea) 00:33, 7 February 2020.

Testing for this was done at the same time as T243075.

Testing the Page and Namespace input in Special:Block and email-blacklist in Special:Preferences, comparing beta with test.

Bug in T243075#5829744 no longer occurs Special:Preferences on https://en.wikipedia.beta.wmflabs.org (1.35.0-alpha (74b7a2b) 14:09, 4 February 2020).

I can no longer add a tag, unless it is of a valid user.

In T238277#5810885, @Tchanders wrote:

This depends on config (see T238277#5705031). In Special:Investigate on testwiki, the menu should appear for:

• Any valid IP address
• Any valid IPv4 range ending /16 or higher
• Any valid IPv6 range ending /32 or higher

@Tchanders When you submit the Special:Investigate form, the usernames get cleared (although the data appears to get posted). This does not happen before the commit in T243075#5828523.

I can no longer reproduce the bugs in the 3 examples.

In T242759#5813216, @MusikAnimal wrote:

PR https://github.com/wikimedia/WhoWroteThat/pull/147

The WWT translations now work for roa-tara (https://en.wikipedia.org/wiki/Mast_(sailing)?uselang=roa-tara).

If the edit summary is hidden, the revision popup shows (edit summary removed).

Not much to test here. Moving to Product sign-off.

The PRU checkbox is now above the "Email confirmation:" section.

In T239840#5822145, @Samwilson wrote:

In T239840#5822102, @dom_walden wrote:

@Samwilson The German version has no description. Should it fall back to English? (https://addons.mozilla.org/de/firefox/addon/whowrotethat/)

Oh weird: you're right, it didn't have a description. So I opened it for editing, clicked into the empty description box, then without typing anything clicked save. Now it falls back to English correctly!

@Samwilson The German version has no description. Should it fall back to English? (https://addons.mozilla.org/de/firefox/addon/whowrotethat/)

In T233091#5819988, @ifried wrote:

@dom_walden Is this still an issue? I'm unable to reproduce the issue, but maybe you're still seeing it. Let me know. Thanks!

If, for the user, the setting is not global -> save in local
If, for the user, the setting is global -> save in global
If, for the user, the setting is global *but* uses local override -> save in local override.

Acceptance Criteria:

• Confirm whether or not PRU can be made a global preference for all users

@ifried I am moving this into Product Sign-Off, but it has yet to be released to the Chrome Store or Firefox Addons.

For each of the five supported wikis, loaded a random article both with the Welcome Tour popup and without it.

After submitting an edit using VisualEditor, WWT uses the correct revision ID, which means the changes made in the edit are reflected in WWT.

In T241062#5793562, @HMonroy wrote:

In T241062#5789558, @Mooeypoo wrote:

Note: I'm fairly sure this will be a lot easier to do (if not outright fixed?) with the refactoring PR at https://github.com/wikimedia/WhoWroteThat/pull/128

I believe this issue was fixed with this pull request. I'm no longer able to replicate it.

On Turkish Special pages (e.g. https://tr.wikipedia.org/wiki/Özel:SonDeğişiklikler) wwtDebug is not defined, which means WWT is not loaded (which is what we want).

Testing with a variety of RTL languages, some for which we have translations (e.g. Hebrew) and some for which we don't (e.g. Farsi).

The plus/minus sign now always appears to the left of the numbers. This is the case even in RTL languages and where a language has its own number system (e.g. Arabic).

And I don't know what is going on here, edit summary cut off:

@Samwilson I'm still not able to get this to work for roa-tara. Can for pt-br and zh-hant.

@Mooeypoo I think this has slightly changed the display of revision popups.

Text now reads: "Activate the tool from the sidebar. Hover over text to highlight contributions by the same author. Click to see the author and revision details."

In T240262#5770063, @Mooeypoo wrote:

PR: https://github.com/wikimedia/WhoWroteThat/pull/127
We still have the "problem" of the lighter line crossing the infobox, but now it only happens when you hover over the specific template, which (at least in my opinion) gives the user some sense of what it's attached to as a box on the screen.

For a few random enwiki articles, I checked that the revision popup appears over the top of the infobar and also image thumbnails, templates, badges, and other parts of the UI (e.g. search bar in timeless).

Recently, I have found this in a number of places, e.g.:

• https://en.wikipedia.org/wiki/Jonathan_Foster_(neuroscientist)
• https://en.wikipedia.org/wiki/Nagendra_Saklani
• https://en.wikipedia.org/wiki/Ross_Nickerson
• https://de.wikipedia.org/wiki/Dennis_Muilenburg

On each of the 5 supported wikis, I walk through the menu items to find different special pages, portals, etc.

I loaded random articles on en, de, es, eu and trwiki. Each wiki was on a different skin and language. Watching for any slowdowns or long-running scripts.

I think the fix in T236702#5726839 is already deprecated by T240707. We now show 3 shimmer lines in edit summaries.

In T239842#5752904, @Samwilson wrote:

I am seeing the WWT link on pages like the Main_Page or in other namespaces (e.g. User_talk).

This was T240690 and has been fixed now.

Acceptance Criteria:

• Remove the display of the username/IP address from the information bar in WWT

Acceptance Criteria:

• Don't italicize 'Who Wrote That?' in the guided tour pop-up

Acceptance Criteria:

• Remove italicization of 'Who Wrote That' in the loading state of the information bar

@MusikAnimal FYI, I found bug T241062 while testing this change. The bug existed before your change, although the impact of it is greater now.

I believe testing this is covered by T239937#5750498.

Acceptance Criteria:

• If the email is confirmed or unconfirmed, display the following message: "Account recovery is enabled. See Email options for settings."

The PRU checkbox now appears on test and test2.

In T240586#5749243, @Niharika wrote:

I did not know hidden blocks were a thing.

I believe this has/will be fixed here: T234709#5739746.

In T240300#5738780, @dom_walden wrote:

There are no translations to test yet. I have made a todo for myself to test these as soon as they are up.

The functionality now appears to be ok:

• Hovering over an image thumbnail shows the contributor name in the infobar
• Any other tokens added by that contributor are highlighted
• Clicking the thumbnail shows the revision popup

After clicking a token, the Edit Summary gets cached. If you click the same token, or another token which was added in the same revision, the Edit Summary appears immediately.

@ifried Should this show even if PRU is not enabled on the wiki? ($wgAllowRequiringEmailForResets)

@MusikAnimal Oh damn. I missed that the toolbar is now over the revision popup. Do you want a separate bug?