Page MenuHomePhabricator

View::addModules() tries to add missing module `ext.flow.mediawiki.ui.text`
Closed, ResolvedPublic

Description

In View::addModules()[1] if the current action has no custom module styles it wants loaded, Flow will default to a list of modules to load, including the ext.flow.mediawiki.ui.text module.

However, the ext.flow.mediawiki.ui.text module was removed in rEFLW326905e4420c: Use '.text-overflow()' mixin from 'mediawiki.mixins' by @Volker_E , writing

Use '.text-overflow()' mixin from 'mediawiki.mixins'
And remove Flow's own mixin and related module, which hasn't been in use any more.

Either the calling code should be updated to stop trying to load it, or the module should be restored - I assume since there have been no complaints about missing styles that it doesn't need to be restored?

Also, why is there error reported for this? ResourceLoaderClientHtml just silently ignores trying to add modules that don't exist.

[1] https://gerrit.wikimedia.org/g/mediawiki/extensions/Flow/+/99f1b623ff350e0a995d2dedd0c42c768902fbdb/includes/View.php#124

Event Timeline

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

(Tagged MediaWiki-ResourceLoader regarding the issue of (not) logging reports of missing modules)

Non-existent modules are generally reported client-side in the browser console.

The server-side ClientHtml class doesn't require modules to exist. That's by design to accomodate ParserCache. When a given module name is removed (e.g. after a deprecation or merging into another module) developers are free to remove that module from the registr if its styles or scripts are no longer needed. For example, if they were moved into a different module that is already added to the same pages and propagated through ParserCache. There has to be a point somewhere where we remove the module, and at which point cached references are not considered an error. We could say that for WMF, we require developers to do this in two patches and wait a month before the second step to avoid a server-side warning. This would make developer experience worse, and doesn't help anyone. But, for third-party upgrades the issue would still hapen as the development delays are skipped over there in one go,

Historically it may also have been this way to accomdate late registration from an exension hook and to suppot foreign module sources, but, those are registered upfront nowadays with service wiring.

Instead, we generally handle this on the client-side instead, which also makes it more visible for the front-end developers that work on this code. When a module, or one of its dependencies, is not found in the registry, a warning is logged to the console. The browser doesn't have a way to emit console warnigns from a CSS response, however, so for style modules these currently end up silently ignored. There's a couple ways we could handle that, I've created task T292274 to look at that more.

Tgr triaged this task as Low priority.

Change 725398 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/Flow@master] Remove reference to deleted mediawiki.ui.text RL module

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

Change 725398 merged by jenkins-bot:

[mediawiki/extensions/Flow@master] Remove reference to deleted mediawiki.ui.text RL module

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