Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-2392] iOS: Drillbit regression: kroll.js

GitHub Issuen/a
TypeBug
PriorityHigh
StatusClosed
ResolutionWon't Fix
Resolution Date2013-11-15T20:53:52.000+0000
Affected Version/sRelease 3.0.0
Fix Version/sn/a
ComponentsiOS
LabelsSupportTeam, core, hard_to_verify, regression
ReporterStephen Tramer
AssigneeIngo Muschenetz
Created2011-04-15T03:18:29.000+0000
Updated2017-03-22T18:16:35.000+0000

Description

Test fails customObjects:53 
view.customObj = {};
view.customObj.test = "hello";
valueOf(view.customObj.test).shouldBe("hello");
Note that view.customObj = { test:"hello" } passes. Probably has to do with objects being presented as raw NSDictionary, and not translating property accessors as [setValue:forKey:].

Comments

  1. Stephen Tramer 2011-04-15

    Okay - this is super serious, and a massive overhaul. Here's the full story:

    • TiCore processes some javascript, which indicates that we have some kind of concrete value to work with. This is presented as a TiValueRef.
    • This TiValueRef is passed through to Kroll, which then copies it into an NSObject of the corresponding type, and sets that value on the KrollObject.
    • When we request this value from the KrollObject, we get back what we expect - the initial (copied) NSObject. But this is then translated into a new TiValueRef (not any corresponding existing one) which is then passed back to TiCore for javascript processing. So the object that's being modified is a copy of the value actually "attached" to the object - not the value itself.

    There are two solutions:

    • More robust lvalue detection in TiCore (was an Object involved at any point in the resolution, and if it was, re-reset the value upon completion of assignment)
    • Obj-C value wrappers for the TiCore stuff, which would allow us something similar to Apple's Toll-Free bridging between CF->NS classes.

    Going to strongly recommend the latter and push this for 1.6.0 but expect it to become a "future".

  2. Stephen Tramer 2011-04-15

    Going to assign for M05 as part of "massive meeting."

  3. Stephen Tramer 2011-04-15

    Tagging for inclusion in 1.7 since we don't have a milestone yet.

  4. Don Thorp 2011-04-15

    removing release- tag as it's for committed code. Using tbs-1.7.0 to find items we know need to go in the next release.

  5. Blain Hamon 2011-06-22

  6. Stephen Tramer 2011-07-27

    Going to strongly recommend we schedule this out of 1.8.0 as it is a significant Kroll layer change.
  7. Shawn Lipscomb 2012-01-10

  8. Blain Hamon 2012-08-27

    The issue here is that it's a 'rewrite Titanium' issue. The way Titanium on iOS works is that there's a native object (TiProxy) underlying all Titanium JS objects. The data stored in TiProxy are wildly different than JS objects, partially because NSObjects can be threadsafe, and JSCore is explicitly not threadsafe. In order to make this really happen:

    Enforce single context running at a time.

    Modify the KrollObject behavior so that the JS portion stores away adhoc properties.

    Introduce a means to indicate which properties are stored on proxy

    Modify all Titanium classes to implement this.

    Document which properties still copy-on-read and copy-on-write for safety issues (eg., Ti.UI.TableView's data and sections properties)

    (I'm probably forgetting a lot more about it)
  9. Andrey Verbin 2013-03-20

    Hi, I think this bug related to how titanium marshall objects between iOS and JS. AFAIK it just copies them, example below demonstrates that. {noformat} var array = [1,2] var view = Ti.UI.createView() view.array = array view.array[3] = 3 console.log(array) //[1,2] expecting [1,2,3] console.log(view.array) //[1,2] expecting [1,2,3] array[3] = 3 console.log(array) //[1,2,3] as it should be console.log(view.array) //[1,2] expecting [1,2,3] {noformat} You can also get stack overflow if you assign a complex JS object with cycles to proxy property due to the copying process.
  10. Ingo Muschenetz 2013-11-15

    We're not going to be addressing this particular issue for two reasons:

    Drillbit has been superseded by Anvil

    Ti.Next will take a different architecture approach not involving a Kroll layer per se.

    The value in fixing this is outweighed by the amount of effort it would take that is better spent on other areas.
  11. Lee Morris 2017-03-22

    Closing ticket as the issue will not fix and with reference to the above comments.

JSON Source