Page MenuHomePhabricator

Cat-a-lot gadget gets stuck if a page is protected
Closed, ResolvedPublicBUG REPORT

Description

If one of the selected images includes a protected page that the user can't edit, the API returns an error and the in-progress dialog stays open forever.

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

What happens?:

  • API returns error, which is handled incorrectly (program doesn't crash but it fails to continue)
  • in-progress dialog stays open forever

What should have happened instead?:

  • There should have been notification for the error with possibility to ignore it and continue editing

TODO:
Investigate where the editing request error handling occurs:

Based on findings:

If error handling is in Cat-a-lot.js:

  • Add proper error handling code to display a dialog with options to ignore the error or cancel editing

If error handling is in Gadget-libAPI.js and it doesn't return to Cat-a-lot.js:

  • Document the code behavior in the ticket

Event Timeline

Zache updated the task description. (Show Details)
Zache updated the task description. (Show Details)

@Zache Hello, I am Chandrakant and I tried to replicate the issue. I selected a category, then selected a file, and removed the category. It showed as successful. However, I couldn't find a protected file within the category since there is no sign or lock symbol indicating protection. Additionally, there is no sorting preference to filter protected files.

Could you help me understand how to find a protected file within a category? Or do I have to manually open each file one by one to check if it's protected?

Screenshot (100).png (1×1 px, 514 KB)

@ichandrasharma It seems that it was little bit too easy to edit unprotected icons in LiveRC Toolbar extension icons category so I made specific categories for Cat-a-lot test images.

I also added some information about suitable test images to the documentation page:

Hi, @RJ2904 I will remove you from "assigned to" as I will plan to submit Cat-a-lot project under Outreachy as there is no WMF GSoC in 2025. I will think something else for GSoC.

Zache removed RJ2904 as the assignee of this task.Mar 5 2025, 11:44 AM
Zache added a subscriber: RJ2904.

I’ve started working on this ticket!
I’m currently looking into replicating the issue. If anyone has suggestions or relevant insights, feel free to share I’m open to collaboration. I’ll provide updates as I make progress.

@Zache

i have successfully confirmed and replicate the bug by following the procedure in the task.

RESULTS

I got stuck on "Editing page X of Y"

Here is a screenshot:

Screenshot 2025-03-20 at 16.01.51.png (1×2 px, 378 KB)

Test Environment

  • Operating System: macOS 12.7.6
  • Browsers Used:
  • Chrome - Version 134.0.6998.89

What next?
Checking both MediaWiki:Gadget-libAPI.js and MediaWiki:Gadget-Cat-a-lot.js to see where the editing request error handling occurs.

Looking forward to any suggestions or feedback from you.

Hi,

I would proceed like this:

  1. Check if there are errors in the JavaScript console when performing the edit (spoiler: there are none).
  2. Check the browser's network response when performing the edit (spoiler: the HTTP response status is 200 OK, but the response content contains the message protectedpage error).
  3. Since this is an unhandled error that should visibly indicate a failure, I would investigate where the API call is made and why error handling is missing.
  4. I would start tracing the code from MediaWiki:Gadget-Cat-a-lot.js—specifically the addCategory() function—to identify the point where the actual API call to MediaWiki:Gadget-libAPI.js occurs. I would then add appropriate error handling there.

One useful thing, but not so easy to figure out is that the parameters used in editpage() within MediaWiki:Gadget-libAPI.js are listed here.

Got it! Thank you for the feedback.
I fixed the unhandled error and notification for the error with possibility to ignore it and continue editing.

Hi,

I would proceed like this:

  1. Check if there are errors in the JavaScript console when performing the edit (spoiler: there are none).
  2. Check the browser's network response when performing the edit (spoiler: the HTTP response status is 200 OK, but the response content contains the message protectedpage error).
  3. Since this is an unhandled error that should visibly indicate a failure, I would investigate where the API call is made and why error handling is missing.
  4. I would start tracing the code from MediaWiki:Gadget-Cat-a-lot.js—specifically the addCategory() function—to identify the point where the actual API call to MediaWiki:Gadget-libAPI.js occurs. I would then add appropriate error handling there.

One useful thing, but not so easy to figure out is that the parameters used in editpage() within MediaWiki:Gadget-libAPI.js are listed here.

@Zache

The error handling is in Cat-a-lot.js but not unhandled properly, i fix this issue in the doAPICall( ) that makes the actual API call through mw.libs.commons.api.editPage

Changes Implemented for Error Handling Enhancement:

  • Added error callback parameter which is misssing editPageParams variable.
  • Visual dialog showing file-specific errors and technical details in editCategories().
  • User options to "Ignore and continue" or "Stop all editing".
  • Modal design for clear focus during failures.
  • Introduced 4 new i18n messages for error titles/actions.

This enhancement provides:

  1. Visual error notifications
  2. User control over error handling
  3. Ability to continue or stop operations
  4. Styled error dialog for better UX

Screenshot :

Screenshot 2025-03-22 at 16.25.47.png (1×2 px, 446 KB)

Link to my edit :
https://commons.wikimedia.org/wiki/User:Ademola01/cat-a-lot.js

I would appreciate a review and any feedback on these changes, as well as guidance on the proper submission process.

Hi @Ademola, just checking the code. It works, but some design notes.

Place of the code
I would move the error dialog code from inline to a separate function and I would move the styles to the Cat-a-lot.css page. These changes would make the code more readable. (ie. dialog starting in line 1044 )

Dark mode support
As users can change between light and dark mode, fixed colors should be avoided and Codex color names should be used so colors will automatically change based on the theme. Codex definitions look like this in CSS (MediaWiki:Gadget-Cat-a-lot.css):

background-color: var(--background-color-interactive,#FEF6E7);
color: var(--color-base, #eaecf0);

The background-color-interactive is a Codex name and #FEF6E7 is a fallback color for skins which don't support Codex. A list of Codex color names can be found here: https://doc.wikimedia.org/codex/latest/design-tokens/color.html

You can toggle dark mode on/off from the menu that opens when clicking the 'eyeglasses icon'. This icon is located either in the top bar next to the username . (see screenshot) or, if the menu is already open, on the right side of the page

Updating the error counters
When an action fails, the older code (before libAPI) incremented the error counter. This adds the error information to the displayResult() function, which is shown at the end of the action. In older error handler updating the counters is done like this:

line 1277.

self.connectionError.push( params.title );
self.updateCounter();

@Zache
Thank you for the feedback!

Place of Code
I fixed that by moving the error dialog code into a separate function and shifting the styles to Cat-a-lot.css as suggested.
I replaced it with CAL.showErrorDialog(data.title, error); in Cat-a-lot.js

Dark Mode Support
I've updated the colors to use Codex color variables instead of fixed colors, so they now adjust automatically based on the theme.

Updating the error counters
I've updated it to ensure that the error information is now handled within showErrorDialog( )

CAL.connectionError.push(fileName);
CAL.updateCounter();

Let me know if there's anything else I should refine!

Hi, just to comment that I was not able to get dialog to work nicely with dark mode either. I.e., with your CSS the dialog was partially with light background. When I tuned the CSS, there was a less-than-ideal titlebar which was always looking crappy, and even though I got other parts changed to dark, it looked like pretty complex CSS styling, and there has to be a better way to do it. I just don't know what it is.

Based on that, I think that we could ignore the dark mode, use minimal CSS-styling and use defaults. My best solution, I think, was just to style the error message and leave the rest as defaults.

.cat-a-lot-error-dialog  .error-details {
    color: #f54739;
    border: 1px solid #f54739;
    padding: 10px;
    margin: 10px 0;
    border-radius: 4px;
}

As for other parts, I think that this could be ready to be proposed to production. Proposing changes to production works like this:

1.) make minimal diff
You would need to make a clean diff so that it is easy to review. I have used separate pages for this where I have included just those changes that I have needed so it will have a very simple diff. (example: js, css )

2.) Propose the edit in the talk page
Changes are proposed in the Mediawiki talk:Gadget-Cat-a-lot-js page. As there is existing discussion on bug gadget gets stuck if a page is protected you can continue it by adding edit request there.

I have used a message format which looks like this:

Edit request: Add error handler to Mediawiki:Gadget-Cat-a-lot.js
{{Edit request}}
I would have following changes to Mediawiki:Gadget-Cat-a-lot.js and Mediawiki:Gadget-Cat-a-lot.css. The changes will add error handler to edits done via libAPI so it will show a visible error dialog where user either ignore error or stop editing.

  • User:<username>/cat-a-lot-T386779.20250325.js (version 10:47, 25 March 2025)
  • User:<username>/cat-a-lot-T386779.20250325.css (version: 10:55, 25 March 2025)

As the change added new texts they need to be added to MediaWiki:Gadget-Cat-a-lot.js/translating

  • 'cat-a-lot-error-title': 'Error occurred while editing',
  • 'cat-a-lot-error': 'An error occurred while editing $1',
  • 'cat-a-lot-ignore-error': 'Ignore and continue',
  • 'cat-a-lot-stop-editing': 'Stop all editing',

How to test the change (there is info on howto replicate the bug on phab:T386779

  1. use regular (non-admin user)
  2. Open category Category:Cat-a-lot test images with protected file File:IOS Client upload testing image 607DD0EE-AF12-4BD4-AE74-12FA1896B124.jpg
  3. Open Cat-a-lot dialog from right-bottom-corner
  4. Click to select file protected file File:IOS Client upload testing image 607DD0EE-AF12-4BD4-AE74-12FA1896B124.jpg
  5. Remove the category Category:Cat-a-lot test images from protected file File:IOS Client upload testing image 607DD0EE-AF12-4BD4-AE74-12FA1896B124.jpg using Cat-a-lot
  6. Expected result: There is now visible error message

    --~~~~

Same as in wikicode

=== Edit request: Add error handler to Mediawiki:Gadget-Cat-a-lot.js  ===
{{Edit request}} <!-- This will flag the discussion so that the interface admins will see it -->

I would have following changes to Mediawiki:Gadget-Cat-a-lot.js and Mediawiki:Gadget-Cat-a-lot.css. The changes will add error handler to edits done via libAPI so it will show a visible error dialog where user either ignore error or stop editing. 

* [[User:<username>/cat-a-lot-T386779.20250325.js]] (version HH:MM, 25 March 2025)
* [[User:<username>/cat-a-lot-T386779.20250325.css]] (version: HH:MM, 25 March 2025)

As the change added new texts they need to be added to [[https://commons.wikimedia.org/wiki/MediaWiki:Gadget-Cat-a-lot.js/translating | MediaWiki:Gadget-Cat-a-lot.js/translating]]
*  'cat-a-lot-error-title': 'Error occurred while editing',
*  'cat-a-lot-error': 'An error occurred while editing $1',
*  'cat-a-lot-ignore-error': 'Ignore and continue',
*  'cat-a-lot-stop-editing': 'Stop all editing',

How to test the change (there is info on  howto replicate the bug on [[phab:T386779]]
# use regular (non-admin user)
# Open category [[:Category:Cat-a-lot test images]] with protected file [[:File:IOS Client upload testing image 607DD0EE-AF12-4BD4-AE74-12FA1896B124.jpg]]
# Open Cat-a-lot dialog from right-bottom-corner
# Click to select file protected file [[:File:IOS Client upload testing image 607DD0EE-AF12-4BD4-AE74-12FA1896B124.jpg]]
# Remove the category [[:Category:Cat-a-lot test images]] from protected file [[:File:IOS Client upload testing image 607DD0EE-AF12-4BD4-AE74-12FA1896B124.jpg]] using Cat-a-lot
# Expected result: There is now visible error message

--~~~~ <!-- user talk page signature in wikicode -->

There is older change proposals in the talk page as example

Noted
i will update the code base on your feedback

A fix has been proposed in subtask T390131. The issue has been addressed in my user page. Review and feedback are welcome!

merged to main version as part of T395770 fixes