I have looked at Special:Contributions for various temporary accounts on testwiki, testwikidata and test2wiki.

I can confirm this new bucketing. I notice that, if the CheckUser data is expired, it will show 0 associated accounts. I wonder if this might confuse people as to whether the current temp user is included in the associated count or not.

I am seeing the exact figure when I have IP Reveal rights. If I don't I still see the buckets in the subtitle.

I cannot reproduce this particular bug. There are some other bugs (e.g. T417250) and more testing will be done when those are fixed.

I cannot reproduce this particular bug. There are some other bugs which we need to be fixed (e.g. T417177) and further testing will be done after this.

I checked this out on beta in different skins and in RTL.

I tested different groups with different combinations of memberConditions, updaterConditions and canBeIgnored being true or false.

In T411260#11415809, @Dreamy_Jazz wrote:

@dom_walden have you tried testing on a wiki where the content language is not English? The options in that dropdown are configured to only be shown in the content language (though that may need to be changed)

I can no longer reproduce this exception. If I go to Special:WatchlistLabels/edit&wll_id=<id> for a label ID that is not my own, when I submit it will create a new label.

I can confirm the points from Specification on testwiki and test2wiki. Also, if I am not blocked and go to Special:MyTalk, I am redirected to the login page.

This is only a change to a translation file, so moving this along.

Testing locally, I see no differences when comparing the results from Special:GlobalContributions with action=query&list=usercontribs for various change tags.

In T409431#11400132, @kostajh wrote:

Hmm, rawmessage in action_context isn't intended or helpful from a data analysis perspective. What was the error message you saw on the page?

Thanks. Trying again I do see this request:

{
  "action": "form_error",
  "funnel_entry_token": "14f0e2cb45ebf6ad700d",
  "action_source": "form",
  "action_context": "rawmessage",
  "funnel_name": "create_account",
  "funnel_event_sequence_position": 1,
  "$schema": "/analytics/product_metrics/web/base/1.3.0",
  "agent": {
    "client_platform_family": "desktop_browser",
    "client_platform": "mediawiki_js"
  },
  "performer": {
    "language": "en",
    "pageview_id": "1700b6b2ad7f5163b4df",
    "session_id": "c0c2f8d0dace1cd099ee",
    "active_browsing_session_token": "c4de71eb9ce48acd475d"
  },
  "dt": "2025-11-24T11:30:24.556Z",
  "meta": {
    "stream": "mediawiki.product_metrics.special_create_account",
    "domain": "test.wikipedia.org"
  }
}

In T392896#11326071, @Samwilson wrote:

I think the remaining issues here are already tracked in other tasks, and this one can probably be closed.

I have tested adding and editing watchlist labels. There might be more testing to do, but probably at a later date when more features have been implemented.

Nothing to test?

I don't have access to the risk scores so I cannot test.

Thanks Sam.

Various QUnit tests are implemented. I don't fully understand what they do or how they work, so this is just my best guess.

The current implementation does not exactly match the design. There is still functionality to be implemented.

Trying to create an account using a Tor proxy, here is the request to https://intake-analytics.wikimedia.org. Is this right @kostajh?

{
  "action": "hcaptcha-execute",
  "funnel_entry_token": "2c0b434868fac6f8c6a1",
  "action_source": "form",
  "action_context": "55.978",
  "funnel_name": "create_account",
  "funnel_event_sequence_position": 12,
  "$schema": "/analytics/product_metrics/web/base/1.3.0",
  "agent": {
    "client_platform_family": "desktop_browser",
    "client_platform": "mediawiki_js"
  },
  "performer": {
    "language": "en",
    "pageview_id": "8d6b620a6ca7e02b9d37",
    "session_id": "1caa8c7320a723b6d03f",
    "active_browsing_session_token": "caac5d2e70b0c34cf8c5"
  },
  "dt": "2025-11-18T08:57:48.956Z",
  "meta": {
    "stream": "mediawiki.product_metrics.special_create_account",
    "domain": "test.wikipedia.org"
  }
}

Publishing an edit in the WikiEditor on testwiki, when I see an hCaptcha challenge, I see two requests to https://intake-analytics.wikimedia.org:

{
  "event": {
    "user_id": 71434,
    "user_is_temp": true,
    "user_editcount": 2,
    "wiki": "testwiki",
    "skin": "vector-2022",
    "is_bot": false,
    "feature": "hcaptcha",
    "action": "execute",
    "editor_interface": "wikitext",
    "integration": "page",
    "platform": "desktop",
    "editingSessionId": "781b558ba9fb797a08c1632fe335e62b",
    "is_oversample": false
  },
  "schema": "VisualEditorFeatureUse",
  "webHost": "test.wikipedia.org",
  "wiki": "testwiki",
  "$schema": "/analytics/legacy/visualeditorfeatureuse/1.1.0",
  "client_dt": "2025-11-18T08:41:36.088Z",
  "meta": {
    "stream": "eventlogging_VisualEditorFeatureUse",
    "domain": "test.wikipedia.org"
  }
}

