Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-1558] iOS - Closing a window in a navigationGroup closes the window before sliding back

GitHub Issuen/a
TypeBug
PriorityMedium
StatusClosed
ResolutionCannot Reproduce
Resolution Date2011-08-02T13:41:22.000+0000
Affected Version/sRelease 1.7.1
Fix Version/sSprint 2011-31
ComponentsiOS
Labelsn/a
ReporterDawson Toth
AssigneeBlain Hamon
Created2011-04-15T02:56:00.000+0000
Updated2011-08-02T14:30:51.000+0000

Description

Problem

Programmatically closing a window in a navigation group causes it to disappear before it slides off the screen.

Reproduction

Drop the following in an app.js. 1. You'll start off by seeing a blue window. This is the outermost window in the nav group. 2. After 2 seconds, a green window will open in the nav group. It will slide in. We're good so far. 3. After 2 seconds, the green window will close; it will disappear, revealing the red background of the nav group's container. The blue window will slide back in to place. 4. After 2 seconds, the green window will open again. Click the "Back" button this time, and you'll see it slides away properly without disappearing first.
var outerWin = Ti.UI.createWindow({ backgroundColor: 'red' });

var childWin1 = Ti.UI.createWindow({ backgroundColor: 'blue' });
var childWin2 = Ti.UI.createWindow({ backgroundColor: 'green' });

var nav = Ti.UI.iPhone.createNavigationGroup({ window: childWin1 });
outerWin.add(nav);

outerWin.open();

function open() {
    nav.open(childWin2, { animated: true });
    setTimeout(close, 2000);
}
function close() {
    nav.close(childWin2, { animated: true });
    setTimeout(open, 2000);
}

setTimeout(open, 2000);

Expected Behavior

When you programmatically close a window in a nav group, it should slide away smoothly without disappearing.

Associated Helpdesk Ticket

http://appc.me/XTG-54178-122

Comments

  1. chrismi 2011-04-15

    I'm kind of surprised this has passed QA. I hope you are able to patch this quickly, as it's a show stopper for many navigation group based applications.

    Alternatively, is there a way to programatically click the back button instead? Clicking the back button results in the desired behavior.

  2. Sindre Sorhus 2011-04-15

    This should really be fixed in 1.5.0.
    It's a showstopper for my app, and probably many others too...

  3. chrismi 2011-04-15

    Do you have any information about the progress of this ticket?

    We have an app for a customer ready for submission, just awaiting this bug to be fixed. As this looks now, table-view based apps are bad-looking. I sincerely hope this can be fixed in time for the 1.5.0 release. I also have the feeling that this bug is the root cause of several other currently open tickets for the 1.5.0 release.

  4. Dawson Toth 2011-07-14

    I updated the ticket based on customer interest; it should be much easier to repro now, and the bug reported here should be clearer. Let me know if there's any additional details I can get to grease the wheels on this one.
  5. Dawson Toth 2011-07-14

    Forgot to update the affected version and test environment. Done...
  6. Alan Leard 2011-07-19

    Pro customer waiting for resolution. HD Ticket: http://appc.me/c/APP-247321
  7. Blain Hamon 2011-08-02

    I do believe this was solved in another bug (possibly duplicate of TIMOB-1564). One thing I noticed is that the test reuses the same window over and over, and using the back button during the script does make things run off the rails, in that the script tries to then open an already-open window (shouldn't be done).
  8. Dawson Toth 2011-08-02

    Agreed, I can't reproduce anymore (on 1.7.2). It must have been fixed by one of our other changes.

JSON Source