Page MenuHomePhabricator

Commons QICvote stopped working
Closed, ResolvedPublicBUG REPORT


Steps to replicate the issue (include links if applicable):

What happens?:

  • You can set up a vote, but you can't submit the votes

What should have happened instead?:

  • After marking a vote, the count should appear in the bottom bar, and when you click 'Confirm reviews' an edit should be made to the page

Software version (skip for WMF-hosted wikis like Wikipedia):

  • Commons

Other information (browser name/version, screenshots, etc.):

  • All browsers

This was working until 12:52, 10 July 2023‎ - which was when the last edit was made using the gadget. No edits have been made to the gadget code (at ) - did something change with MediaWiki that has broken the process?

Event Timeline

I see jQuery.Deferred exception: $(...).parent().find(...).last().attr(...) is undefined thrown in _getImageName. Based on the stack trace and the timing, I’d guess T314318: Disable wgParserEnableLegacyMediaDOM on all wikis.

I made a quick edit based on the pattern in,

But I'll take the time to give the gadget a more thorough reading. Please let me know if it helps.

Thank you so much, that seems to have fixed it!

Arlolra claimed this task.


Please note, as @Tacsipacsi did above, that a change was made earlier this week to how media is rendered by MediaWiki's parser, which, given the nature of commonswiki, might have an outsized effect there. If you notice any other breakage, don't hesitate to ping me.


This is unrelated to the MediaWiki-extension called "Gadgets"

It seems to have stopped working again in the last hour, but at a different point of the process. You can enter votes, and you see "1 pending review confirmations" - but 'Confirm reviews' doesn't work. Did something change in the last hour?

I changed QIvoter.js literally just now for T341863, but if it’s due to that then you found it extremely quickly, so I’m a bit skeptical.

Hmm, perhaps that was it? It seems to be working OK again now.

Hmm, or not, it stopped again. Very odd.

The train reached Commons 100 minutes before your comment (T340246#9029325), maybe WP:ITSTHURSDAY?

@Mike_Peel Is this still an issue for you? Can you try a hard refresh of the page? CTRL-Shift-R

@Mike_Peel Is this still an issue for you? Can you try a hard refresh of the page? CTRL-Shift-R

I just checked, still an issue even after hard refresh. Also happening in Safari. Some people's edits with the tool do seem to be going through, though, so it's somehow an intermittent issue.

I'm not sure what's changed, but it seems to be working again now?

I'm going to optimistically close this but please reopen if it still needs investigation.

Tagooty subscribed.

QIvoter has not been working for me for the past week or so. I can select an image and vote. It shows the count next to "Confirm". When I click "Confirm", nothing happens.

@Tagooty Sorry, this task was highlighting specific breakage as a result of T314318. That change has been deployed for quite some time now so I'm going assume any new breakage is unrelated.

There does seem to be some chatter on the talk page about the confirm button not working,

Taking a quick look at the code, getSectionId pulls the section ID out of the mw-editsection. On Commons:Quality_images_candidates/candidate_list, that may look like 1 but on Commons:Quality_images_candidates, the gallery is coming from a template and so that can look like T-1.

The section is used to index into the votes array in onChangeVote. But, in _addVotes, the array is iterated with $.each(votes, .... The non-numerical keys seem to be omitted on the Array type, at least in Chrome at the moment.

I wonder if changing,

var votes = [];


var votes = {};

would help.

I made this edit but it didn't make any difference,

And reading the talk page, it does say the following, so I'm not sure why I expected that to work,

I just tried clicking on "confirm" at Commons:Quality images candidates and it works. But same at Commons:Quality images candidates/candidate list and it does not work.

Another issue with the gadget is,

$(".gallerybox").each(function() {
    $cmb = $(COMBO_REVIEW).val("");
    section = getSectionId(this);
    $cmb.on("change", function() {
        _onChangeVote(this, section);

section isn't properly scoped such that all the _onChangeVote are going to call with the same value.

Alas, that doesn't seem to matter because, in getSectionContent, it should be rvsection not section, and in editSection we see,

//section: sectionNumber, // Future support of section edition

Also noting that in _addVotes, the subtraction getSectionContent(sectionNumber - 1) isn't going to work with a section number T-1 noted in T341736#9241171.

And getSectionId should maybe be changed from,

var url = $(element).parent().parent().parent().find("h2 span a:last").attr("href");


var url = $(element).parent().prev().find("h2 span a:last").attr("href");

Taking a fresh look today, I noticed,

File:Buildings_on_Darwin_Street_in_Kharkiv.jpg|{{/Nomination|Darwin Street in Kharkiv. --[[User:Lystopad|Lystopad]] 15:41, 12 October 2023 (UTC)|}}

File:Weidelsberg.jpg|{{/Nomination|[[:de:Weidelsberg|Weidelsberg]] mit [[:de:Weidelsburg|Weidelsburg]] von Westen--[[User:Milseburg|Milseburg]] 14:58, 12 October 2023 (UTC)|}}

Mont de Chemun Sasplat.jpg|{{/Nomination|Wayside Crucifix --[[User:Moroder|Moroder]] 13:23, 12 October 2023 (UTC)|}}

In the first case, the name is underscore normalized and namespace prefixed. The last one, however, is not.

In the code, _getImageName pulls the name from href,

<a href="/wiki/File:Mont_de_Chemun_Sasplat.jpg" class="mw-file-description" title="* Nomination: Wayside Crucifix --Moroder 13:23, 12 October 2023 (UTC) * * Review needed">...</a>

which is going to yield, Mont_de_Chemun_Sasplat.jpg.

When _addVote is called, it's going to do,

var reg = escapeRegExp(vote.image) + "(.*)\\n";
var nomination = content.match(new RegExp(reg, "g"))[0];

where vote.image is the normalized form from the href but content is the original source, which contains the unnormalized form, so it isn't going to find it.

Thanks so much for working on this @Arlolra ! Let's see how this goes. :-) If the different filename formats do continue to cause problems, I could probably update the code for QICbot to correct them on a daily basis, if that might be useful.