Opened 14 years ago

Closed 13 years ago

#191 closed defect (worksforme)

IE blocks Xinha after first load

Reported by: matthy@… Owned by: gogo
Priority: normal Milestone: Version 1.0
Component: Plugin_SuperClean Version: trunk
Severity: major Keywords: operation aborted panel superclean
Cc:

Description

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

Change History (18)

comment:1 Changed 14 years ago by kim@…

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

comment:2 Changed 14 years ago by matthy@…

  • Priority changed from high to highest

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

comment:3 Changed 14 years ago by 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.

comment:4 Changed 14 years ago by mokhet

  • Priority changed from highest to lowest

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 = [ ];

comment:5 Changed 14 years ago by mokhet

  • Component changed from Xinha Core to Plugin - Stylist
  • Keywords panel added

comment:6 Changed 14 years ago by 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

comment:7 Changed 14 years ago by gogo

  • Component changed from Plugin - Stylist to Xinha Core
  • Keywords superclean added
  • Priority changed from lowest to normal

comment:8 Changed 14 years ago by gogo

  • Component changed from Xinha Core to Plugin_SuperClean
  • Milestone set to Version 1.0
  • Version set to trunk

comment:9 Changed 14 years ago by 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.

comment:10 Changed 14 years ago by 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();
  }
}

comment:11 Changed 14 years ago by 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.

comment:12 Changed 14 years ago by 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?

comment:13 Changed 14 years ago by ivc

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

comment:14 Changed 14 years ago by 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).

comment:15 Changed 14 years ago by derekcopelin@…

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

comment:16 Changed 14 years ago by 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.

comment:17 Changed 13 years ago by anonymous

I corrected this issue in Samiportal:

samxinha_init = function () {

if( xinha_editors != null )

xinha_init();

}

window.onload = samxinha_init;

comment:18 Changed 13 years ago by gogo

  • Resolution set to worksforme
  • Status changed from new to closed

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.

Note: See TracTickets for help on using tickets.