Page MenuHomePhabricator

User scripts/gadgets can load WikiLove wiki module without Wikilove dependencies
Closed, DeclinedPublic

Description

WikiLove allows editors to make modifications inside a page called MediaWiki:WikiLove.js, however this module doesn't depend on anything meaning its quite common in race conditions for there to be errors in seemingly harmless scripts like https://hu.wikipedia.org/w/index.php?title=MediaWiki:WikiLove.js to occur.

In fact it seems that any module declared using a ResourceLoaderWikiModule cannot have dependencies in its definition.

We probably want to adjust ResourceLoaderWikiModule class in core to allow dependencies. Once that's done fixing should be trivial.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

Change 638126 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/extensions/WikiLove@master] Declare dependencies on ext.wikiLove.local

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

Actually I can’t imagine how this error can occur—ext.wikiLove.local is referenced only from rEWLO resources/ext.wikiLove.init.js, which does depend on ext.wikiLove.startup, so by the time the local module is requested, startup should be ready. (Of course, explicit dependency is a better solution for sure anyways, just wondering how this error could manifest here to begin with.) Do we have a stack trace that could probably help understanding what’s going on?

By the way, adding this dependency was attempted in 96618901c335 back in 2014, but led to T71356.

Stack trace on error is empty which is understandable as this code if run without dependencies runs at the top level, but it does suggest that a user script is either calling mw.loader.using('ext.wikiLove.local') or a gadget is declaring the module as a dependency without ext.wikiLove.startup.

The error also occurs on sv.wikipedia.org but again no clues other than a gadget or user script is loading it incorrectly: https://logstash.wikimedia.org/app/kibana#/doc/logstash-*/logstash-2020.10.27/clienterror/?id=AXVp8wQ7LNRtRo5Xg4UU

Jdlrobson renamed this task from WikiLove wiki modules don't have dependencies available to User scripts/gadgets can load WikiLove wiki module without Wikilove dependencies.Nov 2 2020, 9:22 PM

Change 638126 abandoned by Jdlrobson:
[mediawiki/extensions/WikiLove@master] Declare dependencies on ext.wikiLove.local

Reason:
not working on this

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

Umherirrender added subscribers: Krinkle, Umherirrender.

Other wiki page modules like Common.js also does not allow to declare dependency, that must be done with mw.loader.using on the wiki page to working correctly.

There is no way for the server to know what dependency is needed here. I see no way how to fix this task.

Krinkle claimed this task.

Indeed. unless users are reporting that WikiLove customisations have been broken for years this works as expected.

If a user manually loaded something from their console to debug a problem and accidentaly caused some errors or something, or loads this by other means manually, that's not a bug in the software. Entering foobar() in the console also ends up logging an error we can't do much about, and it appears that is effectively what happened here. Assuming the rate isn't high and it works correctly when the software is used normally, nothing for us to do.

It is by design that the WikiModule class supports not dependencies since it allows loading of arbitrary wiki pages of which we don't control the content. We can't really know what it might depend on. If such extension points are allowed to be asynchronous, then the custom code itself can and must take care of its own dependencies (e.g. with "using" calls). In the case of WikiLove, the extension point can't be asynchronous and must make an assignment it seems, in which case it can only use confguration assignments it seems, which needs to just happen and there can't be arbitrary dependencies. The object that the user may extend is already defined by that point, and the extension is in charge of loading it in the right order, which it does already.

Krinkle changed the task status from Resolved to Declined.Apr 15 2021, 9:22 PM
Krinkle removed Krinkle as the assignee of this task.