[jira] [Commented] (CB-1286) Cordova 2.1 callbacks stops working after sleep/wake with jQuery Mobile + Android Transformer Pad
[ https://issues.apache.org/jira/browse/CB-1286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13490675#comment-13490675 ] Simon MacDonald commented on CB-1286: - Cool, thanks for the investigation. Have you created a separate issue for this bug? If not you should and include these findings. Cordova 2.1 callbacks stops working after sleep/wake with jQuery Mobile + Android Transformer Pad - Key: CB-1286 URL: https://issues.apache.org/jira/browse/CB-1286 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 2.0.0 Environment: Android 4.0.3; Asus Transformer Pad, Reporter: Walter Nicholls Assignee: Joe Bowser Fix For: 2.2.0 Attachments: TPadBug-debug.apk, TPadBug-src.zip Using attached sample app, program works up until tablet goes to sleep. When the tablet wakes up, callback no longer functions Full thread of original problem report: https://groups.google.com/forum/?fromgroups=#!topic/phonegap/ut3RqEgDx58 I started with Cordova 2.0.0, then while investigating upgraded to development code from github and struck an introduced, now fixed, problem. SO I am now back to the original issue but with latest code (2.1 RC) Steps to reproduce: -- 1. Install attached APK file (I also include source in separate zip (includes cordova.jar file), and run program. 2. Touch the dialog button OBSERVED: Text says mary had a little lamb... ( result from plugin) 3. Touch Close to return to front screen 4. Wait for the tablet to go to sleep and disconnect from network etc - takes about 5 minutes with my tablet as it is configured. (screen going dark is not enough, it has to shut down into deep sleep) 5. Wake the tablet and unlock screen 6. Touch the dialog buitton again. EXPECTED: Text mary had a little lamb... again but OBSERVED: Text if you are reading this something went wrong What seems to be happening --- The way the dialog works is that the something wrong message is the text in the HTML file, but the page show functions calls a plugin to get the text to show. This is all handled by jQuery Mobile with an ajax load. Until the deep sleep point, everything works as expected, the plugin returns a result which is placed in the queue, then the setTimeout()-based Javascript side picks it up. After deep sleep, the callback mechanism breaks, and although the plugin is called and produces a result, this is never collected from Javascript. I watch the log with the command : adb logcat -v time | grep -E Cordova|Callback|DroidGap|TPadBug So while it is working... 8-28 14:15:32.180 D/DroidGap(29867): onMessage(onPageFinished,file:///android_asset/www/index.html#/android_asset/www/index.htmlui-state=dialog) 08-28 14:15:32.200 D/CordovaLog(29867): Dialog is about to call plugin 08-28 14:15:32.200 D/CordovaLog(29867): file:///android_asset/www/tpadbug2.js: Line 44 : Dialog is about to call plugin 08-28 14:15:32.200 D/TPadBugPlugin(29867): Enter plugin action:GetRandomText 08-28 14:15:32.200 D/TPadBugPlugin(29867): Plugin successful 08-28 14:15:32.200 D/TPadBugPlugin(29867): Plugin exiting 08-28 14:15:32.250 D/CordovaLog(29867): Dialog has got results back from plugin: 102 chars 08-28 14:15:32.250 D/CordovaLog(29867): file:///android_asset/www/tpadbug2.js: Line 47 : Dialog has got results back from plugin: 102 chars 08-28 14:15:35.770 D/Cordova (29867): onPageFinished(file:///android_asset/www/index.html) Note particular the Dialog has got results back.. which shows the JS callback working. After a sleep/resume cycle: 08-28 14:23:05.880 D/DroidGap(29867): onMessage(onPageFinished,file:///android_asset/www/index.html#/android_asset/www/index.htmlui-state=dialog) 08-28 14:23:05.900 D/CordovaLog(29867): Dialog is about to call plugin 08-28 14:23:05.900 D/CordovaLog(29867): file:///android_asset/www/tpadbug2.js: Line 44 : Dialog is about to call plugin 08-28 14:23:05.900 D/TPadBugPlugin(29867): Enter plugin action:GetRandomText 08-28 14:23:05.900 D/TPadBugPlugin(29867): Plugin successful 08-28 14:23:05.900 D/TPadBugPlugin(29867): Plugin exiting .. and nothing more, no dialog handler. (I did have a lot of console.log and Log.d calls as well, but these got lost in some of the test and updating to latest code. Read Google Groups thread for the agonizing detail). Needless to say, this stops my app in its tracks. I left an additional page for test timeouts which if you navigate to this, it shows that callbacks are once again working, and then when you go back (using the android back button) to the indexpage, the callbacks start working there again too
Re: iOS: Why does the cordova.js filename change?
On Fri, Nov 2, 2012 at 6:20 PM, Shazron shaz...@gmail.com wrote: Ok I found out its actually in two locations, it's in the CordovaLibAppTests/www folder as well as the bin/template. Yeah having one location would be best -- we did have it not having the version before though, with copying/updates based on the Makefile. I'm thinking we only update: CordovaLib/cordova.ios.js with the latest from cordova-js I think we could do this without the explicit step. Then for a release, run a script/Makefile target to update: 1. CordovaLibAppTests/www/cordova.ios.js For this, we can add a copy step to the build phases to copy the file in from CordovaLib on each build 2. bin/templates/project/www with the versioned .js For this, we can have the create script just grab the .js file from CordovaLib instead of from the templates directory. On Fri, Nov 2, 2012 at 2:49 PM, Andrew Grieve agri...@chromium.org wrote: It actually does bother me a little bit too, to have the file name have a version in it when we're developing. I don't really care where we put the file so long as there is only one copy of it and not multiple. On Wed, Oct 31, 2012 at 4:22 PM, Shazron shaz...@gmail.com wrote: On iOS, the cordova.js used to (inertia really because of the legacy location) be in the CordovaLib folder, and also the template. Since it was redundant, we only put it in the default template in bin/templates/project now. Even this is not ideal with respect to people upgrading and using it as an embedded WebView -- to grab the new .js they have to create a new project (or spelunk into the bin/templates folder). Ideally it should be put back also into CordovaLib because the .js is tightly coupled to a specific CordovaLib library and version, and for easy discovery. Don't know what the ideal situation can be here. On Tue, Oct 30, 2012 at 5:34 PM, Kevin Hawkins khawk...@salesforce.com wrote: Hi all, Apologies if/that I've missed this discussion previously. I'm not clear on why the cordova.js file name changes in the iOS repo, particularly given the fact that great lengths seem to have been taken everywhere to be agnostic about what the originating name is, opting to dynamically update the destination name in build scripts, template generation, etc.? Changing the originating file name with each new iteration/revision of Cordova makes it hard to follow its history on GitHub (though it's easy enough locally with git log and --follow), and just generally seems unnecessary. Thanks, Kevin
Updating Release + Test articles on the wiki
I think both our cutting releases [1] and our running tests [2] wiki articles need an audit. After last week's little scare with Android's CordovaWebView functionality, I'd like to see all platforms note down any special release/testing steps in these articles (compiling the Starter zip on WP7 comes to mind). Same as running the ./cordova/debug and ./cordova/emulate test scripts on Android. [1] http://wiki.apache.org/cordova/CuttingReleases [2] http://wiki.apache.org/cordova/RunningTests
[jira] [Resolved] (CB-1801) Inflation Error preventing CordovaTest to run
[ https://issues.apache.org/jira/browse/CB-1801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Bowser resolved CB-1801. Resolution: Fixed CordovaTest now runs and succeeds! Inflation Error preventing CordovaTest to run - Key: CB-1801 URL: https://issues.apache.org/jira/browse/CB-1801 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 2.2.0 Reporter: Joe Bowser Assignee: Joe Bowser Fix For: 2.3.0 The CordovaTest, which tests the CordovaWebView component is failing because of an inflate error when running the unit test. This halts all the unit tests from executing. This should be fixed, because while this doesn't manifest itself in Cordova yet, it could break apps using CordovaWebView as a component. -- 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-1811) Previously hidden select dropdowns crashing the webview when focused upon
[ https://issues.apache.org/jira/browse/CB-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13490867#comment-13490867 ] Joe Bowser commented on CB-1811: This is what happens when I test it on my Galaxy Nexus running CM 10-M2: 11-05 11:50:01.482: E/webcoreglue(27789): Should not happen: no rect-based-test nodes found The select does work though, which makes me want to blame Samsung. More testing will be required. Previously hidden select dropdowns crashing the webview when focused upon - Key: CB-1811 URL: https://issues.apache.org/jira/browse/CB-1811 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 2.1.0, 2.2.0 Environment: Samsung Galaxy S3 (Android 4.0.4) Reporter: Adam Assignee: Joe Bowser Labels: bug, crash I have a div panel that is hidden when a page is first shown. Inside the div are a few html dropdowns (select tags). When I make the div visible (via javascript) and focus into one of the dropdowns, I get the following logcat error: 11-04 03:58:49.136: A/libc(18437): Fatal signal 11 (SIGSEGV) at 0x (code=1) Then, the app just crashes and the webview disappears. I confirmed that this happens when the parent div is initially invisible (display:none). If the div is visible at first, all works fine, even if the div is hidden subsequently. -- 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-1811) Previously hidden select dropdowns crashing the webview when focused upon
[ https://issues.apache.org/jira/browse/CB-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13490872#comment-13490872 ] Joe Bowser commented on CB-1811: Works on my Nexus 7 Stock, which means that this is looking more Samsung based. I'm going to grab the HTC One X and the Samsung Galaxy S2 to test next. Previously hidden select dropdowns crashing the webview when focused upon - Key: CB-1811 URL: https://issues.apache.org/jira/browse/CB-1811 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 2.1.0, 2.2.0 Environment: Samsung Galaxy S3 (Android 4.0.4) Reporter: Adam Assignee: Joe Bowser Labels: bug, crash I have a div panel that is hidden when a page is first shown. Inside the div are a few html dropdowns (select tags). When I make the div visible (via javascript) and focus into one of the dropdowns, I get the following logcat error: 11-04 03:58:49.136: A/libc(18437): Fatal signal 11 (SIGSEGV) at 0x (code=1) Then, the app just crashes and the webview disappears. I confirmed that this happens when the parent div is initially invisible (display:none). If the div is visible at first, all works fine, even if the div is hidden subsequently. -- 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-1811) Previously hidden select dropdowns crashing the webview when focused upon
[ https://issues.apache.org/jira/browse/CB-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13490876#comment-13490876 ] Joe Bowser commented on CB-1811: Tested it on the Samsung Galaxy S2 with 4.0.4 and HTC One X with 4.0.3. This is confined to the Samsung Galaxy S3. Previously hidden select dropdowns crashing the webview when focused upon - Key: CB-1811 URL: https://issues.apache.org/jira/browse/CB-1811 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 2.1.0, 2.2.0 Environment: Samsung Galaxy S3 (Android 4.0.4) Reporter: Adam Assignee: Joe Bowser Labels: bug, crash I have a div panel that is hidden when a page is first shown. Inside the div are a few html dropdowns (select tags). When I make the div visible (via javascript) and focus into one of the dropdowns, I get the following logcat error: 11-04 03:58:49.136: A/libc(18437): Fatal signal 11 (SIGSEGV) at 0x (code=1) Then, the app just crashes and the webview disappears. I confirmed that this happens when the parent div is initially invisible (display:none). If the div is visible at first, all works fine, even if the div is hidden subsequently. -- 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] [Created] (CB-1812) Example use of deviceready in docs is incorrect
Filip Maj created CB-1812:
-
Summary: Example use of deviceready in docs is incorrect
Key: CB-1812
URL: https://issues.apache.org/jira/browse/CB-1812
Project: Apache Cordova
Issue Type: Bug
Components: Docs
Affects Versions: 2.2.0
Reporter: Filip Maj
Assignee: Michael Brooks
This came from someone who submitted a pull req via GitHub to the PhoneGap
project: https://github.com/phonegap/phonegap/pull/17
Essentially the full example first waits for {{body onload}} before attaching
to deviceready. We can eliminate that and directly attach to {{deviceready}}.
--
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
Re: [Android] CordovaWebView is broken
On Mon, Nov 5, 2012 at 9:22 AM, Joe Bowser bows...@gmail.com wrote: Hey I know that this kind of seems like a step back, but perhaps we should start with the refactor of DroidGap into CordovaActivity. The main obstacle that we have right now with the CordovaWebView is the fact that we have to implement everything in CordovaInterface. While we can't get rid of this, we could create a helper activity that implements this by moving the current methods from DroidGap into that. Then we can make DroidGap simply an activity that creates the view and optional. Due to the nature of Java, anyone combining other custom activites (i.e. MapActivity) will still have to implement the CordovaInterface, but this should further lower the barrier for many people who want to mix CordovaWebView with Android UI controls, namely the menu bar (in fact, this is the only UI control that I think anyone would want to add). Thoughts? +1 On Mon, Nov 5, 2012 at 9:10 AM, Andrew Grieve agri...@chromium.org wrote: Aah, I didn't realize that CordovaInterface was meant to be implemented other than by DroidGap. Sorry about that. Weird that projects would even compile without having the new method though. Once the tests are fixed up, we should definitely add running them to the list of release steps. On Fri, Nov 2, 2012 at 4:27 PM, Joe Bowser bows...@gmail.com wrote: Nevermindit's kinda bad but it's not minor release bad. Basically, adding the thread pool method requirement to the CordovaInterface is what broke this. For some reason when you don't have a thread pool, Cordova silently fails instead of dumping core all over the place. Is it possible that we can get plugins to get the thread pool from elsewhere, or does it have to be in the Activity? On Fri, Nov 2, 2012 at 1:08 PM, Joe Bowser bows...@gmail.com wrote: Hey I just started fixing up our broken JUnit Tests, and I discovered that the recent refactors broke the CordovaWebView standalone component. This means that anyone who is using the CordovaWebView as a standalone component should probably not upgrade to 2.2.0 and that we'll have to issue a 2.2.1 release to address this issue. It seems that for some reason deviceready is no longer firing. I think this may have to do with the recent changes to plugins as well as the addition of a thread pool. I'm going to commit the fixes to the tests today, but you can recreate the issue by pulling down this debug repo, putting it in Eclipse and making it use Cordova as a library. https://github.com/infil00p/CordovaActionView/tree/debug_version Also, you can debug this using the default activity on the test project, although the test project still needs a lot of cleaning to be done. It sucks that we missed this, but we really need to make sure we don't break the tests when we do a refactor. I'll add more details to the bug soon. This harsh sucks, because I don't think this will be an easy fix. :( Joe
plan for handling updated device OS versions?
I'm seeing rumors on the web that iOS 6.1 is in the works from Apple and there is a beta that recently opened. Is there any sort of target for handling new device OS versions in Cordova? For example: - Cordova should support a new device OS in the next Cordova version 4-6 weeks after the OS becomes generally available or - through the participation of betas with the device vendor, and careful release scheduling, Cordova should support a new device OS on day 1 that a new OS becomes generally available or - (something else entirely, since these are just examples) The goal here would be to: - provide some general direction to consumers and set realistic expectations. - provide specific direction to the Cordova development community, and give us a target to shoot for. - be consistent in our approach across all the OS vendors (assuming that is desired). Has there been previous discussion on this topic? If not, what are your ideas on this? -- Marcel Kinard
[jira] [Assigned] (CB-1809) `create` script should print out meaningful error messages
[
https://issues.apache.org/jira/browse/CB-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Bowser reassigned CB-1809:
--
Assignee: Anis Kadri (was: Joe Bowser)
`create` script should print out meaningful error messages
--
Key: CB-1809
URL: https://issues.apache.org/jira/browse/CB-1809
Project: Apache Cordova
Issue Type: Bug
Components: Android
Affects Versions: 2.1.0, 2.2.0
Environment: Mac OS X 10.7.5
Reporter: Filip Maj
Assignee: Anis Kadri
I've been seeing people have issues with the {{./bin/create}} script.
Helping them out on IRC is tough as the generic error message always received
is:
There has been an error. Deleting project...
--
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] [Updated] (CB-1811) Previously hidden select dropdowns crashing the webview when focused upon
[ https://issues.apache.org/jira/browse/CB-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Bowser updated CB-1811: --- Priority: Minor (was: Major) Lowering priority. Previously hidden select dropdowns crashing the webview when focused upon - Key: CB-1811 URL: https://issues.apache.org/jira/browse/CB-1811 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 2.1.0, 2.2.0 Environment: Samsung Galaxy S3 (Android 4.0.4) Reporter: Adam Assignee: Joe Bowser Priority: Minor Labels: bug, crash I have a div panel that is hidden when a page is first shown. Inside the div are a few html dropdowns (select tags). When I make the div visible (via javascript) and focus into one of the dropdowns, I get the following logcat error: 11-04 03:58:49.136: A/libc(18437): Fatal signal 11 (SIGSEGV) at 0x (code=1) Then, the app just crashes and the webview disappears. I confirmed that this happens when the parent div is initially invisible (display:none). If the div is visible at first, all works fine, even if the div is hidden subsequently. -- 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] [Updated] (CB-1805) Whitelist guide points to incorrect file for Android instructions
[
https://issues.apache.org/jira/browse/CB-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Bowser updated CB-1805:
---
Fix Version/s: 2.3.0
Whitelist guide points to incorrect file for Android instructions
-
Key: CB-1805
URL: https://issues.apache.org/jira/browse/CB-1805
Project: Apache Cordova
Issue Type: Bug
Components: Android, Docs
Affects Versions: 2.1.0
Reporter: Filip Maj
Assignee: Joe Bowser
Fix For: 2.3.0
The line:
The whitelisting rules are found in res/xml/cordova.xml
should point to {{res/xml/config.xml}} instead.
--
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-1805) Whitelist guide points to incorrect file for Android instructions
[
https://issues.apache.org/jira/browse/CB-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13490957#comment-13490957
]
Joe Bowser commented on CB-1805:
https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-docs.git;a=commit;h=8ba0943c1a990bcfccd4e1833104eed8c545a688
Whitelist guide points to incorrect file for Android instructions
-
Key: CB-1805
URL: https://issues.apache.org/jira/browse/CB-1805
Project: Apache Cordova
Issue Type: Bug
Components: Android, Docs
Affects Versions: 2.1.0
Reporter: Filip Maj
Assignee: Joe Bowser
Fix For: 2.3.0
The line:
The whitelisting rules are found in res/xml/cordova.xml
should point to {{res/xml/config.xml}} instead.
--
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] [Resolved] (CB-1805) Whitelist guide points to incorrect file for Android instructions
[
https://issues.apache.org/jira/browse/CB-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Bowser resolved CB-1805.
Resolution: Fixed
Docs have been updated, see the commit.
Whitelist guide points to incorrect file for Android instructions
-
Key: CB-1805
URL: https://issues.apache.org/jira/browse/CB-1805
Project: Apache Cordova
Issue Type: Bug
Components: Android, Docs
Affects Versions: 2.1.0
Reporter: Filip Maj
Assignee: Joe Bowser
Fix For: 2.3.0
The line:
The whitelisting rules are found in res/xml/cordova.xml
should point to {{res/xml/config.xml}} instead.
--
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] [Comment Edited] (CB-1811) Previously hidden select dropdowns crashing the webview when focused upon
[ https://issues.apache.org/jira/browse/CB-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13490974#comment-13490974 ] Adam edited comment on CB-1811 at 11/5/12 10:06 PM: - Thanks, Joe. Just out of curiosity, does every Android device/vendor/model have a different implementation of the native browser? was (Author: drogon): Thanks, Joe. Just out of curiosity, does every Android device/vendor have a different implementation of the native browser? Previously hidden select dropdowns crashing the webview when focused upon - Key: CB-1811 URL: https://issues.apache.org/jira/browse/CB-1811 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 2.1.0, 2.2.0 Environment: Samsung Galaxy S3 (Android 4.0.4) Reporter: Adam Assignee: Joe Bowser Priority: Minor Labels: bug, crash I have a div panel that is hidden when a page is first shown. Inside the div are a few html dropdowns (select tags). When I make the div visible (via javascript) and focus into one of the dropdowns, I get the following logcat error: 11-04 03:58:49.136: A/libc(18437): Fatal signal 11 (SIGSEGV) at 0x (code=1) Then, the app just crashes and the webview disappears. I confirmed that this happens when the parent div is initially invisible (display:none). If the div is visible at first, all works fine, even if the div is hidden subsequently. -- 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-1811) Previously hidden select dropdowns crashing the webview when focused upon
[ https://issues.apache.org/jira/browse/CB-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13490988#comment-13490988 ] Joe Bowser commented on CB-1811: Yes and no. There are a few primary builds of the browser based on what device tree they're based on. All Samsung devices should have the same build, and since I tested it on Samsung, I would be tempted to say that I can't reproduce it. Nexus devices are based on AOSP. HTC and other Qualcomm based-devices are based on the CodeAurora Android tree. Motorola and other OMAP based devices are based on the OMAP Android tree. Samsung Exynos based devices are based on their own special Android tree. Intel Atom based Android devices have their own tree. In addition, certain other manufacturers will also have other special trees, such as the LG Optimus 3D, which has its own webkit that slows down input and output from the WebKit bridge. This drives me up the wall, since I can't just tell people to root their devices and run CyanogenMod (yet another Android tree, based off AOSP). Previously hidden select dropdowns crashing the webview when focused upon - Key: CB-1811 URL: https://issues.apache.org/jira/browse/CB-1811 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 2.1.0, 2.2.0 Environment: Samsung Galaxy S3 (Android 4.0.4) Reporter: Adam Assignee: Joe Bowser Priority: Minor Labels: bug, crash I have a div panel that is hidden when a page is first shown. Inside the div are a few html dropdowns (select tags). When I make the div visible (via javascript) and focus into one of the dropdowns, I get the following logcat error: 11-04 03:58:49.136: A/libc(18437): Fatal signal 11 (SIGSEGV) at 0x (code=1) Then, the app just crashes and the webview disappears. I confirmed that this happens when the parent div is initially invisible (display:none). If the div is visible at first, all works fine, even if the div is hidden subsequently. -- 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] [Assigned] (CB-1796) camera.getPicture: the photo file is corrupted.
[ https://issues.apache.org/jira/browse/CB-1796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Bowser reassigned CB-1796: -- Assignee: Simon MacDonald (was: Joe Bowser) I can't reproduce on my Galaxy Nexus. AFAIK we no longer write to the gallery with camera.getPicture. camera.getPicture: the photo file is corrupted. --- Key: CB-1796 URL: https://issues.apache.org/jira/browse/CB-1796 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 2.0.0 Environment: Tested on Nexus 7 and Samsung Galaxy Reporter: Julien Bier Assignee: Simon MacDonald The picture saved in the Camera folder is corrupted: the file size is equal to 0kb. The file can not be read from Windows. -- 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] [Assigned] (CB-1794) `cordova` command line script(s) don't work with paths with spaces in them
[
https://issues.apache.org/jira/browse/CB-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Bowser reassigned CB-1794:
--
Assignee: Anis Kadri (was: Joe Bowser)
Can you explain what is going on here? This script just appears to call itself.
`cordova` command line script(s) don't work with paths with spaces in them
--
Key: CB-1794
URL: https://issues.apache.org/jira/browse/CB-1794
Project: Apache Cordova
Issue Type: Bug
Components: Android
Affects Versions: 2.1.0
Environment: Mac OS X 10.7.5
Reporter: Filip Maj
Assignee: Anis Kadri
Fix For: 2.3.0
I run the following:
{code}
./bin/create foo bar
cd foo\ bar
./cordova/debug
{code}
I get:
{code}
bash: /Users/fil/src/incubator-cordova-android/foo: No such file or
directory
{code}
I believe the patch is to change the line:
{{cd PROJECT_PATH}}
.. in the {{debug}} and {{cordova}} scripts to:
{{cd PROJECT_PATH}}
--
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
Re: Whitelist defaults
We've had the discussion. So what is the decision/consensus? Leave as is, or add * to default settings for all, with a warning in the console log? On Fri, Nov 2, 2012 at 11:33 AM, Joe Bowser bows...@gmail.com wrote: On Fri, Nov 2, 2012 at 10:59 AM, Shazron shaz...@gmail.com wrote: Echoing Anis here. The easiest use case is for corporate use (internal), where any connections are restricted to a certain domain for paranoid IT types. I can see the case of us allowing everything _by default_ though (eg adding the '*'), which really should have been the default so as to be backwards compatible with how it was before the whitelist came in. The system could detect this sole wildcard entry, and print out a warning in the console log, as well as the documentation of course pointing this out -- the latter which we should have done in the first place. OK, that sounds cool, but does that mean that in six months, we're going to deprecate this behaviour and get more aggressive with the whitelist? BTW: In the event that the whitelist isn't found based on the code that I'm looking at here, Android should block everything and fire default web intents. If it's not doing this, that's a bug! When we refer to defaults, are we referring to the config.xml that we're circulating? Also, how are we testing this whitelisting feature? I can tell you that doing it in JS alone wouldn't be enough. Joe
Re: Whitelist defaults
I guess the consensus is to whitelist everything (*) all the time. My opinion is that there should be some dev mode where (*) is set and then a release mode where you'd specify your hosts. On Mon, Nov 5, 2012 at 3:11 PM, Shazron shaz...@gmail.com wrote: We've had the discussion. So what is the decision/consensus? Leave as is, or add * to default settings for all, with a warning in the console log? On Fri, Nov 2, 2012 at 11:33 AM, Joe Bowser bows...@gmail.com wrote: On Fri, Nov 2, 2012 at 10:59 AM, Shazron shaz...@gmail.com wrote: Echoing Anis here. The easiest use case is for corporate use (internal), where any connections are restricted to a certain domain for paranoid IT types. I can see the case of us allowing everything _by default_ though (eg adding the '*'), which really should have been the default so as to be backwards compatible with how it was before the whitelist came in. The system could detect this sole wildcard entry, and print out a warning in the console log, as well as the documentation of course pointing this out -- the latter which we should have done in the first place. OK, that sounds cool, but does that mean that in six months, we're going to deprecate this behaviour and get more aggressive with the whitelist? BTW: In the event that the whitelist isn't found based on the code that I'm looking at here, Android should block everything and fire default web intents. If it's not doing this, that's a bug! When we refer to defaults, are we referring to the config.xml that we're circulating? Also, how are we testing this whitelisting feature? I can tell you that doing it in JS alone wouldn't be enough. Joe
Re: Whitelist defaults
I have relaxed my position, as I can work around whatever the choice is. It might be prudent to ask our users though. On Mon, Nov 5, 2012 at 3:22 PM, Anis KADRI anis.ka...@gmail.com wrote: I guess the consensus is to whitelist everything (*) all the time. My opinion is that there should be some dev mode where (*) is set and then a release mode where you'd specify your hosts. On Mon, Nov 5, 2012 at 3:11 PM, Shazron shaz...@gmail.com wrote: We've had the discussion. So what is the decision/consensus? Leave as is, or add * to default settings for all, with a warning in the console log? On Fri, Nov 2, 2012 at 11:33 AM, Joe Bowser bows...@gmail.com wrote: On Fri, Nov 2, 2012 at 10:59 AM, Shazron shaz...@gmail.com wrote: Echoing Anis here. The easiest use case is for corporate use (internal), where any connections are restricted to a certain domain for paranoid IT types. I can see the case of us allowing everything _by default_ though (eg adding the '*'), which really should have been the default so as to be backwards compatible with how it was before the whitelist came in. The system could detect this sole wildcard entry, and print out a warning in the console log, as well as the documentation of course pointing this out -- the latter which we should have done in the first place. OK, that sounds cool, but does that mean that in six months, we're going to deprecate this behaviour and get more aggressive with the whitelist? BTW: In the event that the whitelist isn't found based on the code that I'm looking at here, Android should block everything and fire default web intents. If it's not doing this, that's a bug! When we refer to defaults, are we referring to the config.xml that we're circulating? Also, how are we testing this whitelisting feature? I can tell you that doing it in JS alone wouldn't be enough. Joe -- @purplecabbage risingj.com
[jira] [Resolved] (CB-1809) `create` script should print out meaningful error messages
[
https://issues.apache.org/jira/browse/CB-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anis Kadri resolved CB-1809.
Resolution: Fixed
`create` script should print out meaningful error messages
--
Key: CB-1809
URL: https://issues.apache.org/jira/browse/CB-1809
Project: Apache Cordova
Issue Type: Bug
Components: Android
Affects Versions: 2.1.0, 2.2.0
Environment: Mac OS X 10.7.5
Reporter: Filip Maj
Assignee: Anis Kadri
I've been seeing people have issues with the {{./bin/create}} script.
Helping them out on IRC is tough as the generic error message always received
is:
There has been an error. Deleting project...
--
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] [Reopened] (CB-1794) `cordova` command line script(s) don't work with paths with spaces in them
[
https://issues.apache.org/jira/browse/CB-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anis Kadri reopened CB-1794:
`cordova` command line script(s) don't work with paths with spaces in them
--
Key: CB-1794
URL: https://issues.apache.org/jira/browse/CB-1794
Project: Apache Cordova
Issue Type: Bug
Components: Android
Affects Versions: 2.1.0
Environment: Mac OS X 10.7.5
Reporter: Filip Maj
Assignee: Anis Kadri
Fix For: 2.3.0
I run the following:
{code}
./bin/create foo bar
cd foo\ bar
./cordova/debug
{code}
I get:
{code}
bash: /Users/fil/src/incubator-cordova-android/foo: No such file or
directory
{code}
I believe the patch is to change the line:
{{cd PROJECT_PATH}}
.. in the {{debug}} and {{cordova}} scripts to:
{{cd PROJECT_PATH}}
--
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
