gadget incompatibility: CharInsert / wikEd caused by insertTags() in mediawiki.action.edit.js
Closed, InvalidPublic

Description

The gadget compatibility between CharInsert and wikEd is broken by the code in insertTags() in mediawiki.action.edit.js.

Problem: insertTags() remembers the last active input box or wikiEditor iframe - but not the wikEd iframe. Therefore, after using one of the wikEd input boxes (e.g. search or replace), the CharInsert defaults to that box and does not get reset to the wikEd iframe.

wikEd is currently replacing the global insertTags() function with its own function in order to be able to handle text additions to its iframe. This gets reverted by that input following feature.


Version: unspecified
Severity: enhancement

bzimport added a project: MediaWiki-JavaScript.Via ConduitNov 22 2014, 3:26 AM
bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz67412.
Cacycle created this task.Via LegacyJul 2 2014, 12:41 PM
Krinkle added a comment.Via ConduitJul 2 2014, 4:28 PM

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

Cacycle added a comment.Via ConduitJul 3 2014, 12:44 PM

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?

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.