app.js:
\n\nTi.UI.setBackgroundColor('#000');\nTi.UI.createWindow({\n backgroundColor: 'blue',\n url: 'main.js',\n fullscreen:true,\n exitOnClose: true\n}).open();\n\nmain.js:
\n\n\nvar win = Ti.UI.currentWindow;\nvar btn = Ti.UI.createButton({\n title: 'open subwindow'\n});\n\nvar win2 = Ti.UI.createWindow({\n url: 'sub.js',\n fullscreen: true,\n backgroundColor: 'red'\n});\nwin2.addEventListener('close', function() {Ti.API.info('window close');});\n\nbtn.addEventListener('click', function(){win2.open();});\n\nwin.add(btn);\n\nsub.js:
\n\nvar win = Ti.UI.currentWindow;\nvar btn = Ti.UI.createButton({title: 'close'});\nbtn.addEventListener('click', function(){win.close();});\nwin.add(btn);\n\nThe second time you open sub window, the button inside it will\nnot work anymore.
\nVery likely caused by \nthis commit, wherein I thought I was limiting to app events --\nbut perhaps that distinction cannot really be made.
Actually my failcase here is stupid. Each opening of the 2nd\nwindow stacks a button right on top of the previous button, (since\nall buttons from previous openings of the window get retained).\nThen the topmost button ends up being the first button, whose event\nlistener has been destroyed. Each new button does indeed have an\nevent listener -- it's just that the button never gets clicked\n(touched/tapped) since it's below all previous buttons.
\nI'll put a more logical failcase in here.
Using our latest builds, I'm failing to find a relevant fail\ncase. I've some fairly comprehensive testing, the details of which\nI'll paste here. The attached zip file contains the three test\nfiles.
\nThe goals:
\n1) in each of the below scenarios, the context that creates the\nsecond window will add a close event for it. Each time that second\nwindow closes, that close event in the creating context should\nfire.
\n2) in each of the scenarios, the second window will get a\n\"close\" button put on to it. That close button will have a click\nevent listener which, in turn, will close the window that it is on\n(i.e., the second window). This should always work.
\n3) in two of the scenarios -- the scenarios that use 'url'\nproperties for the second window -- the second window will get a\nsecond 'close' event listener created inside the second JS file. It\nshould fire when the second window is closed. In this case, two\n'close' event handlers should be created: the one from the first\nwindow and the one from inside the second window.
\nScenarios:
\na) Second window is a \"heavyweight\" window (a window that gets\nits own Android Activity) and has its own url. Go back to the first\nwindow using the 'Close' button. Reopen and repeat.
\nb) Same as (a), but go back to the first window using the\nAndroid back button. Reopen and repeat.
\nc) Second window is a \"heavyweight\" window (a window that gets\nits own Android Activity) but does not have its own url. Go back to\nthe first window using the 'Close' button. Reopen and repeat.
\nd) Same as (c), but go back to the first window using the\nAndroid back button. Reopen and repeat.
\ne) Second window is a \"lightweight\" window and has its own url.\n(Note: cannot use Android back button because it's lightweight.)\nClick the 'Close' button to go back to the first window. Reopen and\nrepeat.
\nf) Second window is a \"lightweight\" window and does not have its\nown url. Click the 'Close' button to go back to the first window.\nReopen and repeat.
\nScenario Results:
\na) Success. Close events were captured both from inside the\nsecond window and outside. The click event on the button inside the\nwindow always worked.
\nb) same as (a)
\nc) Success. The close event in the first window succeeded, and\nclick event on the button in the second window always worked.
\nd) same as (c)
\ne) Success: the close button always worked, and the close event\nwas always captured both in the first and second window's\nhandlers.
\nf) Success: the close button always worked and the close event\nwas always captured in the handler in the first window.
Lukasz appears to be the only one following this. Lukasz do you\nhave a fail case for the symptom described in the title of this\nitem?
No, I do not have any fail case for this bug. I can of course\ntest it, but not before Monday. I did not report this bug. My\nproblem is a little bit different because I'm using TabGroups\ninstead of Windows. Did you read this ticket \n\"Android: Window in TabGroup loses event listeners\"? I attached\na fail case there.
\nThanks, Lukasz
Hi Bill,
\nI've tested the scenarios using\nmobilesdk-1.4.1-20100909194301-osx.zip and all 6 are working\ncorrectly.
Hi Bill.
\nI've tested the scenearios using\nmobilesdk-1.4.1-20100915120231-win32.zip and the close events were\ncaptured, but way too often.
Results:
\na) Close event captured seven times.
\nb) Close event captured two times.
\nc) Close event captured four times.
\nd) Close event captured one time.
\ne) Close event captured seven times.
\nf) Close event captured four times.
And it seems memory is not always freed correctly when\nclosing.
\nTest Case: Set a big backgroundImage for win2 before opening,\ne.g. change the event listener in line 11 of main.js:
\nbtn.addEventListener('click', function(){\n win2.backgroundImage=\"http://ddiff.com/wp-content/uploads/2009/11/Hurricane-Isabel-NASA.jpg\";\n win2.open();\n});\n\nResults:There seems to be a connection between this memory leak and the\nclose event being captured more than once.
\nOnly scenario (d) is working properly, the event is captured once\nand there seems to be no leak.
Friedrich's comment relates to a different problem than that\ndescribed by this item, so created #1827 and\nreferenced Friedrich's comment.
\nClosing this ticket as invalid since the original issue doesn't\nappear to be happening.