Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-1069] table view rows with scroll view crashes when simply scrolling the table view

GitHub Issuen/a
Resolution Date2011-04-17T01:55:07.000+0000
Affected Version/sn/a
Fix Version/sRelease 1.4.0
Labelsios, iphone, mobilesdk, scrollview, tableview, tableviewrow
ReporterNolan Wright
AssigneeBlain Hamon



test case attached to ticket. each row has a unique class name but for some reason our code complains that it doesn't




  1. Blain Hamon 2011-04-15

    Mail that was sent to the customer:

    It appears that, for some reason, UITableView (The underlying iPhone class) treats the strings in the ClassName as identical. I'm not sure why this is, (It might be that it stops looking at the string after a set number of characters) and I'll look into it, but in the mean time, here's a workaround:

    Remove the custom className from the tableRow's creation. When the className property is missing, Titanium actually generates a classname of its own internally (Using the memory pointer as the unique key -- which is faster than UUIDs as a bonus), and the warnings and crashes went away.

  2. Alan McConnell 2011-04-15

    Hey Blain,
    Thanks for getting back to me. I tried the workaround (eliminating the className property altogether) and I still get the "different layout than expected error" and a crash if I scroll all the way to the bottom and all the way back to the top in the app.js I attached to my ticket (I've attached it here as well). I also tried manually specifying a short, unique className and still got this behavior in the attach app.js.

    It's strange, I believe I've only seen this behavior when a ScrollView is present in a table row, but with it in there className seems to be totally ignored.

    2010-06-02 20:38:42.504 TableViewTest[603:207] Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: ' -[UIScrollView transferProxy:]: unrecognized selector sent to instance 0x5333fd0'

  3. Alan McConnell 2011-04-15

    Meant to attach the app.js file.

  4. Blain Hamon 2011-04-15

    Okay, I did a regression test. App.js crashes in 1.3, and does fine in HEAD. The difference being the fix/test for un-named classes happened some time since then. (I need to write these things down)

    A few solutions: 1) Either pull from HEAD and build a fresh post-1.3 build of Titanium, or 2) have Nolan provide you with same.

    Another workaround would be that the identifier doesn't need to be wholly unique, just unique within that table view. So if you were to simply have the row number (With no preceeding common text) as the className, or a counter if you intend to modify rows later on, that should be sufficient for unique rows.

  5. Jeff Haynie 2011-04-15

    (from [97825f3c1179e136a01e83741bbc0614f3b372fd]) Closes #1069 , with debugging cleaned up: TableViewRows were looking at the TiUIView's subviews, instead of the views of their proxy's children. Most times, this is okay. But things get very confused very quickly with scrollable/scrolling views. http://github.com/appcelerator/titanium_mobile/commit/97825f3c1179e136a01e83741bbc0614f3b372fd"> http://github.com/appcelerator/titanium_mobile/commit/97825f3c1179e...

JSON Source