Page MenuHomePhabricator

Add mw.hook event for when wpTextbox1's content is used (to beused by extensions providing WYSIWYG/code highlighting etc. functionality)
Closed, ResolvedPublic


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:

Version: 1.22.0
Severity: normal



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:50 AM
bzimport set Reference to bz52071.
bzimport added a subscriber: Unknown Object (MLST).

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
Fire hook "LivePreviewPrepare"

Change 110347 abandoned by Krinkle:
Fire hook "LivePreviewPrepare"

Closing. A 'before' fire is not compatible with how mw.hook works (asynchronous).

Change 119527 had a related patch set uploaded by
Remove inexistent hook "LivePreviewPrepare"

Change 119527 merged by jenkins-bot:
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

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.