Community
Participate
Working Groups
Scenario: browser widget hosted by eclipse, web page loaded. If I hook an onbeforeunload js function in a web page that hook does not get called if you close the browser view by clicking the x in the tab or by choose close from the popup menu. If you navigate() to another URL the hooks is called just fine. Normally, this should not an issue, but IE specifially has problem releasing memory when circular references between JS code and DOM objects exist. Read more here: http://www.bazon.net/mishoo/articles.epl?art_id=824 http://jibbering.com/faq/faq_notes/closures.html#clMem So in some situations, this is absolutely necessary as otherwise big memory leaks can happen (for example some top level divs have ciruclar references in play - in which case the whole DOM may not be freed correctly). A work around would be that on close, a browser widget could navigate to an empty page (the navigation will trigger the onbeforeunload). The empty page has nothing of value so closing it without calling the proper hooks should do less harm. I have searched the archives and I can't figure out how to do the workaround. It seems that .dispose() is the right place to hook the code, but at that point, it's too late. I would need to hook to the close event event and be the first listner to be run to correctly solve this ... anyway to do this ?
Vetoable/cancelable event handlers could to the trick. I have a filed a bug for that as well and noticed that this was asked several times before. Can it be added ? https://bugs.eclipse.org/bugs/show_bug.cgi?id=84644
Michael: is this a problem for your current SWT/Eclipse project? This may be quiet specific and better worked around at the javascript level - avoid the conditions of the bug - rather than at the SWT binding level.
I am actually working on a BPEL plugin for eclipse (curtesy of oracle.com). The problem *can* be worked around in the Javascript code inside IE as you point out. However, the trouble is that when the IE control is disposed (the view is closed) the handler window.onbeforeunload() is never called in IE land - the SWT embedding of the ie control has a bug ... it never calls onbeforeunload() on close and hence my bug cleanup hook is never called. if you call browser.navigate() from the java layer, then the onbeforeunload() hook is called correctly - just not on close. So my thinking was: either fix the browser embedding code to call the hooks on exit correctly or provide a vetoable notification handler on the view close event. This way, I could intercept the user close request, veto it, then navigate to an empty page in the browser (that is unload the document correctly) and then issue a programmatic close (and obviously not veto it). I had also filed a bug with the UI group (the editor frameworks) so that these types of vetoable notifications can be added - a number of people had asked for the same thing in the newsgroups before and noone has come up with an acceptable workaround. This bug (potentially) affects any page loaded in IE. I can probably come up with a simple test case for you .... so that you can see how the memory is never reclaimed.
Wondering if it is related to bug 15139.
I would also like to see this bug fixed. We are currently embedding a web application in an Eclipse application and the web application makes heavy use of the onbeforeunload-event to free resources on the server. BTW: The summary of this bug seems to be a bit misleading since the discussion concerns the missing onbeforeunload-event and not the memory leak which may be a consequence of it. I suggest to rename it.
It might benefit everyone involved if someone could post version information about the versions, and possible build numbers, of IE that are effected. Microsoft released a security patch[1] recently for IE6 that fixed some memory leak issues[3]. Has this fixed the issue for anyone? [1] http://support.microsoft.com/kb/933566/ [2] http://support.microsoft.com/kb/929874/
changing summary to reflect the root issue
Created attachment 147008 [details] patch to revisit after 3.6M2
fixed > 20090921