{
  "event": {
    "user_id": 71434,
    "user_is_temp": true,
    "user_editcount": 2,
    "wiki": "testwiki",
    "skin": "vector-2022",
    "is_bot": false,
    "feature": "hcaptcha",
    "action": "open",
    "editor_interface": "wikitext",
    "integration": "page",
    "platform": "desktop",
    "editingSessionId": "781b558ba9fb797a08c1632fe335e62b",
    "is_oversample": false
  },
  "schema": "VisualEditorFeatureUse",
  "webHost": "test.wikipedia.org",
  "wiki": "testwiki",
  "$schema": "/analytics/legacy/visualeditorfeatureuse/1.1.0",
  "client_dt": "2025-11-18T08:41:39.579Z",
  "meta": {
    "stream": "eventlogging_VisualEditorFeatureUse",
    "domain": "test.wikipedia.org"
  }
}

We checked that we could trigger the addurl consequence via the VisualEditor, DiscussionTools and the MobileFrontend (source and visual) yesterday on testwiki.

In T407853#11302934, @Cparle wrote:

... and the item gets removed from the list. It's the same if I don't select the namespace. FWIW I have 106 items in my watchlist

I wonder if this is another example of T407853.

In T405597#11370208, @kostajh wrote:

In T405597#11369611, @dom_walden wrote:

@sguebo_WMF @kostajh Where would I see these events? I have tried https://graphite.wikimedia.org/ and https://stream.wikimedia.org/v2/ui/ but cannot find mediawiki.hcaptcha.risk_score.

This is in event logging data, so you can query it with spark3-sql, or on stat1010.eqiad.wmnet, you can also do kafkacat -C -b 'kafka-jumbo1010.eqiad.wmnet:9092' -t codfw.mediawiki.hcaptcha.risk_score -o O | jq to monitor the stream of events.

I can confirm this happens on testwiki and test2wiki. On submitting an edit which triggers a filter, I see the edit page and submitting again shows the hCaptcha challenge.

I haven't seen this bug happen since on testwiki.

I could not work out how to test this on testwiki. I copied the config to my local environment and then made HCaptchaEnterpriseHealthChecker::isAvailable() always return false. Then, editing on the wikieditor I don't see the hCaptcha being loaded or triggered on submit.

Making an edit which includes an external URL on testwiki and test2wiki, I do not need to fill in a FancyCaptcha(?) after submitting.

@sguebo_WMF @kostajh Where would I see these events? I have tried https://graphite.wikimedia.org/ and https://stream.wikimedia.org/v2/ui/ but cannot find mediawiki.hcaptcha.risk_score.

@kostajh What counts as an "Account creation error" page? On testwiki, I have tried entering passwords which don't match, usernames starting with ~2025, usernames with WMF in them, and usernames which already exist. I don't see any requests to either /beacon/statsv or https://intake-analytics.wikimedia.org that appear to relate to errors.

I see the submit button is disabled when attempting to publish an edit. I am unable to submit the form multiple times, either with mouse or keyboard.

Testing on testwiki and recording the events that get sent to https://test.wikipedia.org/beacon/statsv.

@sguebo_WMF After an error, the submit button does not respond anymore. I don't know if this is related to this work. I did this by changing the data-sitekey attribute of the div.h-captcha element and triggering the hcaptcha challenge.

@sguebo_WMF I find that the submit button is not disabled when action=submit (I am testing by making an edit, switching to VE and then switching back).

I was prevented from doing an edit via ContentTranslation, but I was not shown a captcha to fill in, I just saw an error Unsupported captcha type encountered.

I have been able to make edits on enwiki beta with external links. I saw the AbuseFilter captcha consequence as appropriate and was able to fill in the challenge and publish the edit.

I can confirm this on enwiki beta.

I did some brief regression testing of Special:Watchlist, Special:EditWatchlist (including /raw and /clear).

If you filter for a namespace where you have no watched pages, you see You have no items in this namespace on your watchlist.

I also don't see a captcha when I trigger a filter during the move, delete or upload actions. I had to test these locally because non-autoconfirmed users cannot normally do these actions.

In T407907#11343499, @kostajh wrote:

In T407907#11340668, @dom_walden wrote:

I was able to create a new page in the Talk namespace (new users cannot create main pages on enwiki beta). Apparently I triggered the AF rule, but I did not actually see the captcha. My user did not have skipcaptcha.

I don't know about beta cluster, but it works fine on test.wikidata.org with this filter https://test.wikidata.org/wiki/Special:AbuseFilter/30

I was able to create a new page in the Talk namespace (new users cannot create main pages on enwiki beta). Apparently I triggered the AF rule, but I did not actually see the captcha. My user did not have skipcaptcha.

@kostajh Is this related? T409154

In T406037#11324177, @Mstyles wrote:

I assume they should all have index=-1. Otherwise, tabbing through the page takes you to the footer before it takes you to the form inputs.

Per https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/tabindex: "A negative value (the exact negative value doesn't actually matter, usually tabindex="-1") means that the element is not reachable via sequential keyboard navigation."

We don't want everything to have index=-1 because that would mean we don't want the user to tab there. While the order is not currently optimal, tabbing does eventually get you to the input box.

In T406037#11320725, @Mstyles wrote:

@dom_walden what do you think the tab order should be for the images listed? Outside of the WebAuthn error page, I think that the other pages seem to tab okay and the tab index increases. Is it that the bottom of the page has tab index set to 0 that's an issue for the other pages?

@kostajh Should this be working on testwiki? I tried it and, although it is being logged, I don't actually see any captcha challenges.

In T400243#11285323, @Dreamy_Jazz wrote:

I don't think this is resolved? The issue wasn't actually fixed during the election

I have retested after patches T407222#11305681, T407222#11312565 and 1198554.