Page MenuHomePhabricator

In Beta Commons, Cat-a-lot preferences dialog doesn't work.
Open, Needs TriagePublicBUG REPORT

Assigned To
Authored By
Zache
Mar 22 2025, 11:44 AM
Referenced Files
F59055400: screen-capture.webm
Apr 13 2025, 2:20 PM
F58914887: screen-capture (5).webm
Mar 25 2025, 10:07 AM
Restricted File
Mar 24 2025, 6:57 PM
F58895144: screen-capture (2).webm
Mar 22 2025, 5:49 PM

Description

In Beta Commons, Cat-a-lot Settings doesn't work. It is broken both when the code is executed as a gadget and when it is executed as a user script.

What happens

  1. Enable Cat-a-lot from preferences OR special:mypage/common.js
  2. Goto category page
  3. Open Cat-a-lot UI from right-bottom corner
  4. Click Cat-a-lot Preferences link in right-bottom corner
  5. Nothing happens

What should have happened instead?:

  1. Settings dialog should be opening.

What should be done

Step 1

  • Debug why Settings doesn't work and document reason as a comment to the ticket. It doesn't throw an error to the javascript console so it needs to be checked from and using the code why button doesn't work.

Step 2

  • Fix the problem when Cat-a-lot has been loaded as user script.

Cat-a-lot should be able to

  • to open preferences dialog
  • to save settings temporarily
  • to save settings permanently to user page

You can check how the Preferences dialog is supposed to work by trying out how Cat-a-lot works on commons.wikimedia.org.

Event Timeline

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

Hi everyone,

I've already started looking into this issue and have begun debugging the problem with Gadget-SettingsManager.js and Gadget-SettingsUI.js. I'll continue investigating, but if anyone else wants to collaborate, I'd be happy to work together and share my findings. Feel free to jump in!

Looking forward to working together on this!

Hey, I just noticed that this task isn't listed as a microtask on the main Outreachy 30 task (T387982). I think adding it there would make it easier for other applicants to find it.

Hi, here’s a quick update on the Cat-a-lot Settings issue in Beta Commons:

Root Cause: The preferences button wasn’t working because the required dependencies SettingsManager.js and SettingsUI.js were not available on Beta Commons.

Fix Implemented: I loaded the dependencies from my user namespace Special:Mypage/Gadget-SettingsManager.js and Special:Mypage/Gadget-SettingsUI.js. Initially, I tried to use mw.loader but that didn't work so I resorted to using $.getScript. This resolved the issue, and the settings dialog now opens when the preferences button is clicked.

Next Steps: Currently, the settings dialog opens, but the settings are not being applied. I’m working on ensuring the settings are saved and applied correctly.

Let me know if you have any feedback!

Hi @Zache ,

I’ve been working on fixing the Cat-a-lot settings functionality in Beta Commons, and I wanted to share my progress so far. Here’s what I’ve done and the current status:

  • Modified manageSettings to save preferences to the user’s common.js. It works but is unstable—requires 2 attempts to save successfully.
  • Still investigating why temporary (session-only) settings aren’t applying. Need to trace where the values are being dropped. (I think it might be related to how preferences are cached?)

Could you help me troubleshoot:

  • Why permanent settings only work after two attempts?
  • Where to look for the breakage in temporary settings?

I’ll keep testing and refining, but any pointers would be greatly appreciated!

For reference:
diff
common.js (saving permanent settings)
{F58911254}

Hi @Zache ,
I'm happy to share that the Cat-a-lot settings functionality is now working correctly on Beta Commons!
Changes Made

  1. The original code relied on mw.loader.using to load dependencies but did not handle cases where these dependencies were missing (e.g., when loaded as a user script). I added a fallback mechanism to dynamically load the required scripts (SettingsManager.js and SettingsUI.js) from the wiki if they aren’t available via mw.loader and used $.getScript to fetch and inject these scripts directly when the gadget loader fails.
  2. Split the logic into two parts:
    • Dependency Loading: Handled in manageSettings with fallbacks.
    • Dialog Creation and Settings Handling: Deferred to _manageSettings only after confirming dependencies are loaded.

I think we can include these changes in the beta commons development guide documentation but please let me know if you’d like to discuss any further improvements!

For reference:
diff

@adiba_anjum .Just FYI that I noticed when you did this. I just didn't have time to do anything about this, but this was good debugging information and well done. The way we should proceed is to check how code should be updated when Cat-a-lot is loaded somewhere other than Wikimedia Commons. For example, it is known that Cat-a-lot is used in different wikis (enwiki example) and users are loading it through their user/common.js similarly to what we are doing.

