Last modified: 2014-07-03 12:44:28 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T69412, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 67412 - gadget incompatibility: CharInsert / wikEd caused by insertTags() in mediawiki.action.edit.js
gadget incompatibility: CharInsert / wikEd caused by insertTags() in mediawik...
Status: RESOLVED INVALID
Product: MediaWiki
Classification: Unclassified
JavaScript (Other open bugs)
unspecified
All All
: Low enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-07-02 12:41 UTC by Cacycle
Modified: 2014-07-03 12:44 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Cacycle 2014-07-02 12:41:28 UTC
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.
Comment 1 Krinkle 2014-07-02 16:28:06 UTC
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
Comment 2 Cacycle 2014-07-03 12:44:28 UTC
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?

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links