IE blocks Xinha after first load

[matthy@…]

Hello,

I installed Xinha in a backoffice php website, seemed to work well, but in fact... When i open a page with a Xinha textarea item, it works well the first time. After that, if i try to open any other page with Xinha in my website, Internet Explorer gives me a red cross bug: "Internet Explorer cannot open the Internet site http://... Operation aborted". I have to reboot to make it work again... The problem is the same on different computers, XP SP2 french, 2003 server US... Please note i use the "nightly" version of Xinha (never made the "latest" version work, dunno why). I guess i made a mistake in the installation, or maybe there's a bug. Hope you can help me... Thanks for all your work !

Matthieu Bonne

[kim@…]

Maby you could post an URL of your installation, it would be easier for people to check it for you.

[matthy@…]

Ok but it's in french :D I'll guide you.

http://matthy.dyndns.org/kp/kpsite/html/admin/

Login with "xinha" / "xinha"... Go in "Ajouter une newsletter" or "Modifier la newsletter", it'll work, Xinha is loaded. Go back (with "Page précédente" or "Retour au menu principal"), go again to a page where Xinha is loaded: boom, error, no way to make it work again.

I tried to load Xinha without my CSS, bug is still here; but the "full_example.html" works fine, i don't understand...

Hope you can help me :) Thanks a lot.

Matthieu

[mokhet]

dont need to reboot eheh, just clear the cache was enough for me :p

instead of

 _editor_url  = "http://matthy.dyndns.org/kp/kpsite/html/admin/xinha/";

perhaps you could try

 _editor_url  = "/kp/kpsite/html/admin/xinha/";

Do you really need all the plugins ? i think some of them needs a bit of polishing before we can safely combos all of them.

I cant log at all in your backoffice with mozilla (win & gnu/linux), firefox (win & gnu/linux), opera (win) and konqueror (linux). is that intended ? :p So i couldnt get much information about the error despite

Ligne : 1308 Erreur : 'side' a la valeur Null ou n'est pas un object ('side' is Null or is not an object)

Seems Xinha is trying to remove the side panel which is not there.

what release are you using ?

Try to load less plugins and add them one after one until you find out what combination of plugin make the crash occurs.

[mokhet]

after digging a bit more with release 87 (error line 1304), it seems it's the plugin Stylist on first load. But can reproduce it on first load with Internet Explorer only. No errors with mozilla / firefox.

Error occurs for panel.side seems to not exists on first load with IE (release 87)

1302:  HTMLArea.prototype.removePanel = function(panel)
1303:  {
1304:    this._panels[panel.side].div.removeChild(panel);
1305:    var clean = [ ];

[matthy@…]

Hi, and thanks for your help :)

I tried to delete the line where Stylist is called, but the bug was still here... So i cut off the other plugins one by one and concluded the bug came from SuperClean... I can't tell you why, but all i know is that all works well without it. So... The issue is resolved for me, but maybe you'll have to check SuperClean's code for IE users :-) Thanks again for your quick help ! Regards,

Matthieu

[aschmidt@…]

This has been discussed in the forum and identified as an Explorer memory leak related to closures.

I'm here because I'm seeing the problem, too, even after removing everything but the Linker plugin from a problem page.

My point in writing is that I think this is probably not a plugin problem per se.

[aschmidt@…]

Here's an EXTREMELY dirty workaround for folks have this problem that need Xinha to work in a Right Now. It doesn't address the memory leak, but it takes advantage of the fact that if you launch a popup, then close it, you can indeed navigate to a new page which has Xinha on it and avoid the IE error.

The trick, of course, is that you have to put this on the page that triggers the problem, not the subsequent page that won't load.

I'd only put it on pages that are actually experiencing the problem, though--it's truly horrible.

xinha.init=function() {
  ...
  if (navigator.appName == "Microsoft Internet Explorer") {
    var arb=window.open('about:blank','workaround','toolbar=no,location=no,directories=no,menubar=no,scrollbars=no,resizable=no,status=no,width=1,height=1,screenX=0,screenY=5000');
    arb.close();
  }
}

[gogo]

I don't think this has anything to do with IE's leaky memory practices. The OP traced it down to SuperClean doing something incorrectly (which is why this bug is attached to SuperClean). Although I haven't seen the problem myself.

Your workaround, well, I have no idea why in the world that would make a difference. Oh to have inside knowledge of the IE code, that must be a real doozy.

[ivc]

Hi All!

Some of my clients using a laptop only is encountered with this problem as well.

I´ve tried as suggested to remove all plugins, but they are still experiencing the problem. Then I tried to remove the line 1304 (this._panels[panel.side].div.removeChild(panel);)..

I´m still waiting for respons from my clients, but is this removal correct?

[ivc]

Well, now I´ve heard from several of my clients, and by removing line 1304 completely the problem is gone..

[aschmidt@…]

Well, I may have been incorrect in just declaring that it was the memory leak, except that my Google searches for the error message seemed to link the error and the memory leak. I am duly chastised.

The deal is, I don't use SuperClean, and yet I get this error. I get it even if I disable all plugins. I found by accident that if I just so happened to click a link that popped up a window BEFORE I tried to leave the page that the error went away. Hence the weirdo workaround (which I also agree does not imply that I am a great programming mind--but it does work around the problem).

[derekcopelin@…]

Had the same problem tried all the options mentioned above and only the Memory leak fix worked.

[yermol]

We've encountered this problem in AreaEdit http://www.areaedit.com.

See the bug report in our tracker:

http://www.formvista.com/bugs.html?ticket_id=234

See this discussion:

http://dojotoolkit.org/pipermail/dojo-interest/2005-December/002190.html

In MSIE, under some circumstances, the body onload= handler is called before the DOM is fully built which generates the Operation Aborted error.

In my tests, building the editor at the bottom of the page after everything has loaded works around this problem.

[anonymous]

I corrected this issue in Samiportal:

samxinha_init = function () {

if( xinha_editors != null )

xinha_init();

}

window.onload = samxinha_init;

[gogo]

There has been no activity on this for so long that I suspect it's either no longer a problem, or was a problem for only a very small number of people. Closing it as worksforme, because it does.