Currently preferences arent supported in other wikis than Wikimedia commons. In and it would be possible to fix this.

Currently in Help:Cat-a-lot that preferences wont work is said like this:

The semi-automatic preferences are not loaded with this example, so you need to set this manually as well (because it supports only Commons, although it is theoretically possible, if you load all the local needed extra modules).

Hey, I've been working on fixing the Cat-a-lot preferences dialog for other wikis especially Wikipedia, but haven't been able to get it fully functional yet. Here's a summary of what I've tried:

  1. Loading Dependencies from Commons
    • Attempted to load SettingsManager.js and SettingsUI.js directly from Commons
    • Scripts load successfully, and mw.libs.SettingsUI initializes, but the dialog's show() method hangs indefinitely
  1. Alternative Loading Approaches
    • Tried loading dependencies from my user space (User:Adiba_anjum3/) - (same behavior)
    • Added Commons CSS to ensure proper styling
    • Tested with different jQuery UI versions (both local and Commons versions - no change)
    • Added manual dialog creation (works, but loses settings functionality)
  1. Debugging & Fallbacks
    • Added extensive console logging - dialog creation works but display fails silently
    • Implemented timeout fallbacks and a simplified settings dialog as backup
    • Verified no JavaScript errors occur during execution
  1. Key Observations
    • The preferences system appears tightly coupled to Commons' infrastructure.
    • Cross-wiki loading works for scripts but not for functionality (likely due to missing backend support).
    • No core files (Gadget-libAPI.js, SettingsManager.js, SettingsUI.js) exist in Wikipedia's MediaWiki: namespace

As a suggested Path Forward would it be feasible to: Register the gadget dependencies (SettingsManager, SettingsUI) on Wikipedia's MediaWiki: namespace to test if native loading resolves the issues?

current diff for the code that works well on both commons and beta commons - It's messy but I'll clean it out for the final working iteration.

As a suggested Path Forward would it be feasible to: Register the gadget dependencies (SettingsManager, SettingsUI) on Wikipedia's MediaWiki: namespace to test if native loading resolves the issues?

I don’t think so, for two reasons:

  • Since Cat-a-lot is not an official gadget on English Wikipedia, adding its dependencies officially (in the MediaWiki: namespace) would probably not be welcomed (and thus not done) by enwiki interface administrators.
  • It would probably end in a lot of copying and pasting, which is a maintenance nightmare.

Instead, the loading issues should be fixed without touching anything on enwiki. I’ve debugged it, and both problems lie in the method SUI.show():

  • It tries to load the ResourceLoader module ext.gadget.libJQuery, which exists on Commons and Beta Commons, but doesn’t exist on English Wikipedia (this link points to a non-existing anchor), which is why the dialog doesn’t appear.
  • And it doesn’t handle eventual errors, making them silently be suppressed, which is why you got no clue what went wrong.

For the latter, the straightforward solution is adding error handling:

	show: function() {
		var sui = this,
			$progress = new $.Deferred();
			
		mw.loader.using([
			'jquery.ui', // deprecated
			'mediawiki.user',
			'ext.gadget.libJQuery'
		]).then(
			()  => sui._show($progress),
			err => $progress.reject(err)
		);
		return $progress;
	},

