About posted tickets: important bugs

forgottentowers · 2005-02-22 22:05:37

Hi everyone

I think Xinha is cool, I not a skilled javascript developer, then for now, I only report bugs or things that I considered bugs, I hope in the future I can help in anyway to the project.

I posted Ticked 29, 30 and 33, I think 30 and 33 are very important to improve Xinha textarea, I hope you think the same.

Ticket 30: (Memory leak) Everytime You reload a page with the Xinha component it´s enlarge his process memory size (try using Task Manager: iexplorer process that is running xinha). If you close this page, but if this page have an opener, then you need to close all windows to restore memory, I refresh a few times and the ie process reach 60mb... wow.

Ticket 33: (onSubmit form desn´t work) I try to validate a form with Xinha textarea, where I need to check some texts and textarea himself, but onsubmit not work, when I submit (pressing the Submit button) only go to the "action" page, onSubmit was ignored.

forgottentowers

Chris Allison · 2005-02-24 01:29:39

forgottentowers wrote:

Ticket 30: (Memory leak) Everytime You reload a page with the Xinha component it´s enlarge his process memory size (try using Task Manager: iexplorer process that is running xinha). If you close this page, but if this page have an opener, then you need to close all windows to restore memory, I refresh a few times and the ie process reach 60mb... wow.
forgottentowers

You aren't going to like this answer, but here is some information about this bug. I believe this bug is actually caused by an IE bug with closures. Closures are some type of programming method that can be used in Javascript. I do not know too much about them. However, I believe that Xinha/htmlArea uses them a lot. If you want to read more about them and IE's problem with them, please read the following:

http://www.bazon.net/mishoo/articles.epl?art_id=824

That was written by Mishoo who is the original developer of htmlArea. He does not refer to htmlArea directly about this problem, but it is my opinion that this is probably the same cause of the memory leak in htmlArea.

In summary, I believe the core of Xinha probably uses closures a lot, and it would not be an easy task to remove them. James could probably add more input here, since he probably knows much more about closures than I.

I should probably add these comments to the bug report. Let me see if I can do that.

forgottentowers · 2005-02-24 21:05:51

Chris Allison wrote:

forgottentowers wrote:
Ticket 30: (Memory leak) Everytime You reload a page with the Xinha component it´s enlarge his process memory size (try using Task Manager: iexplorer process that is running xinha). If you close this page, but if this page have an opener, then you need to close all windows to restore memory, I refresh a few times and the ie process reach 60mb... wow.
forgottentowers
You aren't going to like this answer, but here is some information about this bug. I believe this bug is actually caused by an IE bug with closures. Closures are some type of programming method that can be used in Javascript. I do not know too much about them. However, I believe that Xinha/htmlArea uses them a lot. If you want to read more about them and IE's problem with them, please read the following:
http://www.bazon.net/mishoo/articles.epl?art_id=824
That was written by Mishoo who is the original developer of htmlArea. He does not refer to htmlArea directly about this problem, but it is my opinion that this is probably the same cause of the memory leak in htmlArea.
In summary, I believe the core of Xinha probably uses closures a lot, and it would not be an easy task to remove them. James could probably add more input here, since he probably knows much more about closures than I.

Thanks Chris
I read the url. I hope in the future Microsoft fix ie explorer. I think closures are a important thing if they were 100% compatibles.

I think maybe the best thing will be to rebuild Xinha code looking for bugs that make it incompatible.
Easy to say but very difficult to do, lamentably.

forgottentowers · 2005-02-24 21:14:16

