Page MenuHomePhabricator

Make postEdit hook reliably support user interaction
Open, Needs TriagePublic

Description

Right after saving an edit is a very important point of interaction with the user. This is the natural time to explain how the community reviews edits, to possibly warn about wiki-specific features like FlaggedRevs hiding the edit suggest more tasks, to explain about watchlists, to suggest more editing tasks etc. But in MediaWiki it's under-utilized because the support for it is so poor. GrowthExperiments does a bucket of hacks to mostly make it work but that really shouldn't be necessary.

There is a Javascript hook that usually fires after edits (postEdit or postEditMobile) but it's borderline useless:

  • Some editors immediately reload the page after calling the hook, so it can't be used for user interaction.
  • As it's a Javascript hook, the hook handler needs to be loaded already, which requires a different mechanism for different editors.
  • The desktop and mobile hooks get different data, and the data is not super useful in either case (doesn't contain much information about the edit).

There are six significantly different major code paths (not counting extensions not used on Wikimedia wikis, popular editing gadgets etc) that need to be accounted for in a postEdit hook handler:

  1. Desktop wikitext editor: does a post-redirect-get on save, uses a cookie hack to pass some state through the redirect, sets the wgPostEdit JS variable and uses that to fire the postEdit hook. On the server side, can be detected in a hacky way on the server side.
  2. VisualEditor when the page is newly created, there was a wikitext -> VE switchover, or the editor was opened in some weird place (such as the page history): saves via its own API, then reloads the page. Adds (and after the reload hides) a venotify query parameter which makes this detectable on the server side and is also used to fire postEdit after the page reload. In some cases (when the editor was opened from a non-view action) it fires postEdit both before and after the reload.
  3. VisualEditor when none of the above is true: saves via its own API, tears down the editor and replaces page content without a reload, then fires postEdit. The VisalEditor API that's used for saving the edit provides some integration options which can be used to interact with this event on the server side, somewhat.
  4. MobileFrontend wikitext editor: saves via the action=edit API, fires the postEditMobile hook, then immediately triggers a page reload. Unlike postEdit this also gets called on a null edit, and passes data that allows differentiating that.
  5. VisualEditor in MobileFrontend overlay: saves via the VisualEditor API, tears down the editor, fires the postEditMobile hook, then changes the URL fragment but does not reload/navigate away.
  6. VisualEditor in MobileFrontend overlay when creating a new page (but not when switching from wikitext to visual editor): saves via the VisualEditor API, tears down the editor, fires the postEditMobile hook, then changes the URL fragment. Then reloads the page with a venotify query parameter added. (Unlike the desktop case, it does not get hidden away.)

(There are two more code paths via Flow and DiscussionTools if one also cares about talk page edits, and one more for ProofreadPage pages.)

This is very sad. There should be a single JS hook that

  • reliably supports user interaction, either by only being called after reload if there's a reload, or by using a promise to delay reload;
  • supports a single reliable way to configure that some ResoureLoader module should get loaded to handle the hook (maybe by providing a PHP hook that can examine the edit and decide what JS module needs to be loaded);
  • provides a reasonable amount of data about the edit.

Event Timeline

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

Change 928970 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/core@master] Allow extensions to replace default post-edit notifications

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

Change 928972 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/VisualEditor@master] Remove post-edit hacks for GrowthExperiments

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

Change 928974 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/MobileFrontend@master] Remove post-edit hacks for GrowthExperiments

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

Change 928975 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/GrowthExperiments@master] Use new way to replace post-edit notifications

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

matmarex subscribed.

I've been working on T338003, which removes some of the unique code paths, and I thought maybe I'll take a stab at this too. The GrowthExperiments patch is unfinished, but I think this approach will work.

@Tgr Would you find some time to review or finish this? I'd really like to get rid of the hacks for GrowthExperiments that appeared in lots of places because of this.

Change 928970 abandoned by Bartosz Dziewoński:

[mediawiki/core@master] Allow extensions to replace default post-edit notifications

Reason:

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

Change 928972 abandoned by Bartosz Dziewoński:

[mediawiki/extensions/VisualEditor@master] Remove post-edit hacks for GrowthExperiments

Reason:

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

Change 928974 abandoned by Bartosz Dziewoński:

[mediawiki/extensions/MobileFrontend@master] Remove post-edit hacks for GrowthExperiments

Reason:

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

Change 928975 abandoned by Bartosz Dziewoński:

[mediawiki/extensions/GrowthExperiments@master] Use new way to replace post-edit notifications

Reason:

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

I'm not working on this now, but I'd be happy to return to this idea if anyone else shows any interest in reviewing my changes or working together.