Announcement

Do not use the forums to submit bug reports, feature requests or patches, submit a New Ticket instead.

#1 2007-10-26 12:18:09

gwd
New member
Registered: 2007-10-26
Posts: 2

Dynamic removal/cleanup of Xinha instances

Hi,

I have recently tried tinymce, fckeditor etc and now Xinha using Drupal cms.
They all work for regular installs using the relevant Drupal module, but I want to do something a little different and Xinha is the only one that I've managed to get close to working the way I want.

I'm loading html pages as data (i.e. page regions) via flash and have flash talking to javascript to inject some content into the DOM on the fly. If additional js support is needed for the new content its loaded via ajax. This means that xinha is being loaded on demand if needed, the first time it is needed without a page refresh. If there are textareas in subsequent content it upgrades them to xinhas/htmlareas. So far I have it working as it should in firefox, although I will probably need to check it for memory leaks etc.
However there are problems in IE it stumbles and throws an error on pages it tries to initialise dynamically after working partially the first time.

What I did so far
I couldn't see anything obvious for completely destroying instances of xinhas - I can replace the page content which includes the iframes etc, but didn't know what happened to all the references/listeners. If I've overlooked something on that front please let me know.

One thing that I observed was that the __xinhas array kept growing as I was doing this even if I use deactivateEditor on all instances and I sometimes had xinhas appear embedded inside eachother. In firefox all that seemed to be required was to a) deactivate all __xinhas via a loop and then b) set the __xinhas array to []  (empty array). Just do that with each page change. This fixed things for firefox (although my javascript knowledge is very limited and I will need to check this for memory leaks). So I figure its very close to working in firefox.

In IE... it partially works. It works no problem if the initial page load is like a standard page load... i.e. it includes the xinha js and has xinha textareas. But if I load and apply the behavior dynamically it has a) a lot of extra spacing in the toolbarElements **sometimes** UPDATE see EDIT - UPDATE BELOW and b) subsequent content loads into the Xinhas fine, but renders the toolbars unresponsive.

I used the XinhaCore source  (0.94) for debugging and got the following error using js companion in IE7:
Unknown runtime error on line 3920:
this._statusBarTree.innerHTML = Xinha._lc("Path") + ": "; // cle

I **think** this is as a result of a editor._timerToolbar  setTimeout call. But I have no idea what's causing the error. And there are no (apparent) problems in firefox. There is no other major differences except perhaps that I'm using an extra iframe in IE to help with browser hash history/back button management and I don't need this for firefox. Please let me know if you think that could be interfering.

Is there anything I am overlooking to remove instances and listeners etc. (I did try using the flushEvents and collectGarbageForIE methods...but they seemed to do more harm than good for what I am doing. )
I may be able to post an example soon, I'm working on my own site.

Thanks for your patience in reading through this post... I know its long!
I don't expect an answer specifically... unless someone has dealt with this specifically. But if you have any pointers of where to look, what to research I'd really appreciate it.

EDIT - UPDATE
It turns out that the problem with the toolbar formatting was unrelated. It was caused by IE not loading an extra css file on demand in the same way that works in firefox. I was able to fix that part.
The problem with the embedded xinhas was related to 2 things: a) I was inappropriately attaching the xinha behaviors twice. and b) this was unnecessary... but under normal circumstances would not have been an issue. The problem is that I usually add a class like 'xinha-processed' each time I attach a behavior to an element that I have selected, excluding any elements with that class from the original selection. I use jquery to do this - my original selector was $('textarea[@editor="xinha"]:not(.xinha-processed)').each(...etc 
In this case, with the textareas, xinha adds its own class 'xinha_textarea' and seemed to overwrite rather than add to the class I was adding. So my approach here was failing to exclude the same textareas on the second call.
The successful jquery selector for this is:
$('textarea[@editor="xinha"]:not(.xinha_textarea)').each(
        function () {
          xinha_editors[xinha_editors.length] = this.id;
        }
      )

(this second problem was occuring in firefox as well, this was necessary for both browsers).


The only problem left is the one I described above for IE... I will report back if/how I can get it working completely in IE.

Many thanks
-Greg

Last edited by gwd (2007-10-27 12:29:04)

Offline

#2 2007-10-27 16:54:44

gwd
New member
Registered: 2007-10-26
Posts: 2

Re: Dynamic removal/cleanup of Xinha instances

OK. So I'm an idiot. Its now working in IE. Turns out I made another mistake and Firefox is somehow more forgiving of mistakes like the one I made. I was loading the results of a multistep form back into the page, but turns out I was loading inside the old form element instead of replacing it, resulting in nested identical form elements. Firefox didn't care. IE did. That was the cause of the problem in IE.
I'll still have to do some more testing for whether it consumes memory over time, but at least its working.

Offline

#3 2008-08-09 18:36:39

coyote4til7
New member
Registered: 2008-08-09
Posts: 1

Re: Dynamic removal/cleanup of Xinha instances

For me, the code above didn't remove the editor area from the page.  I added to his code and this did it:

# Kill all editors
$('textarea[@editor="xinha"]:not(.xinha_textarea)').each(
    function () {
        xinha_editors[xinha_editors.length] = this.id;
    }
);
# Kill the displayed editor
$('.htmlarea').remove();

I've only tested this in Firefox 3.0 for OS X.

Offline

Board footer

Powered by FluxBB