[TIMOB-1767] Android: event listeners in reopened window do not fire.

Description

Ti.UI.setBackgroundColor('#000');
Ti.UI.createWindow({
    backgroundColor: 'blue',
    url: 'main.js',
    fullscreen:true,
    exitOnClose: true
}).open();

var win = Ti.UI.currentWindow;
var btn = Ti.UI.createButton({
    title: 'open subwindow'
});

var win2 = Ti.UI.createWindow({
    url: 'sub.js',
    fullscreen: true,
    backgroundColor: 'red'
});
win2.addEventListener('close', function() {Ti.API.info('window close');});

btn.addEventListener('click', function(){win2.open();});

win.add(btn);

var win = Ti.UI.currentWindow;
var btn = Ti.UI.createButton({title: 'close'});
btn.addEventListener('click', function(){win.close();});
win.add(btn);

Attachments

Comments

1. Bill Dawson 2011-04-15

   Actually my failcase here is stupid. Each opening of the 2nd window stacks a button right on top of the previous button, (since all buttons from previous openings of the window get retained). Then the topmost button ends up being the first button, whose event listener has been destroyed. Each new button does indeed have an event listener -- it's just that the button never gets clicked (touched/tapped) since it's below all previous buttons.

   I'll put a more logical failcase in here.

2. Bill Dawson 2011-04-15

   Using our latest builds, I'm failing to find a relevant fail case. I've some fairly comprehensive testing, the details of which I'll paste here. The attached zip file contains the three test files.

   Tests

   The goals:

   1) in each of the below scenarios, the context that creates the second window will add a close event for it. Each time that second window closes, that close event in the creating context should fire.

   2) in each of the scenarios, the second window will get a "close" button put on to it. That close button will have a click event listener which, in turn, will close the window that it is on (i.e., the second window). This should always work.

   3) in two of the scenarios -- the scenarios that use 'url' properties for the second window -- the second window will get a second 'close' event listener created inside the second JS file. It should fire when the second window is closed. In this case, two 'close' event handlers should be created: the one from the first window and the one from inside the second window.

   Scenarios:

   a) Second window is a "heavyweight" window (a window that gets its own Android Activity) and has its own url. Go back to the first window using the 'Close' button. Reopen and repeat.

   b) Same as (a), but go back to the first window using the Android back button. Reopen and repeat.

   c) Second window is a "heavyweight" window (a window that gets its own Android Activity) but does not have its own url. Go back to the first window using the 'Close' button. Reopen and repeat.

   d) Same as (c), but go back to the first window using the Android back button. Reopen and repeat.

   e) Second window is a "lightweight" window and has its own url. (Note: cannot use Android back button because it's lightweight.) Click the 'Close' button to go back to the first window. Reopen and repeat.

   f) Second window is a "lightweight" window and does not have its own url. Click the 'Close' button to go back to the first window. Reopen and repeat.

   Scenario Results:

   a) Success. Close events were captured both from inside the second window and outside. The click event on the button inside the window always worked.

   b) same as (a)

   c) Success. The close event in the first window succeeded, and click event on the button in the second window always worked.

   d) same as (c)

   e) Success: the close button always worked, and the close event was always captured both in the first and second window's handlers.

   f) Success: the close button always worked and the close event was always captured in the handler in the first window.

3. Bill Dawson 2011-04-15

   Lukasz appears to be the only one following this. Lukasz do you have a fail case for the symptom described in the title of this item?

4. Lukasz 2011-04-15

   No, I do not have any fail case for this bug. I can of course test it, but not before Monday. I did not report this bug. My problem is a little bit different because I'm using TabGroups instead of Windows. Did you read this ticket https://appcelerator.lighthouseapp.com/projects/32238-titanium-mobile/tickets/1742"> "Android: Window in TabGroup loses event listeners"? I attached a fail case there.

   Thanks, Lukasz

5. Lukasz 2011-04-15

   Hi Bill,

   I've tested the scenarios using mobilesdk-1.4.1-20100909194301-osx.zip and all 6 are working correctly.

6. Friedrich Seydel 2011-04-15

   Hi Bill.
   I've tested the scenearios using mobilesdk-1.4.1-20100915120231-win32.zip and the close events were captured, but way too often.

   Results:
   a) Close event captured seven times.
   b) Close event captured two times.
   c) Close event captured four times.
   d) Close event captured one time.
   e) Close event captured seven times.
   f) Close event captured four times.

   And it seems memory is not always freed correctly when closing.

   Test Case: Set a big backgroundImage for win2 before opening, e.g. change the event listener in line 11 of main.js:
   

      btn.addEventListener('click', function(){
        win2.backgroundImage="http://ddiff.com/wp-content/uploads/2009/11/Hurricane-Isabel-NASA.jpg";
        win2.open();
      });
      

   Results:
   a) Crashes on second opening of subwindow: Unable to load bitmap. Not enough memory: bitmap size exceeds VM budget.
   b) same as (a)
   c) same as (a)
   d) Sucess: This DOES work without crashing!
   e) same as (a)
   f) same as (a)

   There seems to be a connection between this memory leak and the close event being captured more than once.
   Only scenario (d) is working properly, the event is captured once and there seems to be no leak.

7. Bill Dawson 2011-04-15

   Friedrich's comment relates to a different problem than that described by this item, so created #1827 and referenced Friedrich's comment.

   Closing this ticket as invalid since the original issue doesn't appear to be happening.

8. Lee Morris 2017-03-02 Closing as invalid.

JSON Source