Page MenuHomePhabricator

Add JS hook(s) for extensions and gadgets to interact with the edit recovery process
Open, Needs TriagePublic


Extensions can add fields to the page editing form, and Edit Recovery will attempt to store and recover the data in these fields. But some need special handling, so appropriate JavaScript hooks should be added to Edit Recovery to enable extensions to change what gets stored.

For example, WikiEditor adds editingStatsId which changes over time and the new value of which should be used in a recovered edit.

Details t.b.d.

Event Timeline

The Edit-in-Sequence (T308098) feature of ProofreadPage has a similar unsaved-edit storage system, using localStorage. It might be possible to update that to use EditRecovery. If not, it needs to at least be possible to disable EditRecovery while EiS is enabled.

Just mentioning here, since it seems not unlikely that Edit Recovery will need to have the necessary hooks, depending on how strictly it's layered, to enable things like s:MediaWiki:Gadget-Easy_LST.js that need to transform wikitext on page load and before saving.

Details depend on the actual design of Edit Recovery and how things like EIS (T308098) use it, but if, say, a page load puts data into a Edit Recovery object store and it goes from there to #wpTextBox1 then something like Easy LST would need a mw.hook('editrecovery.before-pageload'). If the interaction with EIS ends up being that EIS requests Edit Recovery to "save these 18 pages", Easy LST would need a mw.hook('editrecovery.before-pagesave') for each of them. On some alternate designs I can envision, instead of hooking into actual load/save you'd do the same on cache update (so the Edit Recovery cache contains raw wikitext and the transform for Easy LST syntax happens between the Edit Recovery cache and #wpTextBox1, not between the cache and MW core persistence).

I also have a custom OCR user script (it transforms the text in various ways in addition to the plain OCR) that, for interactive performance reasons, tries to (speculatively) pregenerate and cache OCR for the current and subsequent Page:-namespace page. It currently stashes this data in localStorage, but, for reasons similar to those that led Edit Recovery to use IndexedDB instead of localStorage/sessionStorage, it might make sense to instead stash this as either a BLOB or JSON in an Edit Recovery IndexedDB slot.

I think these example use cases could be served by generic facilities in Edit Recovery with the right design and layering, but it might need splitting into a base layer and letting Edit Recovery's core feature be a client of its own base layer (i.e. your over-engineered alarm bells might reasonably be going off here).

Soda renamed this task from Add JS hook(s) for extensions to interact with the edit recovery process to Add JS hook(s) for extensions and gadgets to interact with the edit recovery process.Wed, Apr 3, 5:04 AM