{
	"id": "91276",
	"key": "TIMOB-8974",
	"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": [],
		"resolution": null,
		"resolutiondate": null,
		"created": "2012-05-03T10:30:34.000+0000",
		"priority": {
			"name": "Low",
			"id": "4"
		},
		"labels": [
			"core"
		],
		"versions": [
			{
				"id": "13272",
				"description": "Release 2.0.1",
				"name": "Release 2.0.1",
				"archived": true,
				"released": true,
				"releaseDate": "2012-04-16"
			}
		],
		"issuelinks": [],
		"assignee": null,
		"updated": "2018-02-28T20:04:13.000+0000",
		"status": {
			"description": "This issue was once resolved, but the resolution was deemed incorrect. From here issues are either marked assigned or resolved.",
			"name": "Reopened",
			"id": "4",
			"statusCategory": {
				"id": 2,
				"key": "new",
				"colorName": "blue-gray",
				"name": "To Do"
			}
		},
		"components": [
			{
				"id": "10206",
				"name": "iOS",
				"description": "iOS Platform"
			}
		],
		"description": "Currently, iOS has many situations in which `-[TiProxy _initWithPageContext:]` does not pass a page context, but rather an execution context. In many situations this is acceptable and they may be identical, but it could be leading to subtle memory-related bugs and cross-context issues. We need to investigate the problem and make sure that each proxy is initialized with an appropriate JS context for its scope and lifespan.",
		"attachment": [],
		"flagged": false,
		"summary": "iOS: May be using executionContext for proxy creation when pageContext should be used",
		"creator": {
			"name": "stephentramer",
			"key": "stephentramer",
			"displayName": "Stephen Tramer",
			"active": true,
			"timeZone": "America/Los_Angeles"
		},
		"subtasks": [],
		"reporter": {
			"name": "stephentramer",
			"key": "stephentramer",
			"displayName": "Stephen Tramer",
			"active": true,
			"timeZone": "America/Los_Angeles"
		},
		"environment": null,
		"comment": {
			"comments": [
				{
					"id": "193619",
					"author": {
						"name": "blainhamon",
						"key": "blainhamon",
						"displayName": "Blain Hamon",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"body": "The page context is the execution context in which the proxy was created. That is:\r\napp.js\r\n{code}\r\nvar win = Ti.UI.createWindow({url:'foo.js'});\r\nwin.table = Ti.UI.createTableView();\r\nwin.add(win.table);\r\nwin.open();\r\n{code}\r\n\r\nfoo.js\r\n{code}\r\nTi.UI.currentWindow.table.setData([{title:'baz'}]);\r\n{code}\r\n\r\nwin and win.table are both created in app.js's execution context, and thus have the page context of the one running app.js, and that will be the case for the life of the proxies.\r\n\r\nTi.UI.currentWindow.table is the same as app.js's win.table. And while it still has the pagecontext of the one running app.js, the setData command is done inside foo.js, and thus, its execution context will be foo.js's.\r\n\r\nSo setData runs with the foo.js execution context, and creates a row as a side effect. The row's page context MUST be the context it was created in (as to establish relationship) which is foo.js, despite the table itself having a page context of app.js.\r\n\r\nThe only time a proxy should be created with a value other than the creating proxy's execution context is when the execution context is nil -- which is probably indicative of a bug -- in which case the page context is used just as a workaround.\r\n\r\nMarking this bug as invalid.",
					"updateAuthor": {
						"name": "blainhamon",
						"key": "blainhamon",
						"displayName": "Blain Hamon",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"created": "2012-05-03T13:38:40.000+0000",
					"updated": "2012-05-03T13:38:40.000+0000"
				},
				{
					"id": "193620",
					"author": {
						"name": "stephentramer",
						"key": "stephentramer",
						"displayName": "Stephen Tramer",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"body": "There is the following edge case:\r\n\r\nContext A has a global event listener which creates an object. Context B fires this global event. The  execution context is that of context B (or should be), but the page context is that of context A.\r\n\r\nThis may be considered a larger cross-context global vs. context group issue but there is still a problem regarding where data should reside as a result of the callback invoke because of our allowing cross-context interactions.",
					"updateAuthor": {
						"name": "stephentramer",
						"key": "stephentramer",
						"displayName": "Stephen Tramer",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"created": "2012-05-03T13:46:59.000+0000",
					"updated": "2012-05-03T13:48:04.000+0000"
				},
				{
					"id": "193662",
					"author": {
						"name": "blainhamon",
						"key": "blainhamon",
						"displayName": "Blain Hamon",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"body": "In the event of event listeners, this is actually moot. When Context B fires a global event (Via Ti.App.fireEvent), the event and its JSON payload is placed into each context's run loop. That is, Ti.App.fireEvent triggers the event listeners in the contexts to which they exist.\r\n\r\nFor a more concerete example, suppose app.js added a 'buzz' event listener to win, and foo.js added a 'buzz' event listener. This one proxy now has two event listeners associated with it. One attached to the JS object living in the app.js context, and the other attached to the JS object living in the foo.js context. When win.fireEvent('buzz',{}) is called, there is an event given to app.js and an event given to foo.js.\r\n\r\nDuring app.js' run loop, the event listener attached to the JS object living in app.js is called. The execution context is correct and all is well.\r\n\r\nDuring foo.js' run loop, the event listener attached to the JS object living in foo.js is called. The execution context is correct and all is well.\r\n\r\nI'll have to think about a cross-context function call. There may be no right answer, but using the execution context as the pageContext, despite the JS code itself associated with another context, may be the right answer simply because the execution context is also known as 'that context which owns the JS thread, and therefore the only one you can interact with in terms of creating or modifying objects.'\r\n\r\nLeaving reopened because this is a sticky wicket.",
					"updateAuthor": {
						"name": "blainhamon",
						"key": "blainhamon",
						"displayName": "Blain Hamon",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"created": "2012-05-03T16:40:29.000+0000",
					"updated": "2012-05-03T16:40:29.000+0000"
				}
			],
			"maxResults": 3,
			"total": 3,
			"startAt": 0
		}
	}
}