plugin not in registry search (org.chromium.identity) but it's there
Go to http://plugins.cordova.io/ Search for identity Get 2 results: com.blackberry.identityBlackBerry 10 Identity APIs com.blackberry.user.identityBlackBerry 10 User Identity APIs Search for org.chromium.identity Get 1 result: org.chromium.identityThis plugin provides OAuth2 authentication for Android and iOS. How do it work? ;0
Re: Rendering Performance Measurement for Cordova
Totally exciting, can't wait to give it a whirl! On Thu, Feb 27, 2014 at 10:14 AM, Brian LeRoux b...@brian.io wrote: This is really cool stuff man. Will be taking a closer look for sure. On Wed, Feb 26, 2014 at 1:28 PM, Parashuram n.parashu...@gmail.com wrote: Hi, I am working on a Front End Rendering performance measurement tool that can be integrated into a continuous integration systems to generate graphs like this http://nparashuram.com/bootstrap-perf and this http://bench.topcoat.io. This tool started off being based on Chromium telemetry for Topcoat.io but now allows running any Selenium like test cases and records timeline events like paint, Layout, frame times, etc. This currently works on Android 4.4 Cordova apps and Hybrid apps and is available here https://github.com/axemclion/maddie in the dev branch. Would love to hear any feedback that folks have. If you also have a Cordova app on Android app and would like to try this out, I would be glad to help out. Parashuram http://nparashuram.com
Re: Camera does too many things!!!!
+1 for nuking data uris On Fri, Jan 24, 2014 at 11:36 AM, Don Coleman don.cole...@gmail.com wrote: I like the Camera API because it's simple. Capture might be standard but it seems too complex. Resizing and orientation are important features. I never use data URLs. What's going on in the standards bodies around image capture? Is there an emerging standard that we could scope down to, or is nothing emerging and we get to make it up in the meantime? I do like the simplicity of the camera plugin (roughly) just doing capture, and pushing the utilities into a separate plugin (perhaps even non-core). I hear that picture capture and uploading is a common pattern, so we should consider the migration impact to existing users. On Jan 24, 2014, at 8:47 AM, Mike Billau mike.bil...@gmail.com wrote: How does this coincide with the recent thread about Camera vs Capture? Yeah, seems like these are part of the same big picture that should be thought through simultaneously.
Re: [Android] Deprecation of Geolocation on Android
+1 to nuking it. Anyone depending on it for really old versions of Android is likely not doing anyone a favor (themselves or their users) - and (I think) it adds to new developer confusion. Then again, having a plugin that only adds the permission bit sort of does that too. On Fri, Jan 10, 2014 at 7:26 PM, Michal Mocny mmo...@chromium.org wrote: Adding support for play services based geolocation could come as a value add later. If the current implementation is broken and no one wants to work on it (seems to be the case since it hasn't been fixed yet), then Joe's suggestion to just drop it now and leave a no-op plugin that adds permission only sounds like the right thing short term. Joes first email claims Web Geolocation supports all current versions of android (http://caniuse.com/geolocation claims android 2.1+ though I didn't look in to possible quirks). -Michal On Fri, Jan 10, 2014 at 8:43 PM, Andrew Grieve agri...@chromium.org wrote: Is the plugin still needed on older android versions? e.g. we might want to have it be a no-op based on the android version instead of deleting it? Android geolocation seems to have gone Play Services, so another option would be to make the plugin use that instead of the OS geolocation in order to provide some utility. On Fri, Jan 10, 2014 at 4:14 PM, Jesse purplecabb...@gmail.com wrote: The index.html issue was iOS, not sure if it still exists. Windows Phone 7+8 use the browser based geolocation as they have implemented the spec, However because of the way permissions are managed, there is a native do-nothing stub that simply signal that Location Services are required. Windows8 does some massaging of the api to the WinJS version, and adds the permissions to the project. I just spoke ( physically ) with Joe, and with this change, the geolocation plugin would still exist for Android, it would just add the permission to the app. So, Android's plugin would be almost identical to WP7+8 with this change. +1 from me, assuming everything will just work. @purplecabbage risingj.com On Fri, Jan 10, 2014 at 3:40 PM, Joe Bowser bows...@gmail.com wrote: It never did on Android, you can see this in Mobile-Spec. On Fri, Jan 10, 2014 at 3:39 PM, Brian LeRoux b...@brian.io wrote: Does the permission dialogue still ask for index.html ? On Friday, January 10, 2014, Joe Bowser wrote: Due to numerous issues found in Geolocation, combined with an increase in reliability of the Web Geolocation, I'm wanting to see us EOL the Geolocation plugin. Reasons for this include: * Support for Geolocation on all currently supported versions of Android * Numerous issues with the current Geolocation plugin that may involve a full re-write of the Geolocation plugins. * The Web Geolocation may be more energy efficient than our own Geolocation polling. What do people think about deprecating this plugin and recommending that we use the browser's implementation on Android? Joe
Re: Extending CordovaWebView
I was wondering how this is progressing.. (maybe there's already a mechanism for this via config.xml?) I ask because, in the CLI world, I'm not sure how to update webview settings for android, in particular because I'd like to make the changes mentioned here: http://tmkmobile.wordpress.com/2012/03/04/html5-offline-solution/ super.appView.getSettings().setDomStorageEnabled(true); super.appView.getSettings().setAppCacheMaxSize(1024*1024*8); super.appView.getSettings().setAppCachePath(/data/data/com.yourdomain/cache); super.appView.getSettings().setAllowFileAccess(true); super.appView.getSettings().setAppCacheEnabled(true); super.appView.getSettings().setCacheMode(WebSettings.LOAD_DEFAULT); On Tue, Aug 27, 2013 at 7:45 AM, Ian Clelland iclell...@chromium.orgwrote: Issues CB-4671 and CB-4678 added to JIRA for this. If I have time this week, I'll take a stab at implementing them. On Fri, Aug 23, 2013 at 12:30 PM, Ally Ogilvie aogil...@wizcorp.jp wrote: Hell. Yes. Plus all the things you just wrote +1 Sharing is caring... Is why i want accessibility in plugins for maximum awesomeness. Sent from my Windows Phone From: Ian Clelland Sent: 23/08/2013 23:41 To: dev@cordova.apache.org Subject: Re: Extending CordovaWebView On Thu, Aug 22, 2013 at 8:43 PM, Ally Ogilvie aogil...@wizcorp.jp wrote: First is that there is no way to use a custom WebView / WebViewClient / ChromeClient class within the CLI system, without writing custom native code after your project has been created. Not sure about the CLI system, don't really use it. Call me old school but I love my jars 'n frameworks. There is of course another reason for this; Cordova is very much a framework for me, NOT a platform. I think it's crucial to remember there are many reasons to use Cordova in a project, it can often be just as a means to get a little extra accessibility and browser standardisation out of the WebView. The rest of the app could be 80% native with heaps of other SDKs... That is absolutely a valid use of Cordova, and underscores the point that the tools which underlie CLI should be even more stable than CLI itself. (Which I think is true right now) If you're using Cordova in that way, then most of this discussion wouldn't even apply -- your start-of-project flow can just be cordova-android/bin/create newproject com.example.newproject, and then you can start editing (or just throw away) the default Activity class. Nothing here is going to get in the way of that. For Mobile Chrome Apps, we have a need to subclass the CordovaChromeClient class used by our applications. There's not currently a way to do that in the CLI world Ian, I know you are using CLI, but IF you were not, you would subclass CordovaChromeClient on your application's main Activity?? I see no sensible way to do it on a Plugin without going thread crazy... I can separate a thread if you want to keep this CLI related, but I feel the plugin developer use case should be considered in this thread too. The only reason I can imagine for me not to use CLI would be if I was creating a single-platform application, for which I knew that I was going to be making a lot of native code modifications. In that case, I would absolutely introduce my own subclass of CordovaChromeClient, and import it in my main Activity, and override init() to create the right objects. But that only works for my application; it doesn't give me anything that I can share with other developers without also instructing them to modify their code in the same way. There's no way right now to encapsulate this sort of change in a plugin. The CordovaWebView/Client/ChromeClient are necessarily singletons, and it's probably not a good idea to allow plugins to arbitrarily replace them. We could conceivably come up with a new sort of plugin that can do it -- and you could only install one such plugin per project -- but people could also just distribute custom app templates which do pretty much the same thing. I'm 100% hopeful that at a minimum more methods (WebView and WebViewCient) can be exposed to the Plugins. For individual methods, right now lets just name them specifically, and we can add delegation to the plugins for them. Later, I think we can move to a generic registration / notification architecture, once we have a good design for that. I've heard calls for: - disableTouchEvents - registerGestureHandler - onReceivedHttpAuthRequest - getHttpAuthUsernamePassword We can create some issues for those, and get them implemented. Ian
Seeking a partner for a SXSW 2014 workshop on Cordova (Sat, March 8)
Hey fellow Cordova devs, I'm wondering if anyone might want to partner with me to do a Cordova workshop at SXSW 2014 http://sxsw.com/interactive. I made a proposal that has been accepted for a 2.5hr talk for Sat. March 8th, and my plan is to do a walkthrough of taking a relatively simple website and showing how to convert it to a Cordova app while highlighting some gotchas and cool things along the way. If you're interested, please email me off-list before December 8th. I suspect I can add up to 2 other speakers onto this workshop. You'll receive a complimentary Gold access pass to SXSW as a speaker, but your flight/hotel/etc will be something you'd need to figure out. As far as the time commitment goes I think I'll likely do the bulk of the prep-work, but I'd love to have someone who's willing to spend some time on it as well in advance and get together beforehand for a few hours in Austin to really talk it through on Friday or Saturday. I'm hoping that some of the audience will actually participate along the way with a computer and so having someone else to walk around and help folks out in addition to myself will be helpful. Also - just a heads up that SXSW can be a big, unruly conference and this format, the 2.5hr workshop, is something kind of new and experimental, so I'm hoping to end up with some useful tutorial materials to post online as well after the fact to make the most of the effort. -l
Re: Seeking a partner for a SXSW 2014 workshop on Cordova (Sat, March 8)
Hey Gord, Sounds awesome! I've also heard from Lorin Beer that he'd like to come along too. I just sent an email to my contact at SXSW to see how best to proceed with getting them your info, etc.. On Mon, Dec 2, 2013 at 10:02 AM, Gord Tanner gtan...@gmail.com wrote: Hey, I can help out if you want. Here is a talk I have given in the past on Cordova: http://www.youtube.com/watch?v=ZsDPnxBfybo Gord On Mon, Dec 2, 2013 at 12:47 PM, Lindsey Simon els...@gmail.com wrote: Hey fellow Cordova devs, I'm wondering if anyone might want to partner with me to do a Cordova workshop at SXSW 2014 http://sxsw.com/interactive. I made a proposal that has been accepted for a 2.5hr talk for Sat. March 8th, and my plan is to do a walkthrough of taking a relatively simple website and showing how to convert it to a Cordova app while highlighting some gotchas and cool things along the way. If you're interested, please email me off-list before December 8th. I suspect I can add up to 2 other speakers onto this workshop. You'll receive a complimentary Gold access pass to SXSW as a speaker, but your flight/hotel/etc will be something you'd need to figure out. As far as the time commitment goes I think I'll likely do the bulk of the prep-work, but I'd love to have someone who's willing to spend some time on it as well in advance and get together beforehand for a few hours in Austin to really talk it through on Friday or Saturday. I'm hoping that some of the audience will actually participate along the way with a computer and so having someone else to walk around and help folks out in addition to myself will be helpful. Also - just a heads up that SXSW can be a big, unruly conference and this format, the 2.5hr workshop, is something kind of new and experimental, so I'm hoping to end up with some useful tutorial materials to post online as well after the fact to make the most of the effort. -l
Re: cordova-plugins repo release
It seems like a shared repo is just a recipe for the troubles of the last shared repo. On Mon, Nov 25, 2013 at 1:17 PM, Jesse purplecabb...@gmail.com wrote: All of this is fine. I also see no reason why you cannot hack in your own repo, just ensure you start with the right license. Nothing says that the apache git has to be the origin of code. @purplecabbage risingj.com On Mon, Nov 25, 2013 at 1:01 PM, Anis KADRI anis.ka...@gmail.com wrote: It sounds like we all agree. Start hacking on cordova-plugins and if/when it's mature move it to its own repository. Publishig from cordova-plugins should not be an issue. On Mon, Nov 25, 2013 at 11:52 AM, Braden Shepherdson bra...@chromium.org wrote: I'm not sure if I was clear: I am content with the current repo setup and argue for keeping it as it is. The main core plugins are in their own repos and I support that. On the other hand I support having the cordova-plugins repo as an incubator for experimental projects that either die or graduate to having real repos. Braden On Mon, Nov 25, 2013 at 2:44 PM, Michal Mocny mmo...@chromium.org wrote: Okay -- while I do agree with Braden -- in the interests of not debating again, I'll concede to not publishing core plugins from a shared repo (if for no other reason than for consistency with the other core plugins). But I think its still worth having a cordova-plugins repo for early experiments/incubation period so you don't have to file a ticket with INFRA before you even get started. Seems the two published plugins are keyboard and statusbar, so we should get INFRA tickets to make repos for those? -Michal On Mon, Nov 25, 2013 at 10:47 AM, Brian LeRoux b...@brian.io wrote: Super disagree about putting src into a single big repo. I get why we do that. I do not buy that we 'have too many repos' or that complexity is minimized by combining. Anyhow: not a discussion I think is even worth us having AGAIN. =/ On Mon, Nov 25, 2013 at 10:32 AM, Braden Shepherdson bra...@chromium.org wrote: Hang on a second: The release you send to the plugman registry doesn't care about git. You point it at a (sub)directory and it uploads the plugin. The version is set by the plugin.xml of that plugin. If we want tags for when those plugins were pushed to npm, what's wrong with tags like whateverplugin-1.0.0? It's a little cluttered to see all the tags for all the plugins, but you can still see all the releases of a given plugin. They're in this repo precisely because they're small or experimental and not ready for their own repos yet. -10 to one repo per plugin; we have way too many repos already, and this cordova-plugins repo is intended to be the catchall place for small and experimental plugins. Braden On Mon, Nov 25, 2013 at 11:05 AM, Michal Mocny mmo...@chromium.org wrote: Would that only be true if you shared readable tag names between plugins? If we used tags unique to each plugin, perhaps by prefixing tags with the target plugins' name, then plugin releases would be isolated, right? -Michal On Fri, Nov 22, 2013 at 8:02 PM, Jesse purplecabb...@gmail.com wrote: The issue that if use a tag to signify the new version, then the tag is applied to all plugins in the repo. This is probably not a big deal for minor bumps, but when a plugin needs a major bump, they all will. So you will/could have a plugin with a major version bump even though the code has not changed. @purplecabbage risingj.com On Fri, Nov 22, 2013 at 6:36 PM, Michal Mocny mmo...@chromium.org wrote: I don't understand, whats the problem? I thought you publish plugins by git-repo subdir hash -- so multiple plugins makes no difference. The master dev branch deal was to do with cordova-3.0 users that did not support plugin repo install from !master branch, right? But none of these plugins in cordova-plugins existed back then, so we just set engine requirement to 3.1? -Michal On Fri, Nov 22, 2013 at 1:32 PM, Steven Gill stevengil...@gmail.com wrote: +1 on one plugin per repo. Would making releasing and tagging much simpler. On Fri, Nov 22, 2013 at 1:29 PM, Carlos Santana csantan...@gmail.com wrote: Yep that's the problem with having independent plugins in a single repo,
Re: Cordova Debug Mode
On Thu, Nov 21, 2013 at 11:37 AM, Ian Clelland iclell...@chromium.orgwrote: David and I were talking about this this morning, and since Joe brought it up as well, we should probably get the list involved. I think that there is some value in having Debug and Release builds of Cordova projects. I don't know if the platforms have any way to do this already, but it seems like there are a lot of behaviours that are incredibly useful for testing and development, which shouldn't ever be enabled in released applications. Off the top of my head: * All of our Console / ADB / NSLog Logging If you disable logging by default, make it a preference somewhere. Because I always wanted console/Java logging in production Android apps to capture wtf was going on for my users all the time. * Enabling the remote debugger in Android 4.4+ * (maybe) disabling the network whitelist I'm sure there are others -- we have a plugin for chrome.alarm that is *supposed* to have a 1-minute minimum timeout, but I'd love to be able to make that 1/4s in debug mode only. Would it make sense to have a build flag for this? cordova build --debug, cordova build --release; something like that (bikeshed colours welcome). I don't think that config.xml is the place for it; it seems like it should be lower than that, but I'm not exactly sure how it should be set. There will probably need to be platform-specific implementations, but it would be good to have a cross-platform way of turning it on and off. Thoughts? Ian
Re: Cordova Debug Mode
On Thu, Nov 21, 2013 at 12:58 PM, Ian Clelland iclell...@chromium.orgwrote: On Thu, Nov 21, 2013 at 3:22 PM, Lindsey Simon lsi...@commoner.com wrote: On Thu, Nov 21, 2013 at 11:37 AM, Ian Clelland iclell...@chromium.org wrote: David and I were talking about this this morning, and since Joe brought it up as well, we should probably get the list involved. I think that there is some value in having Debug and Release builds of Cordova projects. I don't know if the platforms have any way to do this already, but it seems like there are a lot of behaviours that are incredibly useful for testing and development, which shouldn't ever be enabled in released applications. Off the top of my head: * All of our Console / ADB / NSLog Logging If you disable logging by default, make it a preference somewhere. Because I always wanted console/Java logging in production Android apps to capture wtf was going on for my users all the time. Do you mean console.log() statements from application code? Those should definitely be allowed, and if you have the console plugin installed, then they can go to the device's log. I meant that we could shut up all of the logging that goes on inside Cordova and inside our plugins. If *those* messages are still useful in production apps, then we should clean them up a bit :) Ah, no worries then - you mean internal logging ;) Carry on.
Re: config.xml discussion, we need to talk
On Thu, Sep 26, 2013 at 8:32 AM, Carlos Santana csantan...@gmail.comwrote: Branden, On Android, it's really easy to load XML files from res/xml/foo.xml, so that's where we put it. Easy for who? I think is difficult for web developer to not find it in www/config.xml and start searching for it I don't know much about Android so maybe I'm putting my foot in my mouth because it's too complex to read the file from www/ When you say www are you referring to project/www or project/platform/android/assets/www? --Carlos On Thursday, September 26, 2013, Braden Shepherdson wrote: I am strongly opposed to splitting into one file per platform. We want to support platform tags in config.xml, which will allow platform-specific content within the single config.xml. There are good reasons why the CLI moves the config.xml on some platforms. On Android, it's really easy to load XML files from res/xml/foo.xml, so that's where we put it. We should be deleting the platforms/android/assets/www/config.xml though, since it's an unused duplicate and confusing. Braden On Wed, Sep 25, 2013 at 4:59 PM, Carlos Santana csantan...@gmail.com javascript:; wrote: I was not trying to be purist with the w3c www/config.xml I just want to see some consistency across all platforms for configuration settings for a Cordova App. The same way I have a single index.html, app.css and app.js. I want see one config.xml for all platforms inside www/ or many config.xml per platform config.ios.xml, config.android.xml, etc... But as a web developer I'm excepting all the files that I need to modify inside www/ using CLI or not Even if I have to run something like ./bin/processconfig.sh to propagate changes from the /www/config.xml As web developer I might update the config.xml once for every 100 edits to my app web files (HTML, JS, CSS) TLDR: consistency wins over correctness PS: what is the phonegap team doing? I think you tell users to edit one config.xml for the web app and pgbuild takes care of the rest -- Carlos On Wednesday, September 25, 2013, Braden Shepherdson wrote: I'm in favour of CLI (platform parsers, probably) deleting this www/config.xml that they don't use. It's a waste of space and has confused people in the past. It even confused the iOS prepare code and caused that odd my project doesn't work if it starts with x, y or z bug (because xFactor/config.xml sorts after www/config.xml, and it was blindly taking the first one). Braden On Wed, Sep 25, 2013 at 4:22 PM, Bryan Higgins bhigg...@blackberry.com javascript:; javascript:; wrote: Thanks for the clarification. BlackBerry happened to luck out because we expect config.xml in www. Perhaps copying of config.xml should become a responsibility of the platform parsers. I can understand moving config.xml to root or cordova for the reason stated in the JIRA, but my vote would be to keep it config.xml rather than app.xml. On Wed, Sep 25, 2013 at 3:55 PM, Jesse purplecabb...@gmail.com wrote: I am not saying deviate, I am saying, what is it supposed to be? If you look at the various platforms you will see it is all over the map. Looking at Android code, and talking to Joe, the only location that the config.xml file is loaded from is in res/xml, and the fact that cordova-cli creates another one sitting in the www folder is just irrelevant sloppiness. It may make sense for the config.xml file to sit in the root/www folder of the CLI project, but in reality at runtime, it's location will vary by platform. @purplecabbage risingj.com On Wed, Sep 25, 2013 at 12:29 PM, Bryan Higgins bhigg...@blackberry.com wrote: www/config.xml aligns nicely with the w3c widget spec [1]. Why would we want to deviate? [1] http://www.w3.org/TR/widgets/#reserved-file-and-folder-names On Wed, Sep 25, 2013 at 3:23 PM, Jesse purplecabb...@gmail.com wrote: Seems any project created with the CLI has a config.xml in the www folder. [1] Why do we have 2 of these? I also recently closed a defect created by Carlos, stating that WP8 did NOT have it's config.xml in the www folder. [2] Now I am not sure I should have called this invalid, however, after creating a new WP8 project with the CLI, I see a config.xml in the www folder AND one in the app root. wtf? There is an open issue [3] to re-org config files, where Braden states We already have plans to move
Re: phonegap build doesn't preserve symlink paths
Ok cool thanks fellas - I didn't know if this was a bug or if maybe I was just doing it wrong.. On Mon, Sep 16, 2013 at 12:03 PM, Andrew Grieve agri...@chromium.orgwrote: Bug filed: https://issues.apache.org/jira/browse/CB-4828 Thanks Lindsey. On Mon, Sep 16, 2013 at 2:17 PM, Shazron shaz...@gmail.com wrote: Lindsey, always file an issue. Thanks :) On Mon, Sep 16, 2013 at 10:26 AM, Lindsey Simon els...@gmail.com wrote: In my project/www I symlink my js/css/img directories to another directory in my tree (where my server deploys from). When I run `phonegap build android` the symlinks get copied to platforms/android/assets/www/css but the path is no longer valid. Anyone else experience this? Should I file a bug? (and attempt a CL?) Thanks
phonegap build doesn't preserve symlink paths
In my project/www I symlink my js/css/img directories to another directory in my tree (where my server deploys from). When I run `phonegap build android` the symlinks get copied to platforms/android/assets/www/css but the path is no longer valid. Anyone else experience this? Should I file a bug? (and attempt a CL?) Thanks
Re: phonegap build doesn't preserve symlink paths
On Mon, Sep 16, 2013 at 1:09 PM, Michal Mocny mmo...@chromium.org wrote: Creating symlinks to absolute paths might be sufficient to fix your issue right now. Good idea, that totally worked for now. On Mon, Sep 16, 2013 at 12:44 PM, Lindsey Simon lsi...@commoner.com wrote: Ok cool thanks fellas - I didn't know if this was a bug or if maybe I was just doing it wrong.. On Mon, Sep 16, 2013 at 12:03 PM, Andrew Grieve agri...@chromium.org wrote: Bug filed: https://issues.apache.org/jira/browse/CB-4828 Thanks Lindsey. On Mon, Sep 16, 2013 at 2:17 PM, Shazron shaz...@gmail.com wrote: Lindsey, always file an issue. Thanks :) On Mon, Sep 16, 2013 at 10:26 AM, Lindsey Simon els...@gmail.com wrote: In my project/www I symlink my js/css/img directories to another directory in my tree (where my server deploys from). When I run `phonegap build android` the symlinks get copied to platforms/android/assets/www/css but the path is no longer valid. Anyone else experience this? Should I file a bug? (and attempt a CL?) Thanks
[jira] [Commented] (CB-1185) When Application is placed in background and resumed, the UI is frozen
[ https://issues.apache.org/jira/browse/CB-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13545292#comment-13545292 ] Lindsey Simon commented on CB-1185: --- For some closure on this - I think what fixed it for us was some handing of pause/resume with on short timeouts and with canceling on one or the other to deal with pause and resume being called nearly back to back and perhaps twice really close together when we would come up. Especially happens when we'd resume from a notification intent. When Application is placed in background and resumed, the UI is frozen -- Key: CB-1185 URL: https://issues.apache.org/jira/browse/CB-1185 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 2.0.0 Environment: Jelly Bean 4.1, ICS 4.0.x Reporter: Greg Assignee: Joe Bowser Attachments: 0001-Fix-issue-with-pause-resume-freezing-the-UI.patch, 0002-Uncomment.patch, cordova-2.0.0.jar, issues.zip When using PhoneGap 2.0.0 on ICS or JellyBean, the application freezes up after you set the app to the background or turn of the screen. After around 3-7 seconds, the application unfreezes and pretty much causes a panic and usually crashes. No error reports have been submitted. Here is how you re-produce the issue: 1. Download Untappd - V2.0.4(https://play.google.com/store/apps/details?id=com.untappdllc.app) 2. After logging in stay on the Friends tab 3. Turn the the screen off and wait about 3-7 minutes 4. Turn the screen back on, and the interface should be frozen. Another possible path to re-producing the issue: 1. Download Untappd - V2.0.4(https://play.google.com/store/apps/details?id=com.untappdllc.app) 2. After logging in stay on the Friends tab 3. Go back to the home screen then use other apps for about 3-7 minutes. 4. Go back into Untappd, and the interface should be frozen. When the app is frozen, native menu buttons will not nor any options in the UI. Would love to see if anyone can replicate this. I've tested this on Jelly Bean 4.1.x on a Samsung Galaxy Nexus, but users have been having this problem majority on ICS (4.0.x) Thanks, Greg -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-1185) When Application is placed in background and resumed, the UI is frozen
[ https://issues.apache.org/jira/browse/CB-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13497593#comment-13497593 ] Lindsey Simon commented on CB-1185: --- [~gregavola] Since you do have an easy to repro situation for some magical reason, can you try adding this to the Activity to see if it makes any difference? I started wondering if it wasn't a cache/memory issue. @Override public void onResume() { this.appView.clearCache(false); this.appView.destroyDrawingCache(); super.onResume(); } When Application is placed in background and resumed, the UI is frozen -- Key: CB-1185 URL: https://issues.apache.org/jira/browse/CB-1185 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 2.0.0 Environment: Jelly Bean 4.1, ICS 4.0.x Reporter: Greg Assignee: Joe Bowser Attachments: 0001-Fix-issue-with-pause-resume-freezing-the-UI.patch, 0002-Uncomment.patch, cordova-2.0.0.jar, issues.zip When using PhoneGap 2.0.0 on ICS or JellyBean, the application freezes up after you set the app to the background or turn of the screen. After around 3-7 seconds, the application unfreezes and pretty much causes a panic and usually crashes. No error reports have been submitted. Here is how you re-produce the issue: 1. Download Untappd - V2.0.4(https://play.google.com/store/apps/details?id=com.untappdllc.app) 2. After logging in stay on the Friends tab 3. Turn the the screen off and wait about 3-7 minutes 4. Turn the screen back on, and the interface should be frozen. Another possible path to re-producing the issue: 1. Download Untappd - V2.0.4(https://play.google.com/store/apps/details?id=com.untappdllc.app) 2. After logging in stay on the Friends tab 3. Go back to the home screen then use other apps for about 3-7 minutes. 4. Go back into Untappd, and the interface should be frozen. When the app is frozen, native menu buttons will not nor any options in the UI. Would love to see if anyone can replicate this. I've tested this on Jelly Bean 4.1.x on a Samsung Galaxy Nexus, but users have been having this problem majority on ICS (4.0.x) Thanks, Greg -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-1185) When Application is placed in background and resumed, the UI is frozen
[ https://issues.apache.org/jira/browse/CB-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13496336#comment-13496336 ] Lindsey Simon commented on CB-1185: --- So my simple app test-case didn't reproduce the bug last night. I'll put up a link to a github clone with my changes shortly.. but, in the meantime - @Untappd = what's your high-level main components/lib setup? For Twist it's: - Zepto - Underscore/Backbone - Hogan templates - GPS watchPosition / stopWatchPosition action - Bing Maps When Application is placed in background and resumed, the UI is frozen -- Key: CB-1185 URL: https://issues.apache.org/jira/browse/CB-1185 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 2.0.0 Environment: Jelly Bean 4.1, ICS 4.0.x Reporter: Greg Assignee: Filip Maj Attachments: 0001-Fix-issue-with-pause-resume-freezing-the-UI.patch, 0002-Uncomment.patch, cordova-2.0.0.jar, issues.zip When using PhoneGap 2.0.0 on ICS or JellyBean, the application freezes up after you set the app to the background or turn of the screen. After around 3-7 seconds, the application unfreezes and pretty much causes a panic and usually crashes. No error reports have been submitted. Here is how you re-produce the issue: 1. Download Untappd - V2.0.4(https://play.google.com/store/apps/details?id=com.untappdllc.app) 2. After logging in stay on the Friends tab 3. Turn the the screen off and wait about 3-7 minutes 4. Turn the screen back on, and the interface should be frozen. Another possible path to re-producing the issue: 1. Download Untappd - V2.0.4(https://play.google.com/store/apps/details?id=com.untappdllc.app) 2. After logging in stay on the Friends tab 3. Go back to the home screen then use other apps for about 3-7 minutes. 4. Go back into Untappd, and the interface should be frozen. When the app is frozen, native menu buttons will not nor any options in the UI. Would love to see if anyone can replicate this. I've tested this on Jelly Bean 4.1.x on a Samsung Galaxy Nexus, but users have been having this problem majority on ICS (4.0.x) Thanks, Greg -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-1185) When Application is placed in background and resumed, the UI is frozen
[ https://issues.apache.org/jira/browse/CB-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13496417#comment-13496417 ] Lindsey Simon commented on CB-1185: --- Ok, here's a link to a repo for perusal, and in particular the JS file: https://github.com/elsigh/cordova-android-anr/blob/master/assets/www/js/index.js I tried with this running just turning off the data and wifi and the app continue to run for about 30 minutes no problem, it would just get the error for the fetch and then the timeout fired and another would go off. So I don't know that it's just that. It's unfortunately some combo of moving parts. Ugh. Things I've not tried yet but want to: * Sending multiple XHRs at once and looping/re-fetching once they're all complete. * Including battery listeners * Using backbone in this equation. Also - @Untappd folks - do you guys use Urban Airship for push? I wonder if it's relevant. thanks When Application is placed in background and resumed, the UI is frozen -- Key: CB-1185 URL: https://issues.apache.org/jira/browse/CB-1185 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 2.0.0 Environment: Jelly Bean 4.1, ICS 4.0.x Reporter: Greg Assignee: Filip Maj Attachments: 0001-Fix-issue-with-pause-resume-freezing-the-UI.patch, 0002-Uncomment.patch, cordova-2.0.0.jar, issues.zip When using PhoneGap 2.0.0 on ICS or JellyBean, the application freezes up after you set the app to the background or turn of the screen. After around 3-7 seconds, the application unfreezes and pretty much causes a panic and usually crashes. No error reports have been submitted. Here is how you re-produce the issue: 1. Download Untappd - V2.0.4(https://play.google.com/store/apps/details?id=com.untappdllc.app) 2. After logging in stay on the Friends tab 3. Turn the the screen off and wait about 3-7 minutes 4. Turn the screen back on, and the interface should be frozen. Another possible path to re-producing the issue: 1. Download Untappd - V2.0.4(https://play.google.com/store/apps/details?id=com.untappdllc.app) 2. After logging in stay on the Friends tab 3. Go back to the home screen then use other apps for about 3-7 minutes. 4. Go back into Untappd, and the interface should be frozen. When the app is frozen, native menu buttons will not nor any options in the UI. Would love to see if anyone can replicate this. I've tested this on Jelly Bean 4.1.x on a Samsung Galaxy Nexus, but users have been having this problem majority on ICS (4.0.x) Thanks, Greg -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-1185) When Application is placed in background and resumed, the UI is frozen
[ https://issues.apache.org/jira/browse/CB-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13496482#comment-13496482 ] Lindsey Simon commented on CB-1185: --- One more bit... I went looking back at a prior crash log and see: 11-02 16:56:21.803 D/STATUSBAR-BatteryController( 779): onReceive() - ACTION_BATTERY_CHANGED 11-02 16:56:21.803 D/STATUSBAR-BatteryController( 779): onReceive() - level:99 11-02 16:56:21.803 D/STATUSBAR-BatteryController( 779): onReceive() - plugged:0 11-02 16:56:21.803 D/STATUSBAR-BatteryController( 779): onReceive() - BATTERY_STATUS_DISCHARGING: stat_sys_battery 11-02 16:56:21.833 D/dalvikvm( 2234): GC_CONCURRENT freed 1779K, 27% free 14122K/19107K, paused 8ms+3ms 11-02 16:56:21.983 D/Zygote ( 333): Process 15854 terminated by signal (11) 11-02 16:56:21.993 W/InputDispatcher( 643): channel ~ Consumer closed input channel or an error occurred. events=0x8 11-02 16:56:21.993 E/InputDispatcher( 643): channel ~ Channel is unrecoverably broken and will be disposed! 11-02 16:56:21.993 W/InputDispatcher( 643): Attempted to unregister already unregistered input channel 11-02 16:56:21.993 I/WindowManager( 643): WINDOW DIED Window{4210e748 XXX.X.XXX/XXX.X.XXX.XX paused=false} 11-02 16:56:21.993 I/ActivityManager( 643): Process com.twist.android (pid 15854) has died. What about this being relevant?: http://stackoverflow.com/questions/4973310/signal-11-sigsegv-crash-android aka clearCache and destroyDrawingCache ? (stabbing in dark) When Application is placed in background and resumed, the UI is frozen -- Key: CB-1185 URL: https://issues.apache.org/jira/browse/CB-1185 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 2.0.0 Environment: Jelly Bean 4.1, ICS 4.0.x Reporter: Greg Assignee: Filip Maj Attachments: 0001-Fix-issue-with-pause-resume-freezing-the-UI.patch, 0002-Uncomment.patch, cordova-2.0.0.jar, issues.zip When using PhoneGap 2.0.0 on ICS or JellyBean, the application freezes up after you set the app to the background or turn of the screen. After around 3-7 seconds, the application unfreezes and pretty much causes a panic and usually crashes. No error reports have been submitted. Here is how you re-produce the issue: 1. Download Untappd - V2.0.4(https://play.google.com/store/apps/details?id=com.untappdllc.app) 2. After logging in stay on the Friends tab 3. Turn the the screen off and wait about 3-7 minutes 4. Turn the screen back on, and the interface should be frozen. Another possible path to re-producing the issue: 1. Download Untappd - V2.0.4(https://play.google.com/store/apps/details?id=com.untappdllc.app) 2. After logging in stay on the Friends tab 3. Go back to the home screen then use other apps for about 3-7 minutes. 4. Go back into Untappd, and the interface should be frozen. When the app is frozen, native menu buttons will not nor any options in the UI. Would love to see if anyone can replicate this. I've tested this on Jelly Bean 4.1.x on a Samsung Galaxy Nexus, but users have been having this problem majority on ICS (4.0.x) Thanks, Greg -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-1185) When Application is placed in background and resumed, the UI is frozen
[ https://issues.apache.org/jira/browse/CB-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13496655#comment-13496655 ] Lindsey Simon commented on CB-1185: --- Hrm... I started looking higher up in my log posted above and found something that looks very much like what's being discussed in this thread (and please forgive me if somehow is not relevant.. I'm kinda shooting at fish in a barrel here). http://www.jasonshah.com/handling-android-2-3-webviews-broken-addjavascriptinterface/ From my log: 11-02 16:56:21.263 D/DroidGap(15854): Resuming the App 11-02 16:56:21.263 I/CpuGovernorService( 643): intent action: android.intent.action.SCREEN_ON 11-02 16:56:21.263 I/SamplingRateChangeProcessor( 643): Decreased sampling rate. 11-02 16:56:21.263 D/CordovaWebView(15854): loadUrlNow() 11-02 16:56:21.263 D/FirewallPolicy( 643): getURLFilterEnabled(true) 11-02 16:56:21.263 D/FirewallPolicy( 643): isUrlBlocked - Policy disabled ... 11-02 16:56:21.563 W/System.err(15854): at android.webkit.BrowserFrame.stringByEvaluatingJavaScriptFromString(Native Method) 11-02 16:56:21.563 W/System.err(15854): at android.webkit.BrowserFrame.loadUrl(BrowserFrame.java:303) 11-02 16:56:21.563 W/System.err(15854): at android.webkit.WebViewCore.loadUrl(WebViewCore.java:2817) 11-02 16:56:21.563 W/System.err(15854): at android.webkit.WebViewCore.access$1900(WebViewCore.java:76) 11-02 16:56:21.563 W/System.err(15854): at android.webkit.WebViewCore$EventHub$1.handleMessage(WebViewCore.java:1668) 11-02 16:56:21.563 W/System.err(15854): at android.os.Handler.dispatchMessage(Handler.java:99) 11-02 16:56:21.563 W/System.err(15854): at android.os.Looper.loop(Looper.java:137) 11-02 16:56:21.563 W/System.err(15854): at android.webkit.WebViewCore$WebCoreThread.run(WebViewCore.java:956) 11-02 16:56:21.563 W/System.err(15854): at java.lang.Thread.run(Thread.java:856) When Application is placed in background and resumed, the UI is frozen -- Key: CB-1185 URL: https://issues.apache.org/jira/browse/CB-1185 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 2.0.0 Environment: Jelly Bean 4.1, ICS 4.0.x Reporter: Greg Assignee: Filip Maj Attachments: 0001-Fix-issue-with-pause-resume-freezing-the-UI.patch, 0002-Uncomment.patch, cordova-2.0.0.jar, issues.zip When using PhoneGap 2.0.0 on ICS or JellyBean, the application freezes up after you set the app to the background or turn of the screen. After around 3-7 seconds, the application unfreezes and pretty much causes a panic and usually crashes. No error reports have been submitted. Here is how you re-produce the issue: 1. Download Untappd - V2.0.4(https://play.google.com/store/apps/details?id=com.untappdllc.app) 2. After logging in stay on the Friends tab 3. Turn the the screen off and wait about 3-7 minutes 4. Turn the screen back on, and the interface should be frozen. Another possible path to re-producing the issue: 1. Download Untappd - V2.0.4(https://play.google.com/store/apps/details?id=com.untappdllc.app) 2. After logging in stay on the Friends tab 3. Go back to the home screen then use other apps for about 3-7 minutes. 4. Go back into Untappd, and the interface should be frozen. When the app is frozen, native menu buttons will not nor any options in the UI. Would love to see if anyone can replicate this. I've tested this on Jelly Bean 4.1.x on a Samsung Galaxy Nexus, but users have been having this problem majority on ICS (4.0.x) Thanks, Greg -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-1185) When Application is placed in background and resumed, the UI is frozen
[ https://issues.apache.org/jira/browse/CB-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13496669#comment-13496669 ] Lindsey Simon commented on CB-1185: --- [~bowserj] Pasting more of the logs in case there's something of interest there. My device is a Galaxy S3, so yah Android 4.x 11-02 16:56:00.243 V/AlarmManager( 643): waitForAlarm result :8 11-02 16:56:00.243 V/AlarmManager( 643): ClockReceiver onReceive() ACTION_TIME_TICK 11-02 16:56:00.243 W/AlarmManager( 643): FACTORY_ON= 0 11-02 16:56:00.323 D/KeyguardUpdateMonitor( 643): received broadcast android.intent.action.TIME_TICK 11-02 16:56:00.333 D/KeyguardUpdateMonitor( 643): handleTimeUpdate 11-02 16:56:00.353 D/FirewallPolicy( 643): getURLFilterEnabled(true) 11-02 16:56:00.353 D/FirewallPolicy( 643): isUrlBlocked - Policy disabled 11-02 16:56:00.363 D/STATUSBAR-Clock( 779): onReceive() - ACTION_TIME_TICK 11-02 16:56:00.363 D/STATUSBAR-Clock( 779): updateClock :4:56 PM 11-02 16:56:00.413 D/FirewallPolicy( 643): getURLFilterEnabled(true) 11-02 16:56:00.413 D/FirewallPolicy( 643): isUrlBlocked - Policy disabled 11-02 16:56:00.413 D/STATUSBAR-DateView( 779): updateClock :11/02/2012 11-02 16:56:00.564 D/ClockWidget( 643): refreshTime() 11-02 16:56:00.604 D/ClockWidget( 643): TTS Message = It is 4 : 56 PM, Friday, November 2 11-02 16:56:01.545 D/FirewallPolicy( 643): getURLFilterEnabled(true) 11-02 16:56:01.545 D/FirewallPolicy( 643): isUrlBlocked - Policy disabled 11-02 16:56:01.555 D/FirewallPolicy( 643): getURLFilterEnabled(true) 11-02 16:56:01.555 D/FirewallPolicy( 643): isUrlBlocked - Policy disabled 11-02 16:56:02.986 D/FirewallPolicy( 643): getURLFilterEnabled(true) 11-02 16:56:02.986 D/FirewallPolicy( 643): isUrlBlocked - Policy disabled 11-02 16:56:03.006 D/FirewallPolicy( 643): getURLFilterEnabled(true) 11-02 16:56:03.006 D/FirewallPolicy( 643): isUrlBlocked - Policy disabled 11-02 16:56:04.107 D/FirewallPolicy( 643): getURLFilterEnabled(true) 11-02 16:56:04.107 D/FirewallPolicy( 643): isUrlBlocked - Policy disabled 11-02 16:56:04.117 D/FirewallPolicy( 643): getURLFilterEnabled(true) 11-02 16:56:04.117 D/FirewallPolicy( 643): isUrlBlocked - Policy disabled 11-02 16:56:05.559 D/FirewallPolicy( 643): getURLFilterEnabled(true) 11-02 16:56:05.559 D/FirewallPolicy( 643): isUrlBlocked - Policy disabled 11-02 16:56:05.559 D/FirewallPolicy( 643): getURLFilterEnabled(true) 11-02 16:56:05.559 D/FirewallPolicy( 643): isUrlBlocked - Policy disabled 11-02 16:56:07.251 D/FirewallPolicy( 643): getURLFilterEnabled(true) 11-02 16:56:07.251 D/FirewallPolicy( 643): isUrlBlocked - Policy disabled 11-02 16:56:07.271 D/FirewallPolicy( 643): getURLFilterEnabled(true) 11-02 16:56:07.271 D/FirewallPolicy( 643): isUrlBlocked - Policy disabled 11-02 16:56:07.511 D/FirewallPolicy( 643): getURLFilterEnabled(true) 11-02 16:56:07.511 D/FirewallPolicy( 643): isUrlBlocked - Policy disabled 11-02 16:56:08.542 D/BatteryService( 643): update start 11-02 16:56:08.542 D/BatteryService( 643): level:99 scale:100 status:3 health:2 present:true voltage: 4261 temperature: 290 technology: Li-ion AC powered:false USB powered:false icon:17303121 invalid charger:0 11-02 16:56:08.552 D/KeyguardUpdateMonitor( 643): received broadcast android.intent.action.BATTERY_CHANGED 11-02 16:56:08.552 D/KeyguardUpdateMonitor( 643): handleBatteryUpdate 11-02 16:56:08.552 D/ThermistorObserver( 643): mBatteryBRForAMOLED : onReceive() : newTemperature : 290 11-02 16:56:08.552 D/STATUSBAR-BatteryController( 779): onReceive() - ACTION_BATTERY_CHANGED 11-02 16:56:08.552 D/STATUSBAR-BatteryController( 779): onReceive() - level:99 11-02 16:56:08.552 D/STATUSBAR-BatteryController( 779): onReceive() - plugged:0 11-02 16:56:08.552 D/STATUSBAR-BatteryController( 779): onReceive() - BATTERY_STATUS_DISCHARGING: stat_sys_battery 11-02 16:56:10.815 E/MP-Decision( 1366): UP Ld:92 Nw:1.99 Tw:140 rq:1.00 seq:147.00 11-02 16:56:11.155 D/FirewallPolicy( 643): getURLFilterEnabled(true) 11-02 16:56:11.155 D/FirewallPolicy( 643): isUrlBlocked - Policy disabled 11-02 16:56:11.175 D/FirewallPolicy( 643): getURLFilterEnabled(true) 11-02 16:56:11.175 D/FirewallPolicy( 643): isUrlBlocked - Policy disabled 11-02 16:56:11.185 D/FirewallPolicy( 643): getURLFilterEnabled(true) 11-02 16:56:11.185 D/FirewallPolicy( 643): isUrlBlocked - Policy disabled 11-02 16:56:11.195 D/FirewallPolicy( 643): getURLFilterEnabled(true) 11-02 16:56:11.195 D/FirewallPolicy( 643): isUrlBlocked - Policy disabled 11-02 16:56:11.205 D/FirewallPolicy( 643): getURLFilterEnabled(true) 11-02 16:56:11.205 D/FirewallPolicy( 643): isUrlBlocked - Policy disabled 11-02 16:56:11.215 D/FirewallPolicy( 643): getURLFilterEnabled(true) 11-02 16:56:11.215 D/FirewallPolicy( 643): isUrlBlocked - Policy disabled 11-02 16:56:11.305 D/FirewallPolicy( 643): getURLFilterEnabled(true) 11-02 16:56:11.305 D/FirewallPolicy
[jira] [Commented] (CB-1185) When Application is placed in background and resumed, the UI is frozen
[ https://issues.apache.org/jira/browse/CB-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13493805#comment-13493805 ] Lindsey Simon commented on CB-1185: --- One other thing.. the last log from my app (awhile before this) is this one from UrbanAirship. h. (just throwing this out there to see if Untappd might also be using UA, or else this is just a red herring) 11-08 21:00:13.585 I/Twist - UALib( 691): Sending 4 events. 11-08 21:00:13.595 I/Twist - UALib( 691): Sending Analytics to: https://combine.urbanairship.com/warp9/ When Application is placed in background and resumed, the UI is frozen -- Key: CB-1185 URL: https://issues.apache.org/jira/browse/CB-1185 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 2.0.0 Environment: Jelly Bean 4.1, ICS 4.0.x Reporter: Greg Assignee: Filip Maj Fix For: 2.3.0 Attachments: 0001-Fix-issue-with-pause-resume-freezing-the-UI.patch, 0002-Uncomment.patch, cordova-2.0.0.jar When using PhoneGap 2.0.0 on ICS or JellyBean, the application freezes up after you set the app to the background or turn of the screen. After around 3-7 seconds, the application unfreezes and pretty much causes a panic and usually crashes. No error reports have been submitted. Here is how you re-produce the issue: 1. Download Untappd - V2.0.4(https://play.google.com/store/apps/details?id=com.untappdllc.app) 2. After logging in stay on the Friends tab 3. Turn the the screen off and wait about 3-7 minutes 4. Turn the screen back on, and the interface should be frozen. Another possible path to re-producing the issue: 1. Download Untappd - V2.0.4(https://play.google.com/store/apps/details?id=com.untappdllc.app) 2. After logging in stay on the Friends tab 3. Go back to the home screen then use other apps for about 3-7 minutes. 4. Go back into Untappd, and the interface should be frozen. When the app is frozen, native menu buttons will not nor any options in the UI. Would love to see if anyone can replicate this. I've tested this on Jelly Bean 4.1.x on a Samsung Galaxy Nexus, but users have been having this problem majority on ICS (4.0.x) Thanks, Greg -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-1185) When Application is placed in background and resumed, the UI is frozen
[ https://issues.apache.org/jira/browse/CB-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13492646#comment-13492646 ] Lindsey Simon commented on CB-1185: --- I can't even reproduce it in our app, as much as I try. I'm fantasizing that I'll be able to. If I find a way, I'll definitely try to distill it. When Application is placed in background and resumed, the UI is frozen -- Key: CB-1185 URL: https://issues.apache.org/jira/browse/CB-1185 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 2.0.0 Environment: Jelly Bean 4.1, ICS 4.0.x Reporter: Greg Assignee: Filip Maj Fix For: 2.3.0 Attachments: 0001-Fix-issue-with-pause-resume-freezing-the-UI.patch, 0002-Uncomment.patch, cordova-2.0.0.jar When using PhoneGap 2.0.0 on ICS or JellyBean, the application freezes up after you set the app to the background or turn of the screen. After around 3-7 seconds, the application unfreezes and pretty much causes a panic and usually crashes. No error reports have been submitted. Here is how you re-produce the issue: 1. Download Untappd - V2.0.4(https://play.google.com/store/apps/details?id=com.untappdllc.app) 2. After logging in stay on the Friends tab 3. Turn the the screen off and wait about 3-7 minutes 4. Turn the screen back on, and the interface should be frozen. Another possible path to re-producing the issue: 1. Download Untappd - V2.0.4(https://play.google.com/store/apps/details?id=com.untappdllc.app) 2. After logging in stay on the Friends tab 3. Go back to the home screen then use other apps for about 3-7 minutes. 4. Go back into Untappd, and the interface should be frozen. When the app is frozen, native menu buttons will not nor any options in the UI. Would love to see if anyone can replicate this. I've tested this on Jelly Bean 4.1.x on a Samsung Galaxy Nexus, but users have been having this problem majority on ICS (4.0.x) Thanks, Greg -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-1185) When Application is placed in background and resumed, the UI is frozen
[ https://issues.apache.org/jira/browse/CB-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13492028#comment-13492028 ] Lindsey Simon commented on CB-1185: --- on keepRunning - I found a ref for it, but we don't change the default (which is true right?) When Application is placed in background and resumed, the UI is frozen -- Key: CB-1185 URL: https://issues.apache.org/jira/browse/CB-1185 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 2.0.0 Environment: Jelly Bean 4.1, ICS 4.0.x Reporter: Greg Assignee: Filip Maj Fix For: 2.3.0 Attachments: 0001-Fix-issue-with-pause-resume-freezing-the-UI.patch, 0002-Uncomment.patch, cordova-2.0.0.jar When using PhoneGap 2.0.0 on ICS or JellyBean, the application freezes up after you set the app to the background or turn of the screen. After around 3-7 seconds, the application unfreezes and pretty much causes a panic and usually crashes. No error reports have been submitted. Here is how you re-produce the issue: 1. Download Untappd - V2.0.4(https://play.google.com/store/apps/details?id=com.untappdllc.app) 2. After logging in stay on the Friends tab 3. Turn the the screen off and wait about 3-7 minutes 4. Turn the screen back on, and the interface should be frozen. Another possible path to re-producing the issue: 1. Download Untappd - V2.0.4(https://play.google.com/store/apps/details?id=com.untappdllc.app) 2. After logging in stay on the Friends tab 3. Go back to the home screen then use other apps for about 3-7 minutes. 4. Go back into Untappd, and the interface should be frozen. When the app is frozen, native menu buttons will not nor any options in the UI. Would love to see if anyone can replicate this. I've tested this on Jelly Bean 4.1.x on a Samsung Galaxy Nexus, but users have been having this problem majority on ICS (4.0.x) Thanks, Greg -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-1185) When Application is placed in background and resumed, the UI is frozen
[ https://issues.apache.org/jira/browse/CB-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13492069#comment-13492069 ] Lindsey Simon commented on CB-1185: --- We build locally, but need to keepRunning for our app to work. We're gathering geopoints and beaconing them to a server while backgrounded. When Application is placed in background and resumed, the UI is frozen -- Key: CB-1185 URL: https://issues.apache.org/jira/browse/CB-1185 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 2.0.0 Environment: Jelly Bean 4.1, ICS 4.0.x Reporter: Greg Assignee: Filip Maj Fix For: 2.3.0 Attachments: 0001-Fix-issue-with-pause-resume-freezing-the-UI.patch, 0002-Uncomment.patch, cordova-2.0.0.jar When using PhoneGap 2.0.0 on ICS or JellyBean, the application freezes up after you set the app to the background or turn of the screen. After around 3-7 seconds, the application unfreezes and pretty much causes a panic and usually crashes. No error reports have been submitted. Here is how you re-produce the issue: 1. Download Untappd - V2.0.4(https://play.google.com/store/apps/details?id=com.untappdllc.app) 2. After logging in stay on the Friends tab 3. Turn the the screen off and wait about 3-7 minutes 4. Turn the screen back on, and the interface should be frozen. Another possible path to re-producing the issue: 1. Download Untappd - V2.0.4(https://play.google.com/store/apps/details?id=com.untappdllc.app) 2. After logging in stay on the Friends tab 3. Go back to the home screen then use other apps for about 3-7 minutes. 4. Go back into Untappd, and the interface should be frozen. When the app is frozen, native menu buttons will not nor any options in the UI. Would love to see if anyone can replicate this. I've tested this on Jelly Bean 4.1.x on a Samsung Galaxy Nexus, but users have been having this problem majority on ICS (4.0.x) Thanks, Greg -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-1185) When Application is placed in background and resumed, the UI is frozen
[ https://issues.apache.org/jira/browse/CB-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13492172#comment-13492172 ] Lindsey Simon commented on CB-1185: --- We just got logs with a crash like this, but nothing new here really: 11-06 22:38:35.070 D/DroidGap( 5361): onMessage(onNativeReady,null) 11-06 22:38:35.070 D/DroidGap( 5361): onMessage(onPageFinished,file:///android_asset/www/settings) When Application is placed in background and resumed, the UI is frozen -- Key: CB-1185 URL: https://issues.apache.org/jira/browse/CB-1185 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 2.0.0 Environment: Jelly Bean 4.1, ICS 4.0.x Reporter: Greg Assignee: Filip Maj Fix For: 2.3.0 Attachments: 0001-Fix-issue-with-pause-resume-freezing-the-UI.patch, 0002-Uncomment.patch, cordova-2.0.0.jar When using PhoneGap 2.0.0 on ICS or JellyBean, the application freezes up after you set the app to the background or turn of the screen. After around 3-7 seconds, the application unfreezes and pretty much causes a panic and usually crashes. No error reports have been submitted. Here is how you re-produce the issue: 1. Download Untappd - V2.0.4(https://play.google.com/store/apps/details?id=com.untappdllc.app) 2. After logging in stay on the Friends tab 3. Turn the the screen off and wait about 3-7 minutes 4. Turn the screen back on, and the interface should be frozen. Another possible path to re-producing the issue: 1. Download Untappd - V2.0.4(https://play.google.com/store/apps/details?id=com.untappdllc.app) 2. After logging in stay on the Friends tab 3. Go back to the home screen then use other apps for about 3-7 minutes. 4. Go back into Untappd, and the interface should be frozen. When the app is frozen, native menu buttons will not nor any options in the UI. Would love to see if anyone can replicate this. I've tested this on Jelly Bean 4.1.x on a Samsung Galaxy Nexus, but users have been having this problem majority on ICS (4.0.x) Thanks, Greg -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-1185) When Application is placed in background and resumed, the UI is frozen
[ https://issues.apache.org/jira/browse/CB-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13492176#comment-13492176 ] Lindsey Simon commented on CB-1185: --- Actually, apologies - that log line and when I think the crash happened don't line up, the more I look at the logs. I got excited because I saw an earlier mention on this thread that had these called out, but they're common enough in my logs (they look like they just represent page load). When Application is placed in background and resumed, the UI is frozen -- Key: CB-1185 URL: https://issues.apache.org/jira/browse/CB-1185 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 2.0.0 Environment: Jelly Bean 4.1, ICS 4.0.x Reporter: Greg Assignee: Filip Maj Fix For: 2.3.0 Attachments: 0001-Fix-issue-with-pause-resume-freezing-the-UI.patch, 0002-Uncomment.patch, cordova-2.0.0.jar When using PhoneGap 2.0.0 on ICS or JellyBean, the application freezes up after you set the app to the background or turn of the screen. After around 3-7 seconds, the application unfreezes and pretty much causes a panic and usually crashes. No error reports have been submitted. Here is how you re-produce the issue: 1. Download Untappd - V2.0.4(https://play.google.com/store/apps/details?id=com.untappdllc.app) 2. After logging in stay on the Friends tab 3. Turn the the screen off and wait about 3-7 minutes 4. Turn the screen back on, and the interface should be frozen. Another possible path to re-producing the issue: 1. Download Untappd - V2.0.4(https://play.google.com/store/apps/details?id=com.untappdllc.app) 2. After logging in stay on the Friends tab 3. Go back to the home screen then use other apps for about 3-7 minutes. 4. Go back into Untappd, and the interface should be frozen. When the app is frozen, native menu buttons will not nor any options in the UI. Would love to see if anyone can replicate this. I've tested this on Jelly Bean 4.1.x on a Samsung Galaxy Nexus, but users have been having this problem majority on ICS (4.0.x) Thanks, Greg -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira