Page MenuHomePhabricator

Load module 'mediawiki.action.view.postEdit' only when needed
Closed, ResolvedPublic8 Estimated Story Points


Currently the module 'mediawiki.action.view.postEdit' is loaded on every article views although the module is only needed once directly after an edit and the cookie is set.

Event Timeline

Change 351015 had a related patch set uploaded (by Fomafix; owner: Fomafix):
[mediawiki/core@master] Load module 'mediawiki.action.view.postEdit' only when needed

Change 351015 merged by jenkins-bot:
[mediawiki/core@master] Clear postEdit cookie on server-side

The module mediawiki.action.view.postEdit is still loaded on all page views:

> mw.loader.getState( 'mediawiki.action.view.postEdit' )

I don't know why.

The module mediawiki.action.view.postEdit is loaded by a dependency in other extensions used on the WMF projects.

Krinkle added a subscriber: Krinkle.

Re-opening. Following optimisation work on the mediawiki.notification module from f2e8cd6dbdfc4, it occurred to me the page I was reading did not produce any notifications. We always recommend using mw.notify() which lazy-loads the module on first use. The reason it was loaded is because:

  1. postEdit.js was changed to depend on mediawiki.notification directly (for its CSS styles) - f8ac9bb2e6a28c0
  2. VisualEditor's ext.visualEditor.desktopArticleTarget.init module was changed to depend on postEdit - 1e04640d02c9

Given postEdit was especially optimised to only be loaded where needed and yet (when loaded) not require further lazy-loading, it probably doesn't make sense to change postEdit.js. It loading mediawiki.notification at the same time is fine.

We should instead update VisualEditor to not require postEdit as part of its on-every-page-view "init init" module. It's only needed after saving an edit. Loading it as part of the earliest "init" module on every page is a bit too much. I'd recommend removing as dependency from the init-init code and instead loading it in one of the following two ways:

  1. Move to the list of modules batch loaded at edit-start time within This would delay editor startup, and actually not work for the second case listed below.
  2. A better optinon: Lazy-load where needed, as part of an existing batch where possible, in the two places it is used:
    • DesktopArticleTarget#saveComplete: Can be loaded as part of the mw.loader.load() batch for the page view. The mw.hook call will naturally be handled once it arrived, no using() promise needed.
    • DesktopArticleTarget.init#uri.query.venotify: This is the handler for after the case where save has to redirect/refresh (e.g. when creating a page or restoring). It can be specifically preloaded here with a one-off mw.loader.load().
Krinkle triaged this task as Medium priority.Oct 5 2017, 9:04 PM
Krinkle edited projects, added Performance-Team (Radar); removed Performance-Team.
Krinkle moved this task from Limbo to Watching on the Performance-Team (Radar) board.

Change 382614 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/extensions/VisualEditor@master] DesktopArticleTarget.init: Load 'mediawiki.action.view.postEdit' via loader

Change 382614 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] DesktopArticleTarget.init: Load 'mediawiki.action.view.postEdit' via loader