GitHub Issue | n/a |
Type | Bug |
Priority | High |
Status | Closed |
Resolution | Fixed |
Resolution Date | 2013-10-15T21:12:53.000+0000 |
Affected Version/s | Release 3.1.0 |
Fix Version/s | 2013 Sprint 21, 2013 Sprint 21 API, Release 3.2.0 |
Components | iOS |
Labels | module_textarea, qe-testadded, textarea, triage |
Reporter | Mitchell Amihod |
Assignee | Vishal Duggal |
Created | 2013-05-23T15:43:59.000+0000 |
Updated | 2014-06-19T12:42:44.000+0000 |
Calling setSelection always throws this error - within context of supplied app.js. (and in my app)
void _WebThreadLockFromAnyThread(bool), 0xa8206d0: Obtaining the web lock from a thread other than the main thread or the web thread. UIKit should not be called from a secondary thread.
Please see the app.js as it now consistently reproduces this error.
It would be useful if you could create a test case regardless of whether it crashes or not for us to test in the meantime. Are you running it on a device or the simulator? Reading related issues gave me the impression it was a simulator problem.
Hey Daniel, yeah, its on the simulator. Haven't tried it on device yet. I'll work on making a test case which matches closer my use in app.
Hey Daniel. Good news! I've managed to do a simple repro of the bug :) I've attached it to the ticket. Let me know if I can offer any more info.
More details: It is happening on device. I ran my app on device (ipad mini), seeing the same error w/ crash: nirvanaipad[38597:3e03] void _WebThreadLockFromAnyThread(bool), 0x1f510550: Obtaining the web lock from a thread other than the main thread or the web thread. UIKit should not be called from a secondary thread. I'm including a on this ticket.
bump. now that there's a repo, any chance of moving this to a TI-MOB?
We are going to fix this in our custom Ti SDK. If it helps: there are at least 2 bugs in the iOS implementation of Ti.UI.TextField.setSelection(). One is the immediate cause of the _WebThreadLockFromAnyThread error message: the setSelection() code in the proxy grabs the UITextField directly (not on main thread) and tries to sanity-check using its length property. Even if this problem is fixed (say, by moving that sanity checking directly into non-proxy code), setSelection() will still not work, because setSelectionFrom () then calls becomeFirstReponder on self, instead of on [self textWidgetView]. Currently we have no time to issue pull request, but perhaps the above will help. P.S. Above comment probably applies equally to TextArea.
I would like to humbly point out again that TextArea.setSelection() and TextField.setSelection() in no way work in iOS at this moment (unless this has been stealthily fixed in 3.1.2 or 3.1.3, in which case this ticket should be resolved). This is not just some crash in some particular hardware combination. Based on the code, it's a straight-up regression.
Pull pending against master https://github.com/appcelerator/titanium_mobile/pull/4790
TextArea.setSelection works fine and app does not crash. Verified fix on: Device : iPad 4, iOS version: 6 SDK: 3.2.0.v20131016191202 CLI version : 3.2.0 OS : MAC OSX 10.8.4 Alloy : 1.2.2 Appcelerator Studio, build: 3.2.0.201310112258 XCode : 5