We should have a mw.hook event for when wpTextbox1's content is used (to be used by extensions providing WYSIWYG/code highlighting etc. functionality which need to update it).
This could also replace the old deprecated 'LivePreviewPrepare' even fired on $(mw).
Brief discussion about this: https://gerrit.wikimedia.org/r/#/c/74314/1/resources/mediawiki.action/mediawiki.action.edit.preview.js
Version: 1.22.0
Severity: normal
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | None | T63117 CodeEditor doesn't have a "are you sure you want to leave this page" warning if there are unsaved changes | |||
| Resolved | None | T54071 Add mw.hook event for when wpTextbox1's content is used (to beused by extensions providing WYSIWYG/code highlighting etc. functionality) | |||
| Resolved | Krinkle | T25580 Implement JavaScript mw.hooks framework |
Describe what you mean by "wpTextbox1's content being used". I doubt to what degree an mw.hook would be appropriate as opposed to direct binding.
Can you describe how you'd like to see this work? Remember that mw.hook is (by design) not an event handler or even synchronous, so it can't correctly fired from e.g. form.onsubmit.
Change 110347 had a related patch set uploaded by Helder.wiki:
Fire hook "LivePreviewPrepare"
Change 110347 abandoned by Krinkle:
Fire hook "LivePreviewPrepare"
Reason:
Closing. A 'before' fire is not compatible with how mw.hook works (asynchronous).
Change 119527 had a related patch set uploaded by Helder.wiki:
Remove inexistent hook "LivePreviewPrepare"
Patch was merged a while ago - is there more work left to do here (if yes: please reset the bug report status to NEW or ASSIGNED), or can you close this ticket as RESOLVED FIXED?
It's not fixed. The patch merged on March 19 was removing a hook that had been tentatively added to CodeEditor because the patch to fire that hook in core never materialized.
It could be WONTFIX if the status quo (binding and firing a random event on the mw object) is to be maintained here, since mw.hook has apparently mutated from a replacement for binding and firing random events on objects (see bug 23580 comment 10) to some sort of not-really-an-event-handler asynchronous-firing mechanism (per comment 1 here, although its doc comments describe it as "Registry and firing of events").
Actually, per discussion we had on this per https://gerrit.wikimedia.org/r/#/c/121558
We need a bit of JS API work around this. Ideally there would be an API, where a editor can register, and then while that 'custom' editor for the wpTextbox1 is active, it is notified of and asked for certain events and actions.
This is thus very much the same problem that is currently blocking bug 61117.
Seems obsoleted by the textSelection API which CodeEditor etc already make use of now.