This isn't really a bug in mw.toolbar.

Support for the WikiEditor extensions' iframe used to be hardcoded in mw.toolbar.insertTags in mediawiki-core. This was removed in April of this year[1] and is no longer there now[2].

The insertion tool only works on plain text string containers anyway. That's not gonna change. Depending on how WikiEd works internally, I'd recommend one of two things:

• If not already, have WikiEd internally keep the text as a plain string and store this in the original textarea. Then listen for user input like you do already, and in addition listen for mechanical changes to the original (using "on('change')").

This is possible as iframes have their own relative focus. Make sure you have a text area in the original document (probably use wpTextbox1 for this) and ensure that one is focussed whenever you are able to receive input(e.g. when your "Search and replace" feature closes, focus that element).

• If you don't want to be limited by the (s)lowest common denominator (a plain text area in this case), bypass them this by overloading the "insertTags" function whenever WikiEd is active and apply the text insertion directly to your document model where the user has their cursor in the frame.

The latter allows you to avoid syncing back with the original text area (only needed when saving).

[1] https://github.com/wikimedia/mediawiki-core/commit/0bcbfeb3
[2] https://github.com/wikimedia/mediawiki-core/blob/7cf10514/resources/src/mediawiki.action/mediawiki.action.edit.js#L115

Hi Krinkle, thanks for your quick and detailed response.

I am actually already overloading the "insertTags" function whenever wikEd gets activated (i.e. I swap functions during setup) and then handle the insertion in wikEd. This works fine as long as the "input following mechanism" does not kick in. After the first focus on any input field (e.g. summary), the CharInsert text goes to that field instead of the overlaid wikEd function. Is there any way around this?