For the former, the answer is not that obvious:

  • We could load it conditionally either as a ResourceLoader module (ext.gadget.libJQuery) or by URL (https://commons.wikimedia.org/w/load.php?modules=ext.gadget.libJQuery), but this would add complexity;
  • We could always load it by URL, but in that case, styles and scripts should be loaded separately (https://commons.wikimedia.org/w/load.php?modules=ext.gadget.libJQuery&only=styles and https://commons.wikimedia.org/w/load.php?modules=ext.gadget.libJQuery&only=scripts) because the common URL errors out if the given ResourceLoader module is already known to mw.loader;
  • Or we could just not use it. As far as I see, all we need it for is two tiny icons on the settings panel (the icons of the save and cancel buttons), are they worth the effort? If Cat-a-lot gets migrated to Codex (T389737), the icons will go away anyway.

I also noticed that the error handling you added causes the message Could not load settings. Please ensure all required scripts are available. to appear if I click the cancel button on the settings dialog, both locally (once I make the dialog appear) and on Beta Commons, so the current solution should definitely not stay. (It’s perfectly fine to have it while debugging, though – you know what you meant when you wrote the code, and nobody else needs to understand your debugging version.)

Thank you for the detailed analysis. I completely agree with your findings, and I'd like to share some observations that I made after my last comment on this task:

  1. SUI.show() Behavior:
    • Confirmed the ext.gadget.libJQuery dependency is the root cause
    • Your enhanced error handling successfully surfaces loading errors
    • Additional issues persist in _show() due to deeper dependency chains
  1. Alternative Approaches Tested:
    • Custom Dialog Implementation:
      • Successfully rendered the UI
      • Couldn't integrate with _manageSettings() due to gadget system dependencies
    • Manual Dependency Loading:
      • Caused version conflicts with Wikipedia's jQuery UI

Next Steps

Per your recommendations, I will:

  1. Test conditional loading of the libJQuery dependency.
  2. Verify separate loading of styles and scripts to prevent conflicts
  3. Conduct a full audit of _show() to identify any remaining unhandled errors

I'll share the results of these tests once complete. Your insight about the eventual Codex migration is particularly helpful for understanding the long-term solution.
Thank you again for your guidance. I'll follow up with my findings after completing these additional tests.

Hey, after testing several approaches,I'm happy to tell you that the Cat-a-lot preferences dialog on en.wikipedia finally works. Here's what worked:

Key Issues Solved:

  1. Missing libJQuery: Loaded styles/scripts separately from Commons with fallbacks
  2. Silent Failures: Added proper error handling for dialog initialization
  3. Fixed permanent saves by: Ensuring proper location: 'public' parameter

Current Status:

  • Dialog opens reliably
  • All save modes work (temporary/permanent)
  • Works cross-wiki without local dependencies

The solution keeps Commons compatibility while working on en.wikipedia but please let me know if you’d like to discuss any further improvements!
Thanks for your guidance!

References:
User:Adiba anjum3/Preferences-Gadget-Cat-a-lot.js

This is my take on the error based on your findings and on the code in T395770#10891993.

I tried to modify only the module loading in manageSettings() and keep other places as is. So now this works like this:

1.) mw.loader.using() tries to load required modules. If it succeeds then it will call CAL._manageSettings() which was the original behaviour. If it fails, it will call loadModulesFromCommons() as a fallback.

mw.loader.using( modules, CAL._manageSettings, loadModulesFromCommons);

2.) If the user is not in Wikimedia Commons, then loadModulesFromCommons() loads modules using mw.loader.load(). The load() function is used as it can be used for loading and registering modules. This means that next time when settings are clicked the mw.loader.using() works. The negative side is that load() doesn't have callback interfaces, so we need to simulate it by using setTimeout().

mw.loader.load(
    'https://commons.wikimedia.org/w/load.php?modules=' + modules.join('|') + '&lang=en',
);

3.) setTimeout() checks multiple times if the modules are successfully loaded. If they are, it will call CAL._manageSettings(). If not, then it will show an alert dialog.

// Poll for module availability 
const checkModules = (attempts = 0) => {
    if (attempts > 50) { // Max 2.5 seconds
       alert('Error on loading external modules required by settings');
       return;
    }
                
   if (modules.every(module => mw.loader.getState(module) === 'ready')) {
      CAL._manageSettings();
   } else {
      setTimeout(() => checkModules(attempts + 1), 50);
   }
}

I made updated version about the loading. Instead using mw.loader.load() and then polling when it is read I made it so that it will add Wikimedia Commons as module source and then register the modules.

As simplified version

const modules = [
   'ext.gadget.SettingsManager',
   'ext.gadget.SettingsUI',
   'ext.gadget.libJQuery',
];

// Check if any modules need registration
const needsRegistration = modules.some(module => !mw.loader.moduleRegistry[module]);

if (needsRegistration) {
   // Add Wikimedia Commons as source
   mw.loader.addSource({'commonswiki': 'https://commons.wikimedia.org/w/load.php'});

   // Register modules 
   mw.loader.register('ext.gadget.libJQuery', version, [], null, 'commonswiki');
   mw.loader.register('ext.gadget.SettingsUI', version, ['jquery.ui', 'mediawiki.user', 'ext.gadget.libJQuery'], null, 'commonswiki');
   mw.loader.register('ext.gadget.SettingsManager', version, ['mediawiki.user', 'user.options', 'mediawiki.api', 'mediawiki.util'], null, 'commonswiki');
}

// Load and execute once all modules are ready
mw.loader.using(modules, CAL._manageSettings, function (err) {
   console.error('Failed to load settings modules:', err);
});