• Bug 64975 has been marked as a duplicate of this bug. ***

I wonder if it actually should… The current behavior depends on user preferences, because preferences is what matter here.

Use the data for the current request instead could lead to surprising behavior, e.g. when the user tries to submit the form with &useskin= and gadgets unavailable for the current skin (not present in the form shown) get disabled.

Hi is this still a problem or has it been fixed.

The provided steps still allows reproducing the bug.

Reframing this in a way that focusses on the problem rather than a solution:

A user should be able to easily understand when they are enabling a gadget that it will not work in their current skin. Eg. by not showing the choice at all, or by disabling it with an explanation why, or by otherwise explaining and softly discouraging enabling gadgets that would not be applied.

My own thoughts:

I think user preferences should always present all preference data that exists for your account. Hiding some preferences based on the current skin would imho be undesirable and problematic long-term for transparancy and understanding. But, I do fully agree that we need to improve this. The least we could do is perhaps to show which skins a gadget is compatible with. The data for this is already in the registry, and already shown on Special:Gadgets, but we dont' show it on the preferences page currently. Whether to also discourage or tone down those entries in some way is a product decision I won't comment on.

Change 500206 had a related patch set uploaded (by Krinkle; author: Majr):

[mediawiki/extensions/Gadgets@master] Show all gadgets with required skins on preferences, with skin names

https://gerrit.wikimedia.org/r/500206

Users should be able to see all gadget preferences, irrespective of wich skin being used when visiting the preferences page.

On mobile it's hard for users to even find the gadget preferences T308651. Probably, most users visit the preferences page while in desktop view, e.g. Vector skin, and think they see all gadget preferences available.

As the ResourceLoaders targets system is to be dismantled T127268, I guess the use of "|skins="-settings should increase in gadgets-definitions. However, the effect of hiding gadgets from the users' preferences page may prove to be discouraging for that transition.

Then we have the reset button: "Restore all default preferences (in all sections)"
You need to see all preferences, and their default settings, to know what it means to press that button. See T51501, T70689

I think the UX of enabling an option and having it not work is worse than being unable to find the preferences page in some cases.

The former leads to wikis being in a poorer shape until/less someone with the right knowledge and permissions discovers the issue, and then works around it with improvised and likely-inconsistent description hacks, which then have to be kept in sync by hand.

The latter is a bug in MobileFrontend that can and should be fixed separately. Please find or create an issue for that. That'd be great!

Note that the notion of preferences being shown only when relevant is already widely adopted elsewhere in MediaWiki skins and extensions. There is value in Gadgets following the same model as elsewhere. Changing this is a possibility, but should be discussed more widely so as to not dimish the greater good of consistency and coherence of the platform. For example, we could explore greying out unavailable options, or showing in some standardised design what their scope is.

This task is about an edge case in which preferences are not yet consistently filtered. It isn't about reverting the logic that is already there.

OK. In MobileFrontend, AMC users now have a link to Special:Preferences, after T311720 was merged. T327506 addresses the need to remove the AMC restriction. Until that is resolved, I made a default gadget on svwiki, to make user preferences available for all mobile users. As the intended logic of the gadget preferences page is not that obvious to a new user, I have also added some info there, especially concerning preferences for the mobile view.