[TIMOB-1916] randomly xhr requests do not kill the loading indicator
| GitHub Issue | n/a |
|---|---|
| Type | Bug |
| Priority | Medium |
| Status | Closed |
| Resolution | Fixed |
| Resolution Date | 2011-04-17T01:57:32.000+0000 |
| Affected Version/s | n/a |
| Fix Version/s | Release 1.5.0 |
| Components | iOS |
| Labels | defect, ios, ipad, iphone, rplist, xhr |
| Reporter | ctredway |
| Assignee | Blain Hamon |
| Created | 2011-04-15T03:05:30.000+0000 |
| Updated | 2011-04-17T01:57:32.000+0000 |
Description
On the iphone, sdks 4.x and Ti sdk 1.4.x at random xhr requests do not kill the loading indicator when the onload event fires. Customer reproduced this using the KS xhr examples.
Hi, I have to add that on Android 2.1/Ti 1.4.2 I've had the same problem.
But I just cannot reproduce it most of the times. I think there's some problem with the events firing. I've had to replace most of my code with callback functions because of this.
This is not random in trunk as of this week. It's consistent on every HTTPClient request on iOS SDK 4.1/1.4.2. Both in simulator and on the device. I can't release an app with this, it's unprofessional to leave that spinner flying.
Able to reproduce in KS: KS->Platform->XHR->File Download->Large File Download. Ignore earlier requests for more information, sorry guys.
(from [67c9341488bf72b0f066978cc4ca860daa2ee788]) [#1916 state:fixed-in-qa] Proper return value check for stopNetwork, use OS barrier methods now to ensure order of ops. http://github.com/appcelerator/titanium_mobile/commit/67c9341488bf72b0f066978cc4ca860daa2ee788"> http://github.com/appcelerator/titanium_mobile/commit/67c9341488bf7...
Thom, assigning this to you so that you can confirm and I can patch into 1_4_X ASAP.
Using 1.5.0.62c1cae I am still seeing the spinner persist using KS->Platform->XHR->File Download->Large File Download 4.1 4th gen ipod touch
(from [ff572d3112aab7152833835e71988245a66cb6fa]) [#1916 state:fixed-in-qa] For real this time, as the in/decrements are atomic, the if statement is not. It's easier and faster to do this all on the main thread instead of locks. http://github.com/appcelerator/titanium_mobile/commit/ff572d3112aab7152833835e71988245a66cb6fa"> http://github.com/appcelerator/titanium_mobile/commit/ff572d3112aab...
Closing as per Thom. After fix, could not recreate, and the new logic should be rather robust in this.
well, in today nightly it's still broken in KS
Still an issue here from nightly build.
My comment is referring to iPhone 4 and stimulator, have not tested on iPad.
Nightly builds are done off of 1_4_X, our guaranteed stable branch. Fixes are checked into a different branch. I will put the patch into the appropriate branch and then you should be able to get an updated nightly build. If you require the latest Titanium you may always obtain it from http://github.com/appcelerator/titanium_mobile/tarball/master">http://github.com/appcelerator/titanium_mobile/tarball/master.