Last modified: 2009-08-14 07:58:47 UTC
The new toolbar is not compatible with the rich text editor wikEd (http://en.wikipedia.org/wiki/User_talk:Cacycle/wikEd). wikEd is used as a gadget on many MediaWikis as well as a Greasemonkey script. wikEd uses an iFrame in designmode as the edit area instead of the classical html textarea. The old toolbar has been made compatible with wikEd by redirecting the insertTags() function in edit.js to wikEd's own function WikEdInsertTags(). In order to make the new toolbar compatible with wikEd I need a "hook", anything that could be used to provide wikEd with the three insert strings (before, inside, after). I have checked the toolbar code, but was not able to come up with a mechanism to hook wikEd into the new toolbar. Trevor: please could you check the new toolbar code and point me to a solution or could you otherwise create such a hook (e.g. a function call that wikEd can redirect to its own function). Thanks, Cacycle
Done in r54680. The hook works as follows: // Do this in an onload hook or inside a jQuery(document).ready(function() { here }); jQuery('#wpTextbox1').bind('encapsulateSelection', function(e, before, inside, after) { // Do something with before, inside, after, e.g. WikEdInsertTags(before, inside, after); // or however this is done });
Thanks for this change. Unfortunately, this does not work yet. The problem is that the original button handler is still executed and tries to change / access the hidden (style.display = 'none') original textarea. And because the textarea is not displayed, accessing e.selectionStart (encapsulateSelection in plugin.combined.js, line 315 in rv 54680) terminates with an error message before throwing the encapsulateSelection event. There should be a way to prohibit the default event handling. Also, because one can switch between textarea and rich text frame, it must be possible to switch back and forth between both handlers. I hope this explains the situation a bit better than my original request :-)
JS error fixed in r54704
Thanks again. Maybe you could move the "(e.style.display != 'none')" test up so that no code but the event thrower will be executed under any browser when the textarea is not available. That might be a cleaner solution (even if it currently works under IE without errors).
(In reply to comment #4) > Thanks again. Maybe you could move the "(e.style.display != 'none')" test up so > that no code but the event thrower will be executed under any browser when the > textarea is not available. That might be a cleaner solution (even if it > currently works under IE without errors). > Good point. Done in r54716.
This is a good example of the API in use. (it's our tests to make sure it's working) http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/UsabilityInitiative/js/tests/wikiEditor.toolbar.js?view=markup
(In reply to comment #6) > This is a good example of the API in use. (it's our tests to make sure it's > working) > > http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/UsabilityInitiative/js/tests/wikiEditor.toolbar.js?view=markup > Please note that this means that the hook I added earlier has been removed in favor of this new API.
So what do I have to do to to temporarily redirect all new toolbar button push events to a different editor (i.e. wikEd). I have checked the code but couldn't quite figure that out.
(In reply to comment #8) > So what do I have to do to to temporarily redirect all new toolbar button push > events to a different editor (i.e. wikEd). I have checked the code but couldn't > quite figure that out. > Gah, my apologies. The API for adding and removing buttons changed, the one for catching the insert event and passing it to wikiEd is the same. *Slams head into wall*
