Problem: Some templates depend on JavaScript gadgets: enhanced search fields, flyout menus, and so on. Currently, if an interface administrator wants to get the gadget loaded on pages that use this template, the only option is to run a small amount of JavaScript (determining whether the full gadget should be loaded) on each and every page load, for everyone. Maybe the template is used only on one or two pages out of the tens or hundreds of thousands of pages on the wiki, yet all page loads are slowed down by it.
Who would benefit: Readers by not having unnecessary JavaScript slowing page loads, interface admins (and even other tech-savvy users without IA right) having more straightforward way of controlling gadget loading.
Proposed solution: Have a parser tag similar to TemplateStyles that includes a ResourceLoader module indicated in its argument.
More comments: Care should be taken in order not to allow arbitrary code to be loaded by untrusted users (the parser tag in wikitext can be added and edited even by anonymous users). While the contents of ResourceLoader modules can be changed by only select people, probably the safest solution is to create a “namespace” (e.g. ext.gadget.includeable.*) for this purpose within gadgets, and disallow loading any other RL module. Disallowed modules can be loaded by making them dependencies of allowed gadgets. (Dependency is safe, as gadget dependencies can be edited only by trusted interface admins.)
@TheDJ: Do you mean a gadget that decides on client side whether it should load other gadgets? This is exactly the small amount of JavaScript I mentioned and that I’d like to eliminate. (To be exact, I meant whatever way that small amount of JS is run: one default gadget, many default gadgets, Common.js etc.) This may be a small amount per gadget, but it’s not zero, and especially on Wikibooks and Wiktionaries can be many different such gadgets. —Tacsipacsi (talk) 23:51, 26 November 2020 (UTC)[reply]
Comment I think as proposed this would make security and performance very difficult to uphold. However the idea of allowing a gadget to be enabled "by default" but limited to a subset of pages makes sense. We already support narrowing the default by skin, platform, and user rights. We could for example add support for limiting to categories. Then to initiate it from a template one would add the article to a (hidden) category. This would place the security control with the gadget configuration (the gadget definition specifies its categories, the page does not directly require a gadget), and would also encourage more re-usable logic with less effort (e.g. many articles and templates already have existing categories that you can make use of). It also means gadgets can be merged, split or renamed without their loading breaking as there would not be a direct connection between the two. Perhaps the proposal could be edited to focus more focussed on the problem and use case, and leave the implementation details to be decided by developers and other stakeholders if/when it is worked on. --Krinkle (talk) 20:30, 11 December 2020 (UTC)[reply]
Adding a ResourceLoader module from a parser function doesn't seem problematic to me performance-wise; a number of parser hooks already do that. In terms of security, the only issue I can think of is that it must not allowed to work on "safe" pages like login (via a system message; probably it shouldn't work in system messages at all).
Categories would be nice for tracking where a script is used, but we could also just (ab)use the templatelinks table like we do for TemplateStyles. Tgr (talk) 08:51, 13 December 2020 (UTC)[reply]
@Krinkle: If we were to use categories to decide whether or not to load a gadget, renaming gadgets would be easier, but renaming categories would be more difficult—and the consequences are far less obvious, fixing a typo in a category name would stop the gadget from working for no apparent reason. Furthermore, if one renames a category, they probably won’t be able to adjust the gadget configuration afterwards (as they’re not necessarily an interface admin). Also, gadget naming is an internal detail completely transparent for users, while category names are user-visible, so they’re much more likely needed to be changed. I think gadget renaming is already mostly impossible, as there’s no other permanent identifier for gadgets, so renaming a gadget would likely revert it back to its initial state for everyone (i.e. turn it on in case of default gadget, turn it off otherwise). I see your concerns (although I agree with Tgr in that they’re unlikely to be actual issues), but the point of easing renames is simply false IMO. Split and merger is probably really more convenient with the category-based system, but it still doesn’t outweigh the renaming issues. Also, I don’t like polluting the categories with such technicalities.
Security-wise: what issue do you think would appear that isn’t handled by the proposed tag-based system, but would be handled by your category-based one? IAs are already in control of what could be possibly loaded (with the namespace system), while what’s actually loaded can be controlled by anyone anyway (through adding either the parser tag or the category).
@Tgr: Entirely disabling it in messages could be the way to go, but Common.js is also disabled in these contexts, so there should be a way in MW core to determine whether risky RL modules can be loaded. (There are some MediaWiki messages like s:MediaWiki:proofreadpage_index_template that are practically templates stored in the MediaWiki namespace, and may benefit from this feature. I don’t know if these can be programmatically distinguished from the cookie prompt on the login page, which should certainly not have anything like this.) —Tacsipacsi (talk) 21:43, 14 December 2020 (UTC)[reply]
I think it would be better to implement phab:T204201.
That has much broader capabilities and gives more benefit at various circumstances.
The common approach is to look for elements with certain classes after DOM has been loaded, then proceed. If that could be narrowed to a particular namespace it would save a lot of client execution time already.
Using a category, even a hidden maintenance category, might distract attention of editors. Equipping some elements with a class is very silent.
However, the improvements suggested in phab:T204201 may introduce more Cirrus filters like incategory and hastemplate (actually: transcludes). They should use underscore page titles and leave spaces as separators.
The target is to reduce the amount of gadgets to be loaded in a page but could never be useful under predictable and easily detectable conditions.
I don’t think it is promising to introduce new Wikisyntax, new elements, new parser functions for making page contents triggering gadget execution. There are page properties and various criteria in T204201 which will deliver the same result but with less efforts and wider applicability. --PerfektesChaos (talk) 14:21, 18 March 2021 (UTC)[reply]
Support This proposal combines the utility of having page scripts with the security and caution of eliminating overhead for irrelevant pages. Vanisaac (talk) 01:53, 16 December 2020 (UTC)[reply]
Support Regardless of the pros and cons of implementation methods, this seems like a good idea suffering from bikeshedding neglect. Faster page loads are good, wasting bandwidth is wasting resources. This page load 14 scripts. HLHJ (talk) 00:23, 20 December 2020 (UTC)[reply]
Comment I think as proposed this would make security and performance very difficult to uphold. However the idea of allowing a gadget to be enabled "by default" but limited to a subset of pages makes sense. We already support narrowing the default by skin, platform, and user rights. We could for example add support for limiting to categories. Then to initiate it from a template one would add the article to a (hidden) category. This would place the security control with the gadget configuration (the gadget definition specifies its categories, the page does not directly require a gadget), and would also encourage more re-usable logic with less effort (e.g. many articles and templates already have existing categories that you can make use of). It also means gadgets can be merged, split or renamed without their loading breaking as there would not be a direct connection between the two. Perhaps the proposal could be edited to focus more focussed on the problem and use case, and leave the implementation details to be decided by developers and other stakeholders if/when it is worked on. --Krinkle (talk) 20:30, 11 December 2020 (UTC)
Support Would be useful to have DannyS712 (talk) 18:02, 8 December 2020 (UTC)