{ "id": "61791", "key": "TIMOB-1159", "fields": { "issuetype": { "id": "1", "description": "A problem which impairs or prevents the functions of the product.", "name": "Bug", "subtask": false }, "project": { "id": "10153", "key": "TIMOB", "name": "Titanium SDK/CLI", "projectCategory": { "id": "10100", "description": "Titanium and related SDKs used in application development", "name": "Client" } }, "fixVersions": [ { "id": "11238", "name": "Release 1.6.0 M05", "archived": true, "released": true, "releaseDate": "2011-01-17" } ], "resolution": { "id": "6", "description": "", "name": "Hold" }, "resolutiondate": "2011-04-15T02:45:29.000+0000", "created": "2011-04-15T02:45:26.000+0000", "priority": { "name": "Low", "id": "4" }, "labels": [ "1.3.0", "backbutton", "crash", "design", "ios", "mm", "navbar", "release-1.6.0", "tabGroup", "tabgroup" ], "versions": [], "issuelinks": [], "assignee": { "name": "rseagraves", "key": "rseagraves", "displayName": "Reggie Seagraves", "active": true, "timeZone": "America/Los_Angeles" }, "updated": "2017-03-03T06:44:48.000+0000", "status": { "description": "The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.", "name": "Closed", "id": "6", "statusCategory": { "id": 3, "key": "done", "colorName": "green", "name": "Done" } }, "components": [ { "id": "10206", "name": "iOS", "description": "iOS Platform" } ], "description": "{html}
Consider an app using a TabGroup, opening windows with\nTab.open(), and setting Window.backButtonTitle. We'll nest 3\nwindows inside each other - call them A, B, and C. It is possible\nto cause strange behavior and even crash such an app:
\n1) starting at A, tap a button to open B
\n2) tap a button in B to open C
\n3) before C opens, tap B's back button
\n4) A will appear immediately
\n5) C will appear when it is ready
\n6) C's back button now leads to A
This also works if C is just a complex View. In that case C will\nrender OVER A. In other cases C is doing something complex and the\napp can crash.
\nExpected behavior would be for C to be canceled completely after\nstep 3 so that steps 5 & 6 above are prevented.
By the way, you won't be able to click that fast on the\nsimulator, but with our app on an ipod touch, there is more than\nenough time to do it.
I had the same problem with 1.3.0, but the \"1.3.1\" or 1.4.0 (?)\nfrom git not produce this in my application.
\nI don't know if it was the same problem or not, but my app had\ncrashed if I switched windows fast, or clicked to a not fully\nloaded view and back to previous window.
This is very likely a race condition which may have been solved\nby certain kinds of property ordering if it is no longer\nreproducible.
I really want to revisit this in the future of what is the\n'correct' behavior. Possibly related to opening sequence
Tagged for massive meeting (MM)
This merits discussion with Jeff, after talking with Blain.
\nAdded the design tag.