Hi there, this isn´t a bug.
But I try to import an external css stylesheet without success,
Can anybody give me a hand? thanks in advance. (ticket #40)

In textarea only needs:
editor1.config.pageStyle = "@import url(mystyle.css);";

But now, using Xinha, I try but nothing happens
I used:

xinha_editors.config.myTextArea.pageStyle = "@import url(../css/mycss.css)";

but it didn´t work.
What can I import external css style sheets? some one can help me?

anzenews · 2005-02-24 23:40:39

If you use FullPage plugin - don't.

I had the same problem (not only that, Stylist also didn't change formatting) and not loading FullPage plugin helped.

Hope it helps.

Anze

gogo · 2005-02-27 01:26:51

Chris Allison wrote:

In summary, I believe the core of Xinha probably uses closures a lot, and it would not be an easy task to remove them. James could probably add more input here, since he probably knows much more about closures than I.

Yes that sounds plausable. Closures are, well, hard to describe, basically when you create a function in javascript it has access (when called) to all the variables that were defined in the same (or ancestor) scope that you defined the function in. Whoosh, that probably went over most peoples heads

They are a very useful feature of Javascript, and you're right, Xinha uses them extensivly, actually, lost of Javascript uses them extensivly because it's kind of a wether you need it or not thing (creating a function creates a closure).

I'd put money on it that it's a recursive reference problem with the IE garbage collector. Essentially a garbage collector runs periodically and frees up memory no longer in use (nothing references it), my thought is that IE's collector is not freeing (indirectly) recursivly referenced memory.

Short answer - can't be fixed.

Long answer - can't be fixed by me.

Foxx · 2005-02-27 13:49:23

I don't know if you read mishoo's article on closures, but he suggests a way around it, it leaves you with the same functionality, but it solves the IE memory leak....

gogo · 2005-02-27 20:17:58

Foxx wrote:

I don't know if you read mishoo's article on closures, but he suggests a way around it, it leaves you with the same functionality, but it solves the IE memory leak....

His workaround isn't practical, I don't think we'd ever get all the references before they are lost to us (this is the problem, they become inaccessable to us, but IE still thinks they are alive) so that we could nullify them. It would be a mammoth undertaking.

Chris Allison · 2005-02-28 01:06:18

So, in conclusion, your only hope is a possible fix in Longhorn, since Microsoft is not planning to update IE until then. And even if that happens, you have to wait for users to upgrade to Longhorn, since I doubt the updated IE in Longhorn will be backported to older OS's. And, judging from the slow adoption rates of XP, that could be a long time.

P.S. - This problem doesn't happen in Firefox, correct? I guess that is pretty good workaround.

P. P. S. - Is there anyway to open a new IE "process" (not just a window under the same process) from a link in a webpage in IE? If that is possible (I don't believe it is), you could solve your problem by placing Xinha in the popup, and then the memory would be cleared after the user closed the popup window. Even if this was possible, you would probably have issues with sessions not carrying across multiple IE processes and etc..

Last edited by Chris Allison (2005-02-28 01:09:17)

Chris Allison · 2005-02-28 01:14:29

By the way, here is some more information on this that I read a while back.

It can be found at: http://jibbering.com/faq/faq_notes/closures.html

The Internet Explorer Memory Leak Problem
The Internet Explorer web browser (verified on versions 4 to 6 (6 is current at the time of writing)) has a fault in its garbage collection system that prevents it from garbage collecting ECMAScript and some host objects if those host objects form part of a "circular" reference. The host objects in question are any DOM Nodes (including the document object and its descendants) and ActiveX objects. If a circular reference is formed including one or more of them, then none of the objects involved will be freed until the browser is closed down, and the memory that they consume will be unavailable to the system until that happens.
A circular reference is when two or more objects refer to each other in a way that can be followed and lead back to the starting point. Such as object 1 has a property that refers to object 2, object 2 has a property that refers to object 3 and object 3 has a property that refers back to object 1. With pure ECMAScript objects as soon as no other objects refer to any of objects 1, 2 or 3 the fact that they only refer to each other is recognised and they are made available for garbage collection. But on Internet Explorer, if any of those objects happen to be a DOM Node or ActiveX object, the garbage collection cannot see that the circular relationship between them is isolated from the rest of the system and free them. Instead they all stay in memory until the browser is closed.
Closures are extremely good at forming circular references. If a function object that forms a closure is assigned as, for example, and event handler on a DOM Node, and a reference to that Node is assigned to one of the Activation/Variable objects in its scope chain then a circular reference exists. DOM_Node.onevent -> function_object.[[scope]] -> scope_chain -> Activation_object.nodeRef -> DOM_Node. It is very easy to do, and a bit of browsing around a site that forms such a reference in a piece of code common to each page can consume most of the systems memory (possibly all).
Care can be taken to avoid forming circular references and remedial action can be taken when they cannot otherwise be avoided, such as using IE's onunload event to null event handling function references. Recognising the problem and understanding closures (and their mechanism) is the key to avoiding this problem with IE.

gogo · 2005-02-28 03:58:26

Chris Allison wrote:

So, in conclusion, your only hope is a possible fix in Longhorn, since Microsoft is not planning to update IE until then.

Thats about the size of it, except that MS has indicated they will release a new IE sooner than longhorn now, how much improved it is over the current IE remains to be seen, my guess is some cosmetical stuff and not much more.

There's nothing else we can do, it's very easy to make circular references in javascript even when you don't intend to, and destroying those circular references before you lose a reference to some point in the circle outside of the circle, when the references can be anywhere and everywhere, well, you can imagine how that is unworkable.

P.S. - This problem doesn't happen in Firefox, correct? I guess that is pretty good workaround.

Correct, it's only Microsoft's JScript engine (thier version of Javascript/ECMAScript) which doesn't garbage collect the circular references correctly. It's a bug in there, not with the language.

P. P. S. - Is there anyway to open a new IE "process" (not just a window under the same process) from a link in a webpage in IE?

I shoulsn't imagine so (security hole), even if there were, IE is so tightly coupled to Windows that I expect it woudln't make a difference.

If that is possible (I don't believe it is), you could solve your problem by placing Xinha in the popup, and then the memory would be cleared after the user closed the popup window. Even if this was possible, you would probably have issues with sessions not carrying across multiple IE processes and etc..

Yes I would epect that even if it were possible to have two totally distinct IE processes running at once, that there could be no IPC (inter process communication) between them at the javascript level, for security reasons if nothing else.

Xinha Discussion Forum

Announcement

#1 2005-02-22 22:05:37

About posted tickets: important bugs

#2 2005-02-24 01:29:39

Re: About posted tickets: important bugs

#3 2005-02-24 21:05:51

Re: About posted tickets: important bugs

#4 2005-02-24 21:14:16

Re: About posted tickets: important bugs

#5 2005-02-24 23:40:39

Re: About posted tickets: important bugs

#6 2005-02-27 01:26:51

Re: About posted tickets: important bugs

#7 2005-02-27 13:49:23

Re: About posted tickets: important bugs

#8 2005-02-27 20:17:58

Re: About posted tickets: important bugs

#9 2005-02-28 01:06:18

Re: About posted tickets: important bugs

#10 2005-02-28 01:14:29

Re: About posted tickets: important bugs

#11 2005-02-28 03:58:26

Re: About posted tickets: important bugs

Board footer