[TIMOB-1767] Android: event listeners in reopened window do not fire.
| GitHub Issue | n/a |
|---|---|
| Type | Bug |
| Priority | Trivial |
| Status | Closed |
| Resolution | Invalid |
| Resolution Date | 2011-04-15T03:01:40.000+0000 |
| Affected Version/s | n/a |
| Fix Version/s | Release 1.5.0 |
| Components | Android |
| Labels | android, defect |
| Reporter | Bill Dawson |
| Assignee | Bill Dawson |
| Created | 2011-04-15T03:01:38.000+0000 |
| Updated | 2017-03-02T19:03:23.000+0000 |
Description
app.js:
Ti.UI.setBackgroundColor('#000');
Ti.UI.createWindow({
backgroundColor: 'blue',
url: 'main.js',
fullscreen:true,
exitOnClose: true
}).open();
main.js:
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);
sub.js:
var win = Ti.UI.currentWindow;
var btn = Ti.UI.createButton({title: 'close'});
btn.addEventListener('click', function(){win.close();});
win.add(btn);
The second time you open sub window, the button inside it will not work anymore.
Very likely caused by http://github.com/appcelerator/titanium_mobile/commit/026c645a26d0c83587246af2eaf8d6e82ae65179"> this commit, wherein I thought I was limiting to app events -- but perhaps that distinction cannot really be made.
Attachments
| File | Date | Size |
|---|---|---|
| test_files.zip | 2011-04-15T03:01:39.000+0000 | 1218 |
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.
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.
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?
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
Hi Bill,
I've tested the scenarios using mobilesdk-1.4.1-20100909194301-osx.zip and all 6 are working correctly.
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:
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.
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.
Closing as invalid.