[jira] [Commented] (CB-13415) Importing corrupt images using the Camera plugin crashes the app
[ https://issues.apache.org/jira/browse/CB-13415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16387427#comment-16387427 ] ASF GitHub Bot commented on CB-13415: - alsorokin commented on issue #310: CB-13415 (iOS) Importing corrupt images using the Camera plugin crashes the app URL: https://github.com/apache/cordova-plugin-camera/pull/310#issuecomment-370690997 I'm not sure what you mean. it is failed here: https://travis-ci.org/apache/cordova-plugin-camera/jobs/334579377#L1781 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Importing corrupt images using the Camera plugin crashes the app > > > Key: CB-13415 > URL: https://issues.apache.org/jira/browse/CB-13415 > Project: Apache Cordova > Issue Type: Bug > Components: cordova-plugin-camera > Environment: Android: OS 7.0, Phone Model: Moto G5 Plus > iOS: OS 10.1.1 (14B150) >Reporter: Shemrick Flannigan >Priority: Critical > Labels: android, camera, cameraui, ios > > ISSUE > Importing corrupt images using the Camera plugin crashes the app > Current Behavior > # Importing a corrupt image using the Cordova Camera plugin crashes the > Cordova app which uses the plugin > Expected Behavior > # Importing a corrupt image using the Cordova Camera plugin: > #* Throws an exception which can be caught by the Cordova app which uses the > plugin > #* Does not crash the Cordova app which uses the plugin > #* Allows the Cordova app which uses the plugin to render a Toast error > message relaying the error > # # Platforms affected > #* Android > #* iOS > REFERENCES > # [Sample corrupt image which crashes the app | > https://www.dropbox.com/s/e7dz007svtvscbc/Corrupt_Image_4.7MB_13500x13500.D2.jpg?dl=0] > # [Technique used to wrap the call in a Try/Catch block in a callable inner > class to prevent an app crash | > https://stackoverflow.com/questions/19183174/phonegap-video-capture-crashes] > ADDITIONAL INFORMATION > # Importing corrupt images does not crash apps which do not use the Camera > plugin, such as: > #* Yelp mobile app > #* Slack mobile app -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-13415) Importing corrupt images using the Camera plugin crashes the app
[ https://issues.apache.org/jira/browse/CB-13415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16387395#comment-16387395 ] ASF GitHub Bot commented on CB-13415: - jd0048 commented on issue #310: CB-13415 (iOS) Importing corrupt images using the Camera plugin crashes the app URL: https://github.com/apache/cordova-plugin-camera/pull/310#issuecomment-370684973 But this iOS test already passed. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Importing corrupt images using the Camera plugin crashes the app > > > Key: CB-13415 > URL: https://issues.apache.org/jira/browse/CB-13415 > Project: Apache Cordova > Issue Type: Bug > Components: cordova-plugin-camera > Environment: Android: OS 7.0, Phone Model: Moto G5 Plus > iOS: OS 10.1.1 (14B150) >Reporter: Shemrick Flannigan >Priority: Critical > Labels: android, camera, cameraui, ios > > ISSUE > Importing corrupt images using the Camera plugin crashes the app > Current Behavior > # Importing a corrupt image using the Cordova Camera plugin crashes the > Cordova app which uses the plugin > Expected Behavior > # Importing a corrupt image using the Cordova Camera plugin: > #* Throws an exception which can be caught by the Cordova app which uses the > plugin > #* Does not crash the Cordova app which uses the plugin > #* Allows the Cordova app which uses the plugin to render a Toast error > message relaying the error > # # Platforms affected > #* Android > #* iOS > REFERENCES > # [Sample corrupt image which crashes the app | > https://www.dropbox.com/s/e7dz007svtvscbc/Corrupt_Image_4.7MB_13500x13500.D2.jpg?dl=0] > # [Technique used to wrap the call in a Try/Catch block in a callable inner > class to prevent an app crash | > https://stackoverflow.com/questions/19183174/phonegap-video-capture-crashes] > ADDITIONAL INFORMATION > # Importing corrupt images does not crash apps which do not use the Camera > plugin, such as: > #* Yelp mobile app > #* Slack mobile app -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-13415) Importing corrupt images using the Camera plugin crashes the app
[ https://issues.apache.org/jira/browse/CB-13415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16387393#comment-16387393 ] ASF GitHub Bot commented on CB-13415: - alsorokin commented on issue #310: CB-13415 (iOS) Importing corrupt images using the Camera plugin crashes the app URL: https://github.com/apache/cordova-plugin-camera/pull/310#issuecomment-370684736 This is the line that is failing: https://github.com/apache/cordova-plugin-camera/blob/master/tests/ios/CDVCameraTest/CDVCameraLibTests/CameraTest.m#L481 Hope that helps :) This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Importing corrupt images using the Camera plugin crashes the app > > > Key: CB-13415 > URL: https://issues.apache.org/jira/browse/CB-13415 > Project: Apache Cordova > Issue Type: Bug > Components: cordova-plugin-camera > Environment: Android: OS 7.0, Phone Model: Moto G5 Plus > iOS: OS 10.1.1 (14B150) >Reporter: Shemrick Flannigan >Priority: Critical > Labels: android, camera, cameraui, ios > > ISSUE > Importing corrupt images using the Camera plugin crashes the app > Current Behavior > # Importing a corrupt image using the Cordova Camera plugin crashes the > Cordova app which uses the plugin > Expected Behavior > # Importing a corrupt image using the Cordova Camera plugin: > #* Throws an exception which can be caught by the Cordova app which uses the > plugin > #* Does not crash the Cordova app which uses the plugin > #* Allows the Cordova app which uses the plugin to render a Toast error > message relaying the error > # # Platforms affected > #* Android > #* iOS > REFERENCES > # [Sample corrupt image which crashes the app | > https://www.dropbox.com/s/e7dz007svtvscbc/Corrupt_Image_4.7MB_13500x13500.D2.jpg?dl=0] > # [Technique used to wrap the call in a Try/Catch block in a callable inner > class to prevent an app crash | > https://stackoverflow.com/questions/19183174/phonegap-video-capture-crashes] > ADDITIONAL INFORMATION > # Importing corrupt images does not crash apps which do not use the Camera > plugin, such as: > #* Yelp mobile app > #* Slack mobile app -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-13415) Importing corrupt images using the Camera plugin crashes the app
[ https://issues.apache.org/jira/browse/CB-13415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16387386#comment-16387386 ] ASF GitHub Bot commented on CB-13415: - jd0048 commented on issue #310: CB-13415 (iOS) Importing corrupt images using the Camera plugin crashes the app URL: https://github.com/apache/cordova-plugin-camera/pull/310#issuecomment-370683793 How can i do that? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Importing corrupt images using the Camera plugin crashes the app > > > Key: CB-13415 > URL: https://issues.apache.org/jira/browse/CB-13415 > Project: Apache Cordova > Issue Type: Bug > Components: cordova-plugin-camera > Environment: Android: OS 7.0, Phone Model: Moto G5 Plus > iOS: OS 10.1.1 (14B150) >Reporter: Shemrick Flannigan >Priority: Critical > Labels: android, camera, cameraui, ios > > ISSUE > Importing corrupt images using the Camera plugin crashes the app > Current Behavior > # Importing a corrupt image using the Cordova Camera plugin crashes the > Cordova app which uses the plugin > Expected Behavior > # Importing a corrupt image using the Cordova Camera plugin: > #* Throws an exception which can be caught by the Cordova app which uses the > plugin > #* Does not crash the Cordova app which uses the plugin > #* Allows the Cordova app which uses the plugin to render a Toast error > message relaying the error > # # Platforms affected > #* Android > #* iOS > REFERENCES > # [Sample corrupt image which crashes the app | > https://www.dropbox.com/s/e7dz007svtvscbc/Corrupt_Image_4.7MB_13500x13500.D2.jpg?dl=0] > # [Technique used to wrap the call in a Try/Catch block in a callable inner > class to prevent an app crash | > https://stackoverflow.com/questions/19183174/phonegap-video-capture-crashes] > ADDITIONAL INFORMATION > # Importing corrupt images does not crash apps which do not use the Camera > plugin, such as: > #* Yelp mobile app > #* Slack mobile app -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-13415) Importing corrupt images using the Camera plugin crashes the app
[ https://issues.apache.org/jira/browse/CB-13415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16387383#comment-16387383 ] ASF GitHub Bot commented on CB-13415: - alsorokin commented on issue #310: CB-13415 (iOS) Importing corrupt images using the Camera plugin crashes the app URL: https://github.com/apache/cordova-plugin-camera/pull/310#issuecomment-370683593 I see. Well, If you've changed the function signature, I guess you should also change the test to pass that new argument to it. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Importing corrupt images using the Camera plugin crashes the app > > > Key: CB-13415 > URL: https://issues.apache.org/jira/browse/CB-13415 > Project: Apache Cordova > Issue Type: Bug > Components: cordova-plugin-camera > Environment: Android: OS 7.0, Phone Model: Moto G5 Plus > iOS: OS 10.1.1 (14B150) >Reporter: Shemrick Flannigan >Priority: Critical > Labels: android, camera, cameraui, ios > > ISSUE > Importing corrupt images using the Camera plugin crashes the app > Current Behavior > # Importing a corrupt image using the Cordova Camera plugin crashes the > Cordova app which uses the plugin > Expected Behavior > # Importing a corrupt image using the Cordova Camera plugin: > #* Throws an exception which can be caught by the Cordova app which uses the > plugin > #* Does not crash the Cordova app which uses the plugin > #* Allows the Cordova app which uses the plugin to render a Toast error > message relaying the error > # # Platforms affected > #* Android > #* iOS > REFERENCES > # [Sample corrupt image which crashes the app | > https://www.dropbox.com/s/e7dz007svtvscbc/Corrupt_Image_4.7MB_13500x13500.D2.jpg?dl=0] > # [Technique used to wrap the call in a Try/Catch block in a callable inner > class to prevent an app crash | > https://stackoverflow.com/questions/19183174/phonegap-video-capture-crashes] > ADDITIONAL INFORMATION > # Importing corrupt images does not crash apps which do not use the Camera > plugin, such as: > #* Yelp mobile app > #* Slack mobile app -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-13943) ERR_FILE_NOT_FOUND — deep linking issue
[ https://issues.apache.org/jira/browse/CB-13943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16387356#comment-16387356 ] Arthur Mudrick commented on CB-13943: - Well, no, this is Cordova issue — those screenshots with alerts are from Cordova, not Angular — Angular is even not started at that moment. This is Cordova who tries to find `/login` folder and throws an error. > ERR_FILE_NOT_FOUND — deep linking issue > --- > > Key: CB-13943 > URL: https://issues.apache.org/jira/browse/CB-13943 > Project: Apache Cordova > Issue Type: Bug > Environment: Android — any > Cordova — 6.5.0 >Reporter: Arthur Mudrick >Priority: Major > Attachments: > Screenshot_2018-02-28-15-18-50-964_ru.balumates.balu.png, > Screenshot_2018-02-28-15-55-56-348_ru.balumates.balu.png > > > I use Angular with Cordova. Angular uses URL routing, e.g. `/login` for the > Login page, '/settings' for the Settings page, etc. > When Android application updates (when new application version is installed) > Cordova is like «reloads» itself or something, but the path in the address > bar was `/login` or `/users` or `/settings` etc., so, Cordova thinks it is a > folder. > Cordova throws an error — see screenshot #1 — there is a path `/www/login` > but the `/login` is just Angular's routing, not a folder to search for :) > I also tried to make Angular work with hashbang url strategy, e.g. `/#/login` > rather than `/login` — it throws another error, see screenshot #2. > So, basically Cordova behaves like a server without the `mod_rewrite` option > — it tries to find folders inside the `/www` folder. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-13415) Importing corrupt images using the Camera plugin crashes the app
[ https://issues.apache.org/jira/browse/CB-13415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16387336#comment-16387336 ] ASF GitHub Bot commented on CB-13415: - jd0048 commented on issue #310: CB-13415 (iOS) Importing corrupt images using the Camera plugin crashes the app URL: https://github.com/apache/cordova-plugin-camera/pull/310#issuecomment-370672903 @alsorokin i think its not expected, iOS test already passed This error comes because of **TEST_DIR=./tests/ios** in this test its referring old signature of function. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Importing corrupt images using the Camera plugin crashes the app > > > Key: CB-13415 > URL: https://issues.apache.org/jira/browse/CB-13415 > Project: Apache Cordova > Issue Type: Bug > Components: cordova-plugin-camera > Environment: Android: OS 7.0, Phone Model: Moto G5 Plus > iOS: OS 10.1.1 (14B150) >Reporter: Shemrick Flannigan >Priority: Critical > Labels: android, camera, cameraui, ios > > ISSUE > Importing corrupt images using the Camera plugin crashes the app > Current Behavior > # Importing a corrupt image using the Cordova Camera plugin crashes the > Cordova app which uses the plugin > Expected Behavior > # Importing a corrupt image using the Cordova Camera plugin: > #* Throws an exception which can be caught by the Cordova app which uses the > plugin > #* Does not crash the Cordova app which uses the plugin > #* Allows the Cordova app which uses the plugin to render a Toast error > message relaying the error > # # Platforms affected > #* Android > #* iOS > REFERENCES > # [Sample corrupt image which crashes the app | > https://www.dropbox.com/s/e7dz007svtvscbc/Corrupt_Image_4.7MB_13500x13500.D2.jpg?dl=0] > # [Technique used to wrap the call in a Try/Catch block in a callable inner > class to prevent an app crash | > https://stackoverflow.com/questions/19183174/phonegap-video-capture-crashes] > ADDITIONAL INFORMATION > # Importing corrupt images does not crash apps which do not use the Camera > plugin, such as: > #* Yelp mobile app > #* Slack mobile app -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-13415) Importing corrupt images using the Camera plugin crashes the app
[ https://issues.apache.org/jira/browse/CB-13415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16387333#comment-16387333 ] ASF GitHub Bot commented on CB-13415: - alsorokin commented on issue #310: CB-13415 (iOS) Importing corrupt images using the Camera plugin crashes the app URL: https://github.com/apache/cordova-plugin-camera/pull/310#issuecomment-370671870 I've tried restarting tests and it's still there This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Importing corrupt images using the Camera plugin crashes the app > > > Key: CB-13415 > URL: https://issues.apache.org/jira/browse/CB-13415 > Project: Apache Cordova > Issue Type: Bug > Components: cordova-plugin-camera > Environment: Android: OS 7.0, Phone Model: Moto G5 Plus > iOS: OS 10.1.1 (14B150) >Reporter: Shemrick Flannigan >Priority: Critical > Labels: android, camera, cameraui, ios > > ISSUE > Importing corrupt images using the Camera plugin crashes the app > Current Behavior > # Importing a corrupt image using the Cordova Camera plugin crashes the > Cordova app which uses the plugin > Expected Behavior > # Importing a corrupt image using the Cordova Camera plugin: > #* Throws an exception which can be caught by the Cordova app which uses the > plugin > #* Does not crash the Cordova app which uses the plugin > #* Allows the Cordova app which uses the plugin to render a Toast error > message relaying the error > # # Platforms affected > #* Android > #* iOS > REFERENCES > # [Sample corrupt image which crashes the app | > https://www.dropbox.com/s/e7dz007svtvscbc/Corrupt_Image_4.7MB_13500x13500.D2.jpg?dl=0] > # [Technique used to wrap the call in a Try/Catch block in a callable inner > class to prevent an app crash | > https://stackoverflow.com/questions/19183174/phonegap-video-capture-crashes] > ADDITIONAL INFORMATION > # Importing corrupt images does not crash apps which do not use the Camera > plugin, such as: > #* Yelp mobile app > #* Slack mobile app -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-13415) Importing corrupt images using the Camera plugin crashes the app
[ https://issues.apache.org/jira/browse/CB-13415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16387331#comment-16387331 ] ASF GitHub Bot commented on CB-13415: - alsorokin commented on issue #310: CB-13415 (iOS) Importing corrupt images using the Camera plugin crashes the app URL: https://github.com/apache/cordova-plugin-camera/pull/310#issuecomment-370671665 There's still one test failure, is it expected? ``` Test Case '-[CameraTest testProcessImage]' started. 2018-02-28 14:10:55.751 xctest[2330:8469] -[CDVCamera processImage:info:options:]: unrecognized selector sent to instance 0x7976c770 /Users/travis/build/apache/cordova-plugin-camera/tests/ios/CDVCameraTest/CDVCameraLibTests/CameraTest.m:481: error: -[CameraTest testProcessImage] : failed: caught "NSInvalidArgumentException", "-[CDVCamera processImage:info:options:]: unrecognized selector sent to instance 0x7976c770" ( 0 CoreFoundation 0x00c96ded __exceptionPreprocess + 189 1 libobjc.A.dylib 0x00761d6f objc_exception_throw + 49 2 CoreFoundation 0x00d085b8 -[NSObject(NSObject) doesNotRecognizeSelector:] + 136 3 CoreFoundation 0x00c1ca8d ___forwarding___ + 941 4 CoreFoundation 0x00c1c6be _CF_forwarding_prep_0 + 14 5 CDVCameraLibTests 0x0edb4568 -[CameraTest testProcessImage] + 648 6 CoreFoundation 0x00c1df4d __invoking___ + 29 7 CoreFoundation 0x00c1de81 -[NSInvocation invoke] + 321 8 XCTest 0x0066442b __24-[XCTestCase invokeTest]_block_invoke_2 + 502 9 XCTest 0x006a4b0a -[XCTestContext performInScope:] + 229 10 XCTest 0x00664228 -[XCTestCase invokeTest] + 259 11 XCTest 0x00664bc5 -[XCTestCase performTest:] + 621 12 XCTest 0x006949b7 -[XCTest runTest] + 45 13 XCTest 0x00661a39 __27-[XCTestSuite performTest:]_block_invoke + 258 14 XCTest 0x0066160b -[XCTestSuite _performProtectedSectionForTest:testSection:] + 32 15 XCTest 0x0066181b -[XCTestSuite performTest:] + 213 16 XCTest 0x006949b7 -[XCTest runTest] + 45 17 XCTest 0x00661a39 __27-[XCTestSuite performTest:]_block_invoke + 258 18 XCTest 0x0066160b -[XCTestSuite _performProtectedSectionForTest:testSection:] + 32 19 XCTest 0x0066181b -[XCTestSuite performTest:] + 213 20 XCTest 0x006949b7 -[XCTest runTest] + 45 21 XCTest 0x00661a39 __27-[XCTestSuite performTest:]_block_invoke + 258 22 XCTest 0x0066160b -[XCTestSuite _performProtectedSectionForTest:testSection:] + 32 23 XCTest 0x0066181b -[XCTestSuite performTest:] + 213 24 XCTest 0x006949b7 -[XCTest runTest] + 45 25 XCTest 0x006b0bdf __44-[XCTTestRunSession runTestsAndReturnError:]_block_invoke + 52 26 XCTest 0x00671af7 -[XCTestObservationCenter _observeTestExecutionForBlock:] + 699 27 XCTest 0x006b0a72 -[XCTTestRunSession runTestsAndReturnError:] + 295 28 XCTest 0x0064be10 -[XCTestDriver runTestsAndReturnError:] + 255 29 XCTest 0x006a83a1 _XCTestMain + 790 30 xctest 0x0008bab2 xctest + 6834 31 libdyld.dylib 0x020e6779 start + 1 ) Test Case '-[CameraTest testProcessImage]' failed (0.229 seconds).Test Case '-[CameraTest testProcessImage]' started. 2018-02-28 14:10:55.751 xctest[2330:8469] -[CDVCamera processImage:info:options:]: unrecognized selector sent to instance 0x7976c770 /Users/travis/build/apache/cordova-plugin-camera/tests/ios/CDVCameraTest/CDVCameraLibTests/CameraTest.m:481: error: -[CameraTest testProcessImage] : failed: caught "NSInvalidArgumentException", "-[CDVCamera processImage:info:options:]: unrecognized selector sent to instance 0x7976c770" ( 0 CoreFoundation 0x00c96ded __exceptionPreprocess + 189 1 libobjc.A.dylib 0x00761d6f objc_exception_throw + 49 2 CoreFoundation 0x00d085b8 -[NSObject(NSObject) doesNotRecognizeSelector:] + 136 3 CoreFoundation
[jira] [Commented] (CB-13415) Importing corrupt images using the Camera plugin crashes the app
[ https://issues.apache.org/jira/browse/CB-13415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16387332#comment-16387332 ] ASF GitHub Bot commented on CB-13415: - alsorokin commented on issue #310: CB-13415 (iOS) Importing corrupt images using the Camera plugin crashes the app URL: https://github.com/apache/cordova-plugin-camera/pull/310#issuecomment-370671665 There's still one test failure, is it expected? ``` Test Case '-[CameraTest testProcessImage]' started. 2018-02-28 14:10:55.751 xctest[2330:8469] -[CDVCamera processImage:info:options:]: unrecognized selector sent to instance 0x7976c770 /Users/travis/build/apache/cordova-plugin-camera/tests/ios/CDVCameraTest/CDVCameraLibTests/CameraTest.m:481: error: -[CameraTest testProcessImage] : failed: caught "NSInvalidArgumentException", "-[CDVCamera processImage:info:options:]: unrecognized selector sent to instance 0x7976c770" ( 0 CoreFoundation 0x00c96ded __exceptionPreprocess + 189 1 libobjc.A.dylib 0x00761d6f objc_exception_throw + 49 2 CoreFoundation 0x00d085b8 -[NSObject(NSObject) doesNotRecognizeSelector:] + 136 3 CoreFoundation 0x00c1ca8d ___forwarding___ + 941 4 CoreFoundation 0x00c1c6be _CF_forwarding_prep_0 + 14 5 CDVCameraLibTests 0x0edb4568 -[CameraTest testProcessImage] + 648 6 CoreFoundation 0x00c1df4d __invoking___ + 29 7 CoreFoundation 0x00c1de81 -[NSInvocation invoke] + 321 8 XCTest 0x0066442b __24-[XCTestCase invokeTest]_block_invoke_2 + 502 9 XCTest 0x006a4b0a -[XCTestContext performInScope:] + 229 10 XCTest 0x00664228 -[XCTestCase invokeTest] + 259 11 XCTest 0x00664bc5 -[XCTestCase performTest:] + 621 12 XCTest 0x006949b7 -[XCTest runTest] + 45 13 XCTest 0x00661a39 __27-[XCTestSuite performTest:]_block_invoke + 258 14 XCTest 0x0066160b -[XCTestSuite _performProtectedSectionForTest:testSection:] + 32 15 XCTest 0x0066181b -[XCTestSuite performTest:] + 213 16 XCTest 0x006949b7 -[XCTest runTest] + 45 17 XCTest 0x00661a39 __27-[XCTestSuite performTest:]_block_invoke + 258 18 XCTest 0x0066160b -[XCTestSuite _performProtectedSectionForTest:testSection:] + 32 19 XCTest 0x0066181b -[XCTestSuite performTest:] + 213 20 XCTest 0x006949b7 -[XCTest runTest] + 45 21 XCTest 0x00661a39 __27-[XCTestSuite performTest:]_block_invoke + 258 22 XCTest 0x0066160b -[XCTestSuite _performProtectedSectionForTest:testSection:] + 32 23 XCTest 0x0066181b -[XCTestSuite performTest:] + 213 24 XCTest 0x006949b7 -[XCTest runTest] + 45 25 XCTest 0x006b0bdf __44-[XCTTestRunSession runTestsAndReturnError:]_block_invoke + 52 26 XCTest 0x00671af7 -[XCTestObservationCenter _observeTestExecutionForBlock:] + 699 27 XCTest 0x006b0a72 -[XCTTestRunSession runTestsAndReturnError:] + 295 28 XCTest 0x0064be10 -[XCTestDriver runTestsAndReturnError:] + 255 29 XCTest 0x006a83a1 _XCTestMain + 790 30 xctest 0x0008bab2 xctest + 6834 31 libdyld.dylib 0x020e6779 start + 1 ) Test Case '-[CameraTest testProcessImage]' failed (0.229 seconds). ``` This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Importing corrupt images using the Camera plugin crashes the app > > > Key: CB-13415 > URL: https://issues.apache.org/jira/browse/CB-13415 > Project: Apache Cordova > Issue Type: Bug > Components: cordova-plugin-camera > Environment: Android: OS 7.0, Phone Model: Moto G5 Plus > iOS: OS 10.1.1 (14B150) >Reporter: Shemrick Flannigan >
[jira] [Commented] (CB-13944) Why isn't the "platforms" documentation not the README of the platform repositories and pulled into the docs?
[ https://issues.apache.org/jira/browse/CB-13944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16387321#comment-16387321 ] Dmitry Blotsky commented on CB-13944: - [~Sujan12] yep, it would be a challenge. I think both approaches are roughly equally ok: putting it in a README, or just keeping it separate (like it is right now). > Why isn't the "platforms" documentation not the README of the platform > repositories and pulled into the docs? > - > > Key: CB-13944 > URL: https://issues.apache.org/jira/browse/CB-13944 > Project: Apache Cordova > Issue Type: Improvement > Components: cordova-docs >Reporter: Jan Piotrowski (Sujan) >Priority: Major > > The version of the platform that is installed is hard coded in the CLI. > Wouldn't it make sense to move the "platform" documentation to the README of > the platform itself and only pull in this file (like the docs already do with > plugins) so there is some connection to the actual version? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-13946) How to deal with pages that are missing in this new version of the docs?
[
https://issues.apache.org/jira/browse/CB-13946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16387320#comment-16387320
]
Dmitry Blotsky commented on CB-13946:
-
[~Sujan12] yep, I think we can fix them in {{dev}}.
> How to deal with pages that are missing in this new version of the docs?
>
>
> Key: CB-13946
> URL: https://issues.apache.org/jira/browse/CB-13946
> Project: Apache Cordova
> Issue Type: Improvement
> Components: cordova-docs
>Reporter: Jan Piotrowski (Sujan)
>Priority: Major
>
> There are multiple broken links in the `dev` version of the docs that link to
> pages that used to be there but are not in the current version.
> Examples:
> - /docs/en/dev/guide/platforms/ios/upgrade.html links to
> /docs/en/dev/guide/platforms/ios/tools.html in multiple places
> - /docs/en/dev/guide/platforms/windows/index.html (used to be
> /docs/en/dev/guide/platforms/win8/index.html) links to
> /docs/en/dev/guide/platforms/wp8/index.html
> How can and should those be handled?
> The content still exists, but in older versions :/
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-13940) / vs. /index.html
[ https://issues.apache.org/jira/browse/CB-13940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16387318#comment-16387318 ] Dmitry Blotsky commented on CB-13940: - [~Sujan12] so would this just need a content change? Sounds good to me, if so. > / vs. /index.html > - > > Key: CB-13940 > URL: https://issues.apache.org/jira/browse/CB-13940 > Project: Apache Cordova > Issue Type: Bug > Components: cordova-docs >Reporter: Jan Piotrowski (Sujan) >Priority: Major > > Right now the docs are a mishmash of linking to `folder/` and > `folder/index.html`. > http://cordova.apache.org/docs/en/dev/guide/appdev/privacy/index.html > http://cordova.apache.org/docs/en/dev/guide/appdev/privacy/ > http://cordova.apache.org/docs/en/dev/reference/cordova-plugin-dialogs/index.html > http://cordova.apache.org/docs/en/dev/reference/cordova-plugin-dialogs/ > Both are of course totally valid - we just have to standardize on one and use > it everywhere, if possible also create a redirect rule for all "broken" links > to use the one standard we define. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-13801) Fail to restore plugins with relative path
[
https://issues.apache.org/jira/browse/CB-13801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16387102#comment-16387102
]
Michael Goffioul commented on CB-13801:
---
FYI, there's quite a list of similar problems reported (CB-13637, CB-13503,
CB-13589, CB-12918) going back as far as June 2017. Unfortunately, it doesn't
look like it'll be fixed anytime soon. A (dirty) workaround that works for me
with cordova@8 is to define the plugin specs in config.xml (without 'file:'
prefix), but not in package.json.
> Fail to restore plugins with relative path
> --
>
> Key: CB-13801
> URL: https://issues.apache.org/jira/browse/CB-13801
> Project: Apache Cordova
> Issue Type: Bug
> Components: cordova-lib
>Reporter: Michael Goffioul
>Priority: Major
>
> 1. Create a cordova project
> 2. Add android platform
> 3. Add a local plugin using a relative path: {{cordova plugin add
> myplugins/testplugin}}
> 4. Delete directories platforms/ and plugins/
> 5. Prepare android: {{cordova prepare android}}
> Cordova will fail to restore the local plugin. The plugin has been added to
> {{package.json}} using the spec {{file:myplugins/testplugin}} and the
> restoration utility is unable to handle such URL. Note that {{config.xml}}
> contains the spec {{myplugins/testplugin}} (that is, without the file:
> scheme), but the one in {{package.json}} takes precedence.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Updated] (CB-13954) NullPointerException when processing result from camera
[
https://issues.apache.org/jira/browse/CB-13954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brad Zacher updated CB-13954:
-
Description:
I have gotten a number of crash reports via the google play console for a null
pointer exception (see below for stack).
Looking at the source code, it seems to be a problem when attempting to access
the extras from the intent - the problem being that the extras return null
(which the code doesn't expect):
[https://github.com/apache/cordova-plugin-camera/blob/e36482c7ba1e5dec07f68a246f3ecde8743d7cd6/src/android/CameraLauncher.java#L516]
*java.lang.RuntimeException:*
at android.app.ActivityThread.deliverResults (ActivityThread.java:4520)
at android.app.ActivityThread.handleSendResult (ActivityThread.java:4563)
at android.app.ActivityThread.-wrap22 (ActivityThread.java)
at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1698)
at android.os.Handler.dispatchMessage (Handler.java:102)
at android.os.Looper.loop (Looper.java:154)
at android.app.ActivityThread.main (ActivityThread.java:6776)
at java.lang.reflect.Method.invoke (Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run
(ZygoteInit.java:1520)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1410)
*Caused by: java.lang.NullPointerException:*
at org.apache.cordova.camera.CameraLauncher.processResultFromCamera
(CameraLauncher.java:514)
at org.apache.cordova.camera.CameraLauncher.onActivityResult
(CameraLauncher.java:805)
at org.apache.cordova.CordovaInterfaceImpl.onActivityResult
(CordovaInterfaceImpl.java:152)
at org.apache.cordova.CordovaActivity.onActivityResult
(CordovaActivity.java:358)
at android.app.Activity.dispatchActivityResult (Activity.java:7282)
at android.app.ActivityThread.deliverResults (ActivityThread.java:4516)
was:
I have gotten a number of crash reports via the google play console for a null
pointer exception (see below for stack).
Looking at the source code, it seems to be a problem when attempting to access
the extras from the intent - the problem being that the extras return null
(which the code doesn't expect):
[https://github.com/apache/cordova-plugin-camera/blob/e36482c7ba1e5dec07f68a246f3ecde8743d7cd6/src/android/CameraLauncher.java#L516]
{{java.lang.RuntimeException:
at android.app.ActivityThread.deliverResults (ActivityThread.java:4520)
at android.app.ActivityThread.handleSendResult (ActivityThread.java:4563)
at android.app.ActivityThread.-wrap22 (ActivityThread.java)
at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1698)
at android.os.Handler.dispatchMessage (Handler.java:102)
at android.os.Looper.loop (Looper.java:154)
at android.app.ActivityThread.main (ActivityThread.java:6776)
at java.lang.reflect.Method.invoke (Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run
(ZygoteInit.java:1520)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1410)
Caused by: java.lang.NullPointerException:
at org.apache.cordova.camera.CameraLauncher.processResultFromCamera
(CameraLauncher.java:514)
at org.apache.cordova.camera.CameraLauncher.onActivityResult
(CameraLauncher.java:805)
at org.apache.cordova.CordovaInterfaceImpl.onActivityResult
(CordovaInterfaceImpl.java:152)
at org.apache.cordova.CordovaActivity.onActivityResult
(CordovaActivity.java:358)
at android.app.Activity.dispatchActivityResult (Activity.java:7282)
at android.app.ActivityThread.deliverResults (ActivityThread.java:4516)}}
> NullPointerException when processing result from camera
> ---
>
> Key: CB-13954
> URL: https://issues.apache.org/jira/browse/CB-13954
> Project: Apache Cordova
> Issue Type: Bug
> Components: cordova-plugin-camera
>Reporter: Brad Zacher
>Priority: Major
>
> I have gotten a number of crash reports via the google play console for a
> null pointer exception (see below for stack).
> Looking at the source code, it seems to be a problem when attempting to
> access the extras from the intent - the problem being that the extras return
> null (which the code doesn't expect):
> [https://github.com/apache/cordova-plugin-camera/blob/e36482c7ba1e5dec07f68a246f3ecde8743d7cd6/src/android/CameraLauncher.java#L516]
>
> *java.lang.RuntimeException:*
> at android.app.ActivityThread.deliverResults (ActivityThread.java:4520)
> at android.app.ActivityThread.handleSendResult (ActivityThread.java:4563)
> at android.app.ActivityThread.-wrap22 (ActivityThread.java)
> at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1698)
> at android.os.Handler.dispatchMessage (Handler.java:102)
> at android.os.Looper.loop (Looper.java:154)
> at android.app.ActivityThread.main (ActivityThread.java:6776)
> at
[jira] [Updated] (CB-13954) NullPointerException when processing result from camera
[
https://issues.apache.org/jira/browse/CB-13954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brad Zacher updated CB-13954:
-
Description:
I have gotten a number of crash reports via the google play console for a null
pointer exception (see below for stack).
Looking at the source code, it seems to be a problem when attempting to access
the extras from the intent - the problem being that the extras return null
(which the code doesn't expect):
[https://github.com/apache/cordova-plugin-camera/blob/e36482c7ba1e5dec07f68a246f3ecde8743d7cd6/src/android/CameraLauncher.java#L516]
{{
java.lang.RuntimeException:
at android.app.ActivityThread.deliverResults (ActivityThread.java:4520)
at android.app.ActivityThread.handleSendResult (ActivityThread.java:4563)
at android.app.ActivityThread.-wrap22 (ActivityThread.java)
at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1698)
at android.os.Handler.dispatchMessage (Handler.java:102)
at android.os.Looper.loop (Looper.java:154)
at android.app.ActivityThread.main (ActivityThread.java:6776)
at java.lang.reflect.Method.invoke (Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run
(ZygoteInit.java:1520)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1410)
Caused by: java.lang.NullPointerException:
at org.apache.cordova.camera.CameraLauncher.processResultFromCamera
(CameraLauncher.java:514)
at org.apache.cordova.camera.CameraLauncher.onActivityResult
(CameraLauncher.java:805)
at org.apache.cordova.CordovaInterfaceImpl.onActivityResult
(CordovaInterfaceImpl.java:152)
at org.apache.cordova.CordovaActivity.onActivityResult
(CordovaActivity.java:358)
at android.app.Activity.dispatchActivityResult (Activity.java:7282)
at android.app.ActivityThread.deliverResults (ActivityThread.java:4516)
}}
was:
I have gotten a number of crash reports via the google play console for a null
pointer exception (see below for stack).
Looking at the source code, it seems to be a problem when attempting to access
the extras from the intent - the problem being that the extras return null
(which the code doesn't expect):
https://github.com/apache/cordova-plugin-camera/blob/e36482c7ba1e5dec07f68a246f3ecde8743d7cd6/src/android/CameraLauncher.java#L516
{{*java.lang.RuntimeException:* }}
{{ at android.app.ActivityThread.deliverResults (ActivityThread.java:4520)}}
{{ at android.app.ActivityThread.handleSendResult (ActivityThread.java:4563)}}
{{ at android.app.ActivityThread.-wrap22 (ActivityThread.java)}}
{{ at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1698)}}
{{ at android.os.Handler.dispatchMessage (Handler.java:102)}}
{{ at android.os.Looper.loop (Looper.java:154)}}
{{ at android.app.ActivityThread.main (ActivityThread.java:6776)}}
{{ at java.lang.reflect.Method.invoke (Native Method)}}
{{ at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run
(ZygoteInit.java:1520)}}
{{ at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1410)}}
{{*Caused by: java.lang.NullPointerException:* }}
{{ at org.apache.cordova.camera.CameraLauncher.processResultFromCamera
(CameraLauncher.java:514)}}
{{ at org.apache.cordova.camera.CameraLauncher.onActivityResult
(CameraLauncher.java:805)}}
{{ at org.apache.cordova.CordovaInterfaceImpl.onActivityResult
(CordovaInterfaceImpl.java:152)}}
{{ at org.apache.cordova.CordovaActivity.onActivityResult
(CordovaActivity.java:358)}}
{{ at android.app.Activity.dispatchActivityResult (Activity.java:7282)}}
{{ at android.app.ActivityThread.deliverResults (ActivityThread.java:4516)}}
> NullPointerException when processing result from camera
> ---
>
> Key: CB-13954
> URL: https://issues.apache.org/jira/browse/CB-13954
> Project: Apache Cordova
> Issue Type: Bug
> Components: cordova-plugin-camera
>Reporter: Brad Zacher
>Priority: Major
>
> I have gotten a number of crash reports via the google play console for a
> null pointer exception (see below for stack).
> Looking at the source code, it seems to be a problem when attempting to
> access the extras from the intent - the problem being that the extras return
> null (which the code doesn't expect):
> [https://github.com/apache/cordova-plugin-camera/blob/e36482c7ba1e5dec07f68a246f3ecde8743d7cd6/src/android/CameraLauncher.java#L516]
>
> {{
> java.lang.RuntimeException:
> at android.app.ActivityThread.deliverResults (ActivityThread.java:4520)
> at android.app.ActivityThread.handleSendResult (ActivityThread.java:4563)
> at android.app.ActivityThread.-wrap22 (ActivityThread.java)
> at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1698)
> at android.os.Handler.dispatchMessage (Handler.java:102)
> at android.os.Looper.loop (Looper.java:154)
> at
[jira] [Updated] (CB-13954) NullPointerException when processing result from camera
[
https://issues.apache.org/jira/browse/CB-13954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brad Zacher updated CB-13954:
-
Description:
I have gotten a number of crash reports via the google play console for a null
pointer exception (see below for stack).
Looking at the source code, it seems to be a problem when attempting to access
the extras from the intent - the problem being that the extras return null
(which the code doesn't expect):
[https://github.com/apache/cordova-plugin-camera/blob/e36482c7ba1e5dec07f68a246f3ecde8743d7cd6/src/android/CameraLauncher.java#L516]
{{java.lang.RuntimeException:
at android.app.ActivityThread.deliverResults (ActivityThread.java:4520)
at android.app.ActivityThread.handleSendResult (ActivityThread.java:4563)
at android.app.ActivityThread.-wrap22 (ActivityThread.java)
at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1698)
at android.os.Handler.dispatchMessage (Handler.java:102)
at android.os.Looper.loop (Looper.java:154)
at android.app.ActivityThread.main (ActivityThread.java:6776)
at java.lang.reflect.Method.invoke (Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run
(ZygoteInit.java:1520)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1410)
Caused by: java.lang.NullPointerException:
at org.apache.cordova.camera.CameraLauncher.processResultFromCamera
(CameraLauncher.java:514)
at org.apache.cordova.camera.CameraLauncher.onActivityResult
(CameraLauncher.java:805)
at org.apache.cordova.CordovaInterfaceImpl.onActivityResult
(CordovaInterfaceImpl.java:152)
at org.apache.cordova.CordovaActivity.onActivityResult
(CordovaActivity.java:358)
at android.app.Activity.dispatchActivityResult (Activity.java:7282)
at android.app.ActivityThread.deliverResults (ActivityThread.java:4516)}}
was:
I have gotten a number of crash reports via the google play console for a null
pointer exception (see below for stack).
Looking at the source code, it seems to be a problem when attempting to access
the extras from the intent - the problem being that the extras return null
(which the code doesn't expect):
[https://github.com/apache/cordova-plugin-camera/blob/e36482c7ba1e5dec07f68a246f3ecde8743d7cd6/src/android/CameraLauncher.java#L516]
{{
java.lang.RuntimeException:
at android.app.ActivityThread.deliverResults (ActivityThread.java:4520)
at android.app.ActivityThread.handleSendResult (ActivityThread.java:4563)
at android.app.ActivityThread.-wrap22 (ActivityThread.java)
at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1698)
at android.os.Handler.dispatchMessage (Handler.java:102)
at android.os.Looper.loop (Looper.java:154)
at android.app.ActivityThread.main (ActivityThread.java:6776)
at java.lang.reflect.Method.invoke (Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run
(ZygoteInit.java:1520)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1410)
Caused by: java.lang.NullPointerException:
at org.apache.cordova.camera.CameraLauncher.processResultFromCamera
(CameraLauncher.java:514)
at org.apache.cordova.camera.CameraLauncher.onActivityResult
(CameraLauncher.java:805)
at org.apache.cordova.CordovaInterfaceImpl.onActivityResult
(CordovaInterfaceImpl.java:152)
at org.apache.cordova.CordovaActivity.onActivityResult
(CordovaActivity.java:358)
at android.app.Activity.dispatchActivityResult (Activity.java:7282)
at android.app.ActivityThread.deliverResults (ActivityThread.java:4516)
}}
> NullPointerException when processing result from camera
> ---
>
> Key: CB-13954
> URL: https://issues.apache.org/jira/browse/CB-13954
> Project: Apache Cordova
> Issue Type: Bug
> Components: cordova-plugin-camera
>Reporter: Brad Zacher
>Priority: Major
>
> I have gotten a number of crash reports via the google play console for a
> null pointer exception (see below for stack).
> Looking at the source code, it seems to be a problem when attempting to
> access the extras from the intent - the problem being that the extras return
> null (which the code doesn't expect):
> [https://github.com/apache/cordova-plugin-camera/blob/e36482c7ba1e5dec07f68a246f3ecde8743d7cd6/src/android/CameraLauncher.java#L516]
>
> {{java.lang.RuntimeException:
> at android.app.ActivityThread.deliverResults (ActivityThread.java:4520)
> at android.app.ActivityThread.handleSendResult (ActivityThread.java:4563)
> at android.app.ActivityThread.-wrap22 (ActivityThread.java)
> at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1698)
> at android.os.Handler.dispatchMessage (Handler.java:102)
> at android.os.Looper.loop (Looper.java:154)
> at android.app.ActivityThread.main (ActivityThread.java:6776)
> at
[jira] [Created] (CB-13954) NullPointerException when processing result from camera
Brad Zacher created CB-13954:
Summary: NullPointerException when processing result from camera
Key: CB-13954
URL: https://issues.apache.org/jira/browse/CB-13954
Project: Apache Cordova
Issue Type: Bug
Components: cordova-plugin-camera
Reporter: Brad Zacher
I have gotten a number of crash reports via the google play console for a null
pointer exception (see below for stack).
Looking at the source code, it seems to be a problem when attempting to access
the extras from the intent - the problem being that the extras return null
(which the code doesn't expect):
https://github.com/apache/cordova-plugin-camera/blob/e36482c7ba1e5dec07f68a246f3ecde8743d7cd6/src/android/CameraLauncher.java#L516
{{*java.lang.RuntimeException:* }}
{{ at android.app.ActivityThread.deliverResults (ActivityThread.java:4520)}}
{{ at android.app.ActivityThread.handleSendResult (ActivityThread.java:4563)}}
{{ at android.app.ActivityThread.-wrap22 (ActivityThread.java)}}
{{ at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1698)}}
{{ at android.os.Handler.dispatchMessage (Handler.java:102)}}
{{ at android.os.Looper.loop (Looper.java:154)}}
{{ at android.app.ActivityThread.main (ActivityThread.java:6776)}}
{{ at java.lang.reflect.Method.invoke (Native Method)}}
{{ at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run
(ZygoteInit.java:1520)}}
{{ at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1410)}}
{{*Caused by: java.lang.NullPointerException:* }}
{{ at org.apache.cordova.camera.CameraLauncher.processResultFromCamera
(CameraLauncher.java:514)}}
{{ at org.apache.cordova.camera.CameraLauncher.onActivityResult
(CameraLauncher.java:805)}}
{{ at org.apache.cordova.CordovaInterfaceImpl.onActivityResult
(CordovaInterfaceImpl.java:152)}}
{{ at org.apache.cordova.CordovaActivity.onActivityResult
(CordovaActivity.java:358)}}
{{ at android.app.Activity.dispatchActivityResult (Activity.java:7282)}}
{{ at android.app.ActivityThread.deliverResults (ActivityThread.java:4516)}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Comment Edited] (CB-13801) Fail to restore plugins with relative path
[
https://issues.apache.org/jira/browse/CB-13801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16386996#comment-16386996
]
Jacob Weber edited comment on CB-13801 at 3/6/18 12:11 AM:
---
I'm running into this myself. A few notes:
* It affects iOS too, not just Android.
* Running it on Cordova 8.0.0 and 7.0.1, I'm seeing the same error, but when I
open the npm debug log, it shows different values for the "cwd" line; on 7.0.1
it seems to be running from within node_modules.
* If I change the paths in both config.xml and package.json to
{{../myplugins/testplugin}}, this fixes the error on 7.0.1 (but not 8.0.0).
I reproduced this by doing:
{code:java}
cordova create CordovaTest com.sample.cordovatest CordovaTest
cd CordovaTest
cordova platform add ios@4.5.4
cordova plugin add cordova-plugin-whitelist
# copy local plugin into CordovaTest
cordova plugin add myplugins/testplugin
rm -rf node_modules/ plugins/ platforms/
cordova prepare{code}
was (Author: jweber):
I'm running into this myself. A few notes:
* It affects iOS too, not just Android.
* Running it from Mac OS X and CentOS 6, I'm seeing the same error, but when I
open the npm debug log, it shows different values for the "cwd" line; on CentOS
it seems to be running from within node_modules.
* If I change the paths in both config.xml and package.json to
{{../myplugins/testplugin}}, this fixes the error on CentOS (but not Mac OS).
* HOWEVER, even on CentOS, it only works if I delete the package-lock.json
file before running {{cordova prepare}}. If I leave it, I get a very bizarre
error, where it seems to be confusing a plugin for a platform:
{code:java}
Discovered platform "ios@^4.5.4" in config.xml or package.json. Adding it to
the project
Using cordova-fetch for cordova-ios@^4.5.4
Adding cordova-plugin-whitelist project...
Error: Your cordova-plugin-whitelist platform does not have Api.js
Error: No platforms added to this project. Please use `cordova platform add
`.
{code}
I reproduced this by doing:
{code:java}
cordova create CordovaTest com.sample.cordovatest CordovaTest
cd CordovaTest
cordova platform add ios@4.5.4
cordova plugin add cordova-plugin-whitelist
# copy local plugin into CordovaTest
cordova plugin add myplugins/testplugin
rm -rf node_modules/ plugins/ platforms/
cordova prepare{code}
> Fail to restore plugins with relative path
> --
>
> Key: CB-13801
> URL: https://issues.apache.org/jira/browse/CB-13801
> Project: Apache Cordova
> Issue Type: Bug
> Components: cordova-lib
>Reporter: Michael Goffioul
>Priority: Major
>
> 1. Create a cordova project
> 2. Add android platform
> 3. Add a local plugin using a relative path: {{cordova plugin add
> myplugins/testplugin}}
> 4. Delete directories platforms/ and plugins/
> 5. Prepare android: {{cordova prepare android}}
> Cordova will fail to restore the local plugin. The plugin has been added to
> {{package.json}} using the spec {{file:myplugins/testplugin}} and the
> restoration utility is unable to handle such URL. Note that {{config.xml}}
> contains the spec {{myplugins/testplugin}} (that is, without the file:
> scheme), but the one in {{package.json}} takes precedence.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-13801) Fail to restore plugins with relative path
[
https://issues.apache.org/jira/browse/CB-13801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16386996#comment-16386996
]
Jacob Weber commented on CB-13801:
--
I'm running into this myself. A few notes:
* It affects iOS too, not just Android.
* Running it from Mac OS X and CentOS 6, I'm seeing the same error, but when I
open the npm debug log, it shows different values for the "cwd" line; on CentOS
it seems to be running from within node_modules.
* If I change the paths in both config.xml and package.json to
{{../myplugins/testplugin}}, this fixes the error on CentOS (but not Mac OS).
* HOWEVER, even on CentOS, it only works if I delete the package-lock.json
file before running {{cordova prepare}}. If I leave it, I get a very bizarre
error, where it seems to be confusing a plugin for a platform:
{code:java}
Discovered platform "ios@^4.5.4" in config.xml or package.json. Adding it to
the project
Using cordova-fetch for cordova-ios@^4.5.4
Adding cordova-plugin-whitelist project...
Error: Your cordova-plugin-whitelist platform does not have Api.js
Error: No platforms added to this project. Please use `cordova platform add
`.
{code}
I reproduced this by doing:
{code:java}
cordova create CordovaTest com.sample.cordovatest CordovaTest
cd CordovaTest
cordova platform add ios@4.5.4
cordova plugin add cordova-plugin-whitelist
# copy local plugin into CordovaTest
cordova plugin add myplugins/testplugin
rm -rf node_modules/ plugins/ platforms/
cordova prepare{code}
> Fail to restore plugins with relative path
> --
>
> Key: CB-13801
> URL: https://issues.apache.org/jira/browse/CB-13801
> Project: Apache Cordova
> Issue Type: Bug
> Components: cordova-lib
>Reporter: Michael Goffioul
>Priority: Major
>
> 1. Create a cordova project
> 2. Add android platform
> 3. Add a local plugin using a relative path: {{cordova plugin add
> myplugins/testplugin}}
> 4. Delete directories platforms/ and plugins/
> 5. Prepare android: {{cordova prepare android}}
> Cordova will fail to restore the local plugin. The plugin has been added to
> {{package.json}} using the spec {{file:myplugins/testplugin}} and the
> restoration utility is unable to handle such URL. Note that {{config.xml}}
> contains the spec {{myplugins/testplugin}} (that is, without the file:
> scheme), but the one in {{package.json}} takes precedence.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-12922) [iOS] In-app browser does not cede control after actions on certain pages
[ https://issues.apache.org/jira/browse/CB-12922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16386969#comment-16386969 ] Jacob Weber commented on CB-12922: -- Bump (sorry, but we're getting complaints) > [iOS] In-app browser does not cede control after actions on certain pages > - > > Key: CB-12922 > URL: https://issues.apache.org/jira/browse/CB-12922 > Project: Apache Cordova > Issue Type: Bug > Components: cordova-plugin-inappbrowser >Reporter: Ben Williams >Priority: Critical > Attachments: nest_iab.zip > > > This issue only occurs on the iOS version of inappbrowser. > When opening the Nest login (https://home.nest.com/login/) page in the > inappbrowser, clicking Sign In (with or without valid credentials) and > subsequently closing the browser, the main cordova page becomes unresponsive, > receiving no touch events whatsoever. > I have created a barebones application which exhibits the issue, which I will > attach. > Thank you. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-13583) Gray bar in status area when using inappbrowser
[
https://issues.apache.org/jira/browse/CB-13583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16386955#comment-16386955
]
Jacob Weber commented on CB-13583:
--
Just a reminder that this is still an issue.
> Gray bar in status area when using inappbrowser
> ---
>
> Key: CB-13583
> URL: https://issues.apache.org/jira/browse/CB-13583
> Project: Apache Cordova
> Issue Type: Bug
> Components: cordova-plugin-inappbrowser
> Environment: Mac OS 10.13.1, Xcode 9.1
>Reporter: Jacob Weber
>Priority: Major
> Attachments: config.xml, landscape-to-portrait-to-landscape.png,
> portrait-to-landscape.png, portrait.png
>
>
> Use the attached config.xml in a new Cordova project. Add viewport-fit=cover
> to index.html, and add Default@2x~universal~anyany.png file for the splash
> image.
> Open the project in an iPhone X simulator, running iOS 11.1.
> In portrait mode, call window.open('https://www.google.com', '_blank').
> You'll see a gray area where the status bar would be on older devices (see
> portrait.png). Rotate to landscape, and it's still there (see
> portrait-to-landscape.png).
> Close the browser. Now in landscape, run the window.open command again.
> Rotate to portrait, then back to landscape. Now you'll see a gray area, but
> it only covers half of the screen (see
> landscape-to-portrait-to-landscape.png).
> (Note that I used the "master" version of cordova-ios and some plugins, since
> it seems like there are some unreleased fixes for the iPhone X, like
> CB-13505).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-13929) duplicate entry: android/support/v13/view/DragStartHelper$OnDragStartListener.class
[
https://issues.apache.org/jira/browse/CB-13929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16386843#comment-16386843
]
Joe Bowser commented on CB-13929:
-
There's some third party plugins there that could be including support twice
after the recent update. This is why we've been trying to avoid using the
support library in Cordova for so long, since it could easily cause problems
like this in the gradle file. Do you have the generated gradle file handy,
namely the part where it's including the different libraries?
> duplicate entry:
> android/support/v13/view/DragStartHelper$OnDragStartListener.class
> ---
>
> Key: CB-13929
> URL: https://issues.apache.org/jira/browse/CB-13929
> Project: Apache Cordova
> Issue Type: Bug
> Components: cordova-android
>Affects Versions: cordova@7.0.0
>Reporter: Daniel Ramos
>Assignee: Joe Bowser
>Priority: Major
>
> Hello Cordova team.
>
> Today I've launched my app build in Jenkins as always, and it gives me the
> following error:
>
> {code:java}
> ...
> Note: Recompile with -Xlint:unchecked for details.
> :compileArmv7DebugNdk UP-TO-DATE
> :compileArmv7DebugSources
> :transformClassesWithJarMergingForArmv7Debug FAILED
> FAILURE: Build failed with an exception.
> * What went wrong:
> Execution failed for task ':transformClassesWithJarMergingForArmv7Debug'.
> > com.android.build.api.transform.TransformException:
> java.util.zip.ZipException: duplicate entry:
> android/support/v13/view/DragStartHelper$OnDragStartListener.class
> {code}
> I've been investigating what could have caused this issue, and the only thing
> that I can find that is different from previous builds, is an update that
> Cordova did over support-v4.
> Here is the log diff:
> [https://gist.github.com/DanielRamosAcosta/29f3223c3b8f96447814122bfc193f08]
> Cordova version & plugins:
> {code}
> "dependencies": {
> "cordova": "^7.1.0",
> "cordova-android": "^6.4.0",
> "cordova-plugin-android-permissions": "^1.0.0",
> "cordova-plugin-crosswalk-webview": "^2.3.0",
> "cordova-plugin-dbmeter": "^2.1.0",
> "cordova-plugin-screen-orientation": "^3.0.1",
> "cordova-plugin-statusbar": "^2.4.1",
> "cordova-plugin-whitelist": "^1.3.3",
> "cordova-plugin-x-socialsharing": "^5.2.1",
> "es6-promise-plugin": "^4.1.1"
> },
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Resolved] (CB-13943) ERR_FILE_NOT_FOUND — deep linking issue
[ https://issues.apache.org/jira/browse/CB-13943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Bowser resolved CB-13943. - Resolution: Won't Fix This is an angular routing issue, not a Cordova issue: https://stackoverflow.com/questions/15105910/angular-ng-view-routing-not-working-in-phonegap > ERR_FILE_NOT_FOUND — deep linking issue > --- > > Key: CB-13943 > URL: https://issues.apache.org/jira/browse/CB-13943 > Project: Apache Cordova > Issue Type: Bug > Environment: Android — any > Cordova — 6.5.0 >Reporter: Arthur Mudrick >Priority: Major > Attachments: > Screenshot_2018-02-28-15-18-50-964_ru.balumates.balu.png, > Screenshot_2018-02-28-15-55-56-348_ru.balumates.balu.png > > > I use Angular with Cordova. Angular uses URL routing, e.g. `/login` for the > Login page, '/settings' for the Settings page, etc. > When Android application updates (when new application version is installed) > Cordova is like «reloads» itself or something, but the path in the address > bar was `/login` or `/users` or `/settings` etc., so, Cordova thinks it is a > folder. > Cordova throws an error — see screenshot #1 — there is a path `/www/login` > but the `/login` is just Angular's routing, not a folder to search for :) > I also tried to make Angular work with hashbang url strategy, e.g. `/#/login` > rather than `/login` — it throws another error, see screenshot #2. > So, basically Cordova behaves like a server without the `mod_rewrite` option > — it tries to find folders inside the `/www` folder. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Updated] (CB-13947) Back button behavior doesn't revert to default when removing listeners
[
https://issues.apache.org/jira/browse/CB-13947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cedric Reichenbach updated CB-13947:
Description:
When adding a {{backbutton}} event listener to {{document}}, Cordova disables
default back button behavior (which is usually closing the app).
Later, when removing the last event listener, it should re-enable default
behavior, but does not.
h2. Technical details
Internally, cordova seems to use a channel to handle document event listener
registrations, which should update the override state on every listener
addition/removal:
[https://github.com/apache/cordova-android/blob/eddad666ff60129bf716cee61c24d3d65741640f/bin/templates/project/assets/www/cordova.js#L1664]
However, debugging indicates that {{onHasSubscribersChange}} is only triggered
once, when adding a listener for the first time, but never on removal.
h2. Workaround
As described [here|https://stackoverflow.com/a/49087662/1090166], one can
manually update the override state, e.g. to disable:
{code:javascript}
navigator.app.overrideBackbutton(false);
{code}
was:
When adding a `backbutton` event listener to `document`, Cordova disables
default back button behavior (which is usually closing the app).
Later, when removing the last event listener, it should re-enable default
behavior, but does not.
h2. Technical details
Internally, cordova seems to use a channel to handle document event listener
registrations, which should update the override state on every listener
addition/removal:
[https://github.com/apache/cordova-android/blob/eddad666ff60129bf716cee61c24d3d65741640f/bin/templates/project/assets/www/cordova.js#L1664]
However, debugging indicates that `onHasSubscribersChange` is only triggered
once, when adding a listener for the first time, but never on removal.
> Back button behavior doesn't revert to default when removing listeners
> --
>
> Key: CB-13947
> URL: https://issues.apache.org/jira/browse/CB-13947
> Project: Apache Cordova
> Issue Type: Bug
> Components: cordova-android, cordova-js
>Affects Versions: cordova-android-7.0.0
>Reporter: Cedric Reichenbach
>Assignee: Joe Bowser
>Priority: Major
>
> When adding a {{backbutton}} event listener to {{document}}, Cordova disables
> default back button behavior (which is usually closing the app).
> Later, when removing the last event listener, it should re-enable default
> behavior, but does not.
> h2. Technical details
> Internally, cordova seems to use a channel to handle document event listener
> registrations, which should update the override state on every listener
> addition/removal:
> [https://github.com/apache/cordova-android/blob/eddad666ff60129bf716cee61c24d3d65741640f/bin/templates/project/assets/www/cordova.js#L1664]
> However, debugging indicates that {{onHasSubscribersChange}} is only
> triggered once, when adding a listener for the first time, but never on
> removal.
> h2. Workaround
> As described [here|https://stackoverflow.com/a/49087662/1090166], one can
> manually update the override state, e.g. to disable:
> {code:javascript}
> navigator.app.overrideBackbutton(false);
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-13400) Restructure and test "Installing" instructions
[ https://issues.apache.org/jira/browse/CB-13400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16386681#comment-16386681 ] ASF GitHub Bot commented on CB-13400: - janpio closed pull request #802: CB-13400 Restructure and test "Installing" instructions(part b) - Categorizing installation steps according to OSes URL: https://github.com/apache/cordova-docs/pull/802 This is a PR merged from a forked repository. As GitHub hides the original diff on merge, it is displayed below for the sake of provenance: As this is a foreign pull request (from a fork), the diff is supplied below (as it won't show otherwise due to GitHub magic): diff --git a/doc/installing-a-development-environment.md b/doc/installing-a-development-environment.md index 48f8a3151..5020839fe 100644 --- a/doc/installing-a-development-environment.md +++ b/doc/installing-a-development-environment.md @@ -1,16 +1,34 @@ ## Installing -### Ruby +### Mac OS X -Ruby 2.0 is required to build the docs. NOTE: *The docs will not build with Ruby 1.8, 1.9 or 2.4.* - - Mac OS X + Ruby Install Homebrew from [this site][homebrew], and then run: brew install ruby@2.0 - Windows + Python + +Mac OS X comes with Python 2.7 pre-installed. Else, follow these steps: + +1. Download [this installer][python_installer_mac] from [this page][python_downloads]. +2. Run the downloaded file. + + Node.js + +Go to [this site][nodejs], and click the "Install" button. Then run the downloaded file and follow the on-screen instructions. Make sure that the option to **install NPM** is enabled, if you see one. + + Make (optional) + +Make comes with the Xcode Command Line Tools. To install them, run: + +xcode-select --install + + +### Windows + + Ruby Follow these steps: @@ -31,57 +49,64 @@ Follow these steps: ruby dk.rb install 1. Close `cmd.exe`. - Linux - -Run the commands from [this site][ruby_linux] that apply to your Linux distribution. + Python - Verify Ruby +Python 2.7 is also required to build the docs. NOTE: *The docs will not build with Python 3.0 or greater.* -Verify your Ruby installation by running: +Follow these steps: -ruby --version +1. Download [this installer][python_installer_windows] from [this page][python_downloads]. +2. Run the downloaded file. + 1. Use the default installation path + 1. Make sure the **'add executable to path'** option is checked. -### Python + Node.js -Python 2.7 is also required to build the docs. NOTE: *The docs will not build with Python 3.0 or greater.* +Go to [this site][nodejs], and click the "Install" button. Then run the downloaded file and follow the on-screen instructions. Make sure that the option to **install NPM** is enabled, if you see one. - Mac OS X + Make (optional) -Mac OS X comes with Python 2.7 pre-installed. Else, follow these steps: +Make can be installed on Windows from [this page][make_page] by downloading the [setup tool][make_setup] and running it. -1. Download [this installer][python_installer_mac] from [this page][python_downloads]. -2. Run the downloaded file. - Windows +### Linux -Follow these steps: + Ruby -1. Download [this installer][python_installer_windows] from [this page][python_downloads]. -2. Run the downloaded file. - 1. Use the default installation path - 1. Make sure the **'add executable to path'** option is checked. +Run the commands from [this site][ruby_linux] that apply to your Linux distribution. - Linux + Python The latest version of CentOS, Fedora, Redhat Enterprise (RHEL) and Ubuntu come with Python 2.7 pre-installed. Else, follow the steps from [this site][python_linux]. - Verify Python + Node.js -Verify your Python installation by running: +Follow the instructions on [this site][linux_node]. -python --version + Make -The version must be 2.7.x. +Make is installed by default on Linux. -### Node.js - Mac OS X Windows +### Check Installations -Go to [this site][nodejs], and click the "Install" button. Then run the downloaded file and follow the on-screen instructions. Make sure that the option to **install NPM** is enabled, if you see one. + Verify Ruby + +Ruby 2.0 is required to build the docs. NOTE: *The docs will not build with Ruby 1.8, 1.9 or 2.4.* + +Verify your Ruby installation by running: + +ruby --version + + Verify Python + +Python 2.7 is also required to build the docs. NOTE: *The docs will not build with Python 3.0 or greater.* - Linux +Verify your Python installation by running: -Linux, follow the instructions on [this site][linux_node]. +python --version + +The version must be 2.7.x. Verify Node.js @@ -90,6 +115,13 @@ Verify your Node.js installation by running: node --version npm --version + Verify make + +Verify your make installation by running:
[jira] [Updated] (CB-13947) Back button behavior doesn't revert to default when removing listeners
[ https://issues.apache.org/jira/browse/CB-13947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Bowser updated CB-13947: Component/s: cordova-js > Back button behavior doesn't revert to default when removing listeners > -- > > Key: CB-13947 > URL: https://issues.apache.org/jira/browse/CB-13947 > Project: Apache Cordova > Issue Type: Bug > Components: cordova-android, cordova-js >Affects Versions: cordova-android-7.0.0 >Reporter: Cedric Reichenbach >Assignee: Joe Bowser >Priority: Major > > When adding a `backbutton` event listener to `document`, Cordova disables > default back button behavior (which is usually closing the app). > Later, when removing the last event listener, it should re-enable default > behavior, but does not. > h2. Technical details > Internally, cordova seems to use a channel to handle document event listener > registrations, which should update the override state on every listener > addition/removal: > [https://github.com/apache/cordova-android/blob/eddad666ff60129bf716cee61c24d3d65741640f/bin/templates/project/assets/www/cordova.js#L1664] > However, debugging indicates that `onHasSubscribersChange` is only triggered > once, when adding a listener for the first time, but never on removal. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-13953) Cordova has a hard dependency on Gradle being on the path and JAVA_HOME being set in advance
[ https://issues.apache.org/jira/browse/CB-13953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16386576#comment-16386576 ] Joe Bowser commented on CB-13953: - The wrapper is in gitignore because Apache policy prevents us from committing the Gradle Wrapper. The reason we use wrapper.gradle is so that we can generate the wrapper. We do not plan on supporting any Gradle Wrapper customization, since we lack the ability to do so due to the ASF policy on bundling gradle. > Cordova has a hard dependency on Gradle being on the path and JAVA_HOME being > set in advance > > > Key: CB-13953 > URL: https://issues.apache.org/jira/browse/CB-13953 > Project: Apache Cordova > Issue Type: Improvement > Components: cordova-android >Affects Versions: cordova-android-7.0.0 > Environment: android build >Reporter: armin >Assignee: Joe Bowser >Priority: Minor > Original Estimate: 8h > Remaining Estimate: 8h > > Cordova is tightly coupled with the gradle executable and it is verifying it > being on the path even though the gradle wrapper is available. Also the > JAVA_HOME has to be already available or java be on the path before running > cordova commands even though these can be set during the build. > In general there are several problems with the current gradle bootstrapping > process: > * Cordova checks for gradle being on the path and fails execution if it > isn't there even though the wrapper is already generated so gradle is not > needed at that point. The wrapper files are also on .gitignore for no reason > since committing them is fairly standard practice and they could be bundled > with cordova from the beginning to avoid dependency on gradle in general and > to tie the gradle version to the cordova version. > * In general the checks inside cordova are not sufficient to determine if a > given "requirement" is available (or will be set during the build) or not, it > should be possible to continue the build even if the build-in requirement > checks fail > * The gradle wrapper is generated by Cordova instead of the user as it > should be and as it is the gradle convention -> this means any customization > process is extremely difficult and we have no control. It is understandable > to tie the gradle version to a cordova version but this version check should > be done during execution and not before so the users can manage their own > wrapper > * Cordova is using a separate gradle file for generating the wrapper and not > the actual build.gradle file -> wrapper.gradle is being used for generation > which means any configuration from build.gradle is not respected, such as > wrapper version or wrapper customization (for example we also generate the > JAVA_HOME variable into the wrapper so we would not need java or gradle on > the path at all after the initial install, as we only have a local > installations) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Resolved] (CB-13953) Cordova has a hard dependency on Gradle being on the path and JAVA_HOME being set in advance
[ https://issues.apache.org/jira/browse/CB-13953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Bowser resolved CB-13953. - Resolution: Won't Fix > Cordova has a hard dependency on Gradle being on the path and JAVA_HOME being > set in advance > > > Key: CB-13953 > URL: https://issues.apache.org/jira/browse/CB-13953 > Project: Apache Cordova > Issue Type: Improvement > Components: cordova-android >Affects Versions: cordova-android-7.0.0 > Environment: android build >Reporter: armin >Assignee: Joe Bowser >Priority: Minor > Original Estimate: 8h > Remaining Estimate: 8h > > Cordova is tightly coupled with the gradle executable and it is verifying it > being on the path even though the gradle wrapper is available. Also the > JAVA_HOME has to be already available or java be on the path before running > cordova commands even though these can be set during the build. > In general there are several problems with the current gradle bootstrapping > process: > * Cordova checks for gradle being on the path and fails execution if it > isn't there even though the wrapper is already generated so gradle is not > needed at that point. The wrapper files are also on .gitignore for no reason > since committing them is fairly standard practice and they could be bundled > with cordova from the beginning to avoid dependency on gradle in general and > to tie the gradle version to the cordova version. > * In general the checks inside cordova are not sufficient to determine if a > given "requirement" is available (or will be set during the build) or not, it > should be possible to continue the build even if the build-in requirement > checks fail > * The gradle wrapper is generated by Cordova instead of the user as it > should be and as it is the gradle convention -> this means any customization > process is extremely difficult and we have no control. It is understandable > to tie the gradle version to a cordova version but this version check should > be done during execution and not before so the users can manage their own > wrapper > * Cordova is using a separate gradle file for generating the wrapper and not > the actual build.gradle file -> wrapper.gradle is being used for generation > which means any configuration from build.gradle is not respected, such as > wrapper version or wrapper customization (for example we also generate the > JAVA_HOME variable into the wrapper so we would not need java or gradle on > the path at all after the initial install, as we only have a local > installations) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-13947) Back button behavior doesn't revert to default when removing listeners
[ https://issues.apache.org/jira/browse/CB-13947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16386578#comment-16386578 ] Joe Bowser commented on CB-13947: - This sounds more like a cordova-js error than a cordova-android error. > Back button behavior doesn't revert to default when removing listeners > -- > > Key: CB-13947 > URL: https://issues.apache.org/jira/browse/CB-13947 > Project: Apache Cordova > Issue Type: Bug > Components: cordova-android, cordova-js >Affects Versions: cordova-android-7.0.0 >Reporter: Cedric Reichenbach >Assignee: Joe Bowser >Priority: Major > > When adding a `backbutton` event listener to `document`, Cordova disables > default back button behavior (which is usually closing the app). > Later, when removing the last event listener, it should re-enable default > behavior, but does not. > h2. Technical details > Internally, cordova seems to use a channel to handle document event listener > registrations, which should update the override state on every listener > addition/removal: > [https://github.com/apache/cordova-android/blob/eddad666ff60129bf716cee61c24d3d65741640f/bin/templates/project/assets/www/cordova.js#L1664] > However, debugging indicates that `onHasSubscribersChange` is only triggered > once, when adding a listener for the first time, but never on removal. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-13949) cordova prepare doesn't install the correct plugin versions
[
https://issues.apache.org/jira/browse/CB-13949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16386435#comment-16386435
]
Jesper van den Ende commented on CB-13949:
--
[~jcesarmobile] ah that makes sense, I wasn't aware that the ^ and ~ in front
of versions are called save prefixes and actually have a purpose.
Thanks for the clarification :)
> cordova prepare doesn't install the correct plugin versions
> ---
>
> Key: CB-13949
> URL: https://issues.apache.org/jira/browse/CB-13949
> Project: Apache Cordova
> Issue Type: Bug
> Components: cordova-cli
>Affects Versions: cordova@8.0.0
> Environment: Mac OS,
> Cordova 8.0.0
> npm 3.10.3
>Reporter: Jesper van den Ende
>Priority: Major
> Labels: cordova-cli, plugin, prepare, version
>
> according to the documentation at
> [https://cordova.apache.org/docs/en/latest/platform_plugin_versioning_ref/#plugin-versioning]
> plugins should install the version from either config.xml or package.json.
> However, the latest version is always installed instead.
> How to reproduce:
> {noformat}
> cordova create test
> cd test
> cordova platform add android
> cordova plugin add cordova-plugin-splashscreen@4.0.0{noformat}
> Note how
> {code:java}
> cordova plugin ls{code}
> Shows that version 4.0.0 is installed. Also config.xml and package.json both
> indicate that 4.0.0 is installed.
> Now delete the 'platforms' and 'plugins' folder and run
> {noformat}
> cordova prepare{noformat}
> Note how config.xml and package.json still indicate that 4.0.0 installed,
> however when running
> {noformat}
> cordova plugin ls{noformat}
> it shows
> {noformat}
> cordova-plugin-splashscreen 4.1.0 "Splashscreen"
> cordova-plugin-whitelist 1.3.3 "Whitelist"{noformat}
>
> perhaps I'm missing something, though my understanding is that when `cordova
> prepare` is run, all plugins and platforms will be installed with their
> version as listed in package.json and config.xml.
>
> {noformat}
> cordova plugin rm cordova-plugin-splashscreen
> cordova plugin add cordova-plugin-splashscreen@4.0.0{noformat}
> Installs the correct version again, but that kind of defeats the purpose of
> cordova prepare.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Updated] (CB-13943) ERR_FILE_NOT_FOUND — deep linking issue
[ https://issues.apache.org/jira/browse/CB-13943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arthur Mudrick updated CB-13943: Summary: ERR_FILE_NOT_FOUND — deep linking issue (was: ERR_FILE_NOT_FOUND) > ERR_FILE_NOT_FOUND — deep linking issue > --- > > Key: CB-13943 > URL: https://issues.apache.org/jira/browse/CB-13943 > Project: Apache Cordova > Issue Type: Bug > Environment: Android — any > Cordova — 6.5.0 >Reporter: Arthur Mudrick >Priority: Major > Attachments: > Screenshot_2018-02-28-15-18-50-964_ru.balumates.balu.png, > Screenshot_2018-02-28-15-55-56-348_ru.balumates.balu.png > > > I use Angular with Cordova. Angular uses URL routing, e.g. `/login` for the > Login page, '/settings' for the Settings page, etc. > When Android application updates (when new application version is installed) > Cordova is like «reloads» itself or something, but the path in the address > bar was `/login` or `/users` or `/settings` etc., so, Cordova thinks it is a > folder. > Cordova throws an error — see screenshot #1 — there is a path `/www/login` > but the `/login` is just Angular's routing, not a folder to search for :) > I also tried to make Angular work with hashbang url strategy, e.g. `/#/login` > rather than `/login` — it throws another error, see screenshot #2. > So, basically Cordova behaves like a server without the `mod_rewrite` option > — it tries to find folders inside the `/www` folder. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Updated] (CB-13953) Cordova has a hard dependency on Gradle being on the path and JAVA_HOME being set in advance
[ https://issues.apache.org/jira/browse/CB-13953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] armin updated CB-13953: --- Remaining Estimate: 8h (was: 24h) Original Estimate: 8h (was: 24h) > Cordova has a hard dependency on Gradle being on the path and JAVA_HOME being > set in advance > > > Key: CB-13953 > URL: https://issues.apache.org/jira/browse/CB-13953 > Project: Apache Cordova > Issue Type: Improvement > Components: cordova-android >Affects Versions: cordova-android-7.0.0 > Environment: android build >Reporter: armin >Assignee: Joe Bowser >Priority: Minor > Original Estimate: 8h > Remaining Estimate: 8h > > Cordova is tightly coupled with the gradle executable and it is verifying it > being on the path even though the gradle wrapper is available. Also the > JAVA_HOME has to be already available or java be on the path before running > cordova commands even though these can be set during the build. > In general there are several problems with the current gradle bootstrapping > process: > * Cordova checks for gradle being on the path and fails execution if it > isn't there even though the wrapper is already generated so gradle is not > needed at that point. The wrapper files are also on .gitignore for no reason > since committing them is fairly standard practice and they could be bundled > with cordova from the beginning to avoid dependency on gradle in general and > to tie the gradle version to the cordova version. > * In general the checks inside cordova are not sufficient to determine if a > given "requirement" is available (or will be set during the build) or not, it > should be possible to continue the build even if the build-in requirement > checks fail > * The gradle wrapper is generated by Cordova instead of the user as it > should be and as it is the gradle convention -> this means any customization > process is extremely difficult and we have no control. It is understandable > to tie the gradle version to a cordova version but this version check should > be done during execution and not before so the users can manage their own > wrapper > * Cordova is using a separate gradle file for generating the wrapper and not > the actual build.gradle file -> wrapper.gradle is being used for generation > which means any configuration from build.gradle is not respected, such as > wrapper version or wrapper customization (for example we also generate the > JAVA_HOME variable into the wrapper so we would not need java or gradle on > the path at all after the initial install, as we only have a local > installations) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Created] (CB-13953) Cordova has a hard dependency on Gradle being on the path and JAVA_HOME being set in advance
armin created CB-13953: -- Summary: Cordova has a hard dependency on Gradle being on the path and JAVA_HOME being set in advance Key: CB-13953 URL: https://issues.apache.org/jira/browse/CB-13953 Project: Apache Cordova Issue Type: Improvement Components: cordova-android Affects Versions: cordova-android-7.0.0 Environment: android build Reporter: armin Assignee: Joe Bowser Cordova is tightly coupled with the gradle executable and it is verifying it being on the path even though the gradle wrapper is available. Also the JAVA_HOME has to be already available or java be on the path before running cordova commands even though these can be set during the build. In general there are several problems with the current gradle bootstrapping process: * Cordova checks for gradle being on the path and fails execution if it isn't there even though the wrapper is already generated so gradle is not needed at that point. The wrapper files are also on .gitignore for no reason since committing them is fairly standard practice and they could be bundled with cordova from the beginning to avoid dependency on gradle in general and to tie the gradle version to the cordova version. * In general the checks inside cordova are not sufficient to determine if a given "requirement" is available (or will be set during the build) or not, it should be possible to continue the build even if the build-in requirement checks fail * The gradle wrapper is generated by Cordova instead of the user as it should be and as it is the gradle convention -> this means any customization process is extremely difficult and we have no control. It is understandable to tie the gradle version to a cordova version but this version check should be done during execution and not before so the users can manage their own wrapper * Cordova is using a separate gradle file for generating the wrapper and not the actual build.gradle file -> wrapper.gradle is being used for generation which means any configuration from build.gradle is not respected, such as wrapper version or wrapper customization (for example we also generate the JAVA_HOME variable into the wrapper so we would not need java or gradle on the path at all after the initial install, as we only have a local installations) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-13415) Importing corrupt images using the Camera plugin crashes the app
[ https://issues.apache.org/jira/browse/CB-13415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16386134#comment-16386134 ] ASF GitHub Bot commented on CB-13415: - jd0048 commented on issue #310: CB-13415 (iOS) Importing corrupt images using the Camera plugin crashes the app URL: https://github.com/apache/cordova-plugin-camera/pull/310#issuecomment-370434875 @jcesarmobile @shazron @alsorokin Have you got a chance to take a look and merge this code? i am requesting you to merge code asap. Thank you This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Importing corrupt images using the Camera plugin crashes the app > > > Key: CB-13415 > URL: https://issues.apache.org/jira/browse/CB-13415 > Project: Apache Cordova > Issue Type: Bug > Components: cordova-plugin-camera > Environment: Android: OS 7.0, Phone Model: Moto G5 Plus > iOS: OS 10.1.1 (14B150) >Reporter: Shemrick Flannigan >Priority: Critical > Labels: android, camera, cameraui, ios > > ISSUE > Importing corrupt images using the Camera plugin crashes the app > Current Behavior > # Importing a corrupt image using the Cordova Camera plugin crashes the > Cordova app which uses the plugin > Expected Behavior > # Importing a corrupt image using the Cordova Camera plugin: > #* Throws an exception which can be caught by the Cordova app which uses the > plugin > #* Does not crash the Cordova app which uses the plugin > #* Allows the Cordova app which uses the plugin to render a Toast error > message relaying the error > # # Platforms affected > #* Android > #* iOS > REFERENCES > # [Sample corrupt image which crashes the app | > https://www.dropbox.com/s/e7dz007svtvscbc/Corrupt_Image_4.7MB_13500x13500.D2.jpg?dl=0] > # [Technique used to wrap the call in a Try/Catch block in a callable inner > class to prevent an app crash | > https://stackoverflow.com/questions/19183174/phonegap-video-capture-crashes] > ADDITIONAL INFORMATION > # Importing corrupt images does not crash apps which do not use the Camera > plugin, such as: > #* Yelp mobile app > #* Slack mobile app -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Closed] (CB-13950) All Exif data is stripped off under iOS when Camera.DestinationType is File_URI
[ https://issues.apache.org/jira/browse/CB-13950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jcesarmobile closed CB-13950. - Resolution: Duplicate Closing as duplicate of CB-11225 > All Exif data is stripped off under iOS when Camera.DestinationType is > File_URI > --- > > Key: CB-13950 > URL: https://issues.apache.org/jira/browse/CB-13950 > Project: Apache Cordova > Issue Type: Bug > Components: cordova-plugin-camera >Affects Versions: cordova-ios 4.5.0 >Reporter: Junran >Priority: Major > > When Camera.DestinationType is File_URI > All exif metadata is stripped off under iOS > This is inconsistent with what it is under Android. It seems the code have > implemented to reattached the exif metadata when writing to temporary file > path, but it doesn't work. > A way to retain the exif data when using File_URI under iOS is needed. > Any idea is much appreciated. Thanks! -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Closed] (CB-13949) cordova prepare doesn't install the correct plugin versions
[
https://issues.apache.org/jira/browse/CB-13949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
jcesarmobile closed CB-13949.
-
Resolution: Not A Problem
When the plugins are added, they are added with your configured npm save-prefix
Type npm get save-prefix and you will get ^
It's recommended to change it to ~ to get latest patch version and instead of
latest minor
Supposedly --save-exact option was added some time ago, but last time I tried
it wasn't working fine.
> cordova prepare doesn't install the correct plugin versions
> ---
>
> Key: CB-13949
> URL: https://issues.apache.org/jira/browse/CB-13949
> Project: Apache Cordova
> Issue Type: Bug
> Components: cordova-cli
>Affects Versions: cordova@8.0.0
> Environment: Mac OS,
> Cordova 8.0.0
> npm 3.10.3
>Reporter: Jesper van den Ende
>Priority: Major
> Labels: cordova-cli, plugin, prepare, version
>
> according to the documentation at
> [https://cordova.apache.org/docs/en/latest/platform_plugin_versioning_ref/#plugin-versioning]
> plugins should install the version from either config.xml or package.json.
> However, the latest version is always installed instead.
> How to reproduce:
> {noformat}
> cordova create test
> cd test
> cordova platform add android
> cordova plugin add cordova-plugin-splashscreen@4.0.0{noformat}
> Note how
> {code:java}
> cordova plugin ls{code}
> Shows that version 4.0.0 is installed. Also config.xml and package.json both
> indicate that 4.0.0 is installed.
> Now delete the 'platforms' and 'plugins' folder and run
> {noformat}
> cordova prepare{noformat}
> Note how config.xml and package.json still indicate that 4.0.0 installed,
> however when running
> {noformat}
> cordova plugin ls{noformat}
> it shows
> {noformat}
> cordova-plugin-splashscreen 4.1.0 "Splashscreen"
> cordova-plugin-whitelist 1.3.3 "Whitelist"{noformat}
>
> perhaps I'm missing something, though my understanding is that when `cordova
> prepare` is run, all plugins and platforms will be installed with their
> version as listed in package.json and config.xml.
>
> {noformat}
> cordova plugin rm cordova-plugin-splashscreen
> cordova plugin add cordova-plugin-splashscreen@4.0.0{noformat}
> Installs the correct version again, but that kind of defeats the purpose of
> cordova prepare.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Updated] (CB-13952) cordova build ios Failing due to "Pods/Target Support Files" being cleared
[
https://issues.apache.org/jira/browse/CB-13952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Meijers updated CB-13952:
Description:
After runnign `cordova platform add ios --nofetch` and `pod install`, the
`cordova build ios --nofetch --device --release` command fails (also fails for
debug builds).
The reason it fails is because `platforms/ios/Pods/Target Support Files/` is
completely empty and during the build it errors because it cannot find configs
for the Pod dependencies in that folder. I have verified that the `Target
Support Files` folder is *not* empty after adding the platform nor is it empty
after running `pod install`. However, as soon as the build command runs it is
empty.
The errors are similar to these:
{code:bash}
Ignoring configuration file
'/Users/jenkins/build/workspace/triggi-app-release/platforms/ios/cordova/build-release.xcconfig'
because it could not be loaded.
Reason: File could not be parsed due to preprocessing errors:
pods-release.xcconfig line 2: Unable to find included file "Pods/Target
Support Files/Pods-Olisto/Pods-Olisto.release.xcconfig"User defaults from
command line:
IDEArchivePathOverride =
/Users/jenkins/build/workspace/triggi-app-release/platforms/ios/Olisto.xcarchive
clang: error: no such file or directory:
'/Users/jenkins/build/workspace/triggi-app-release/platforms/ios/Pods/Target
Support Files/GoogleToolboxForMac/GoogleToolboxForMac-dummy.m'
clang: error: no input files
{code}
The weird thing is that, after the build fails, when I run the same `pod
install` command and thereafter `cordova build ios --nofetch --device
--release` the build succeeds. The output from CocoaPods isn't any different.
This problem started occurring about a week ago and never occurred in the
months before.
I have also verified that the plugins we use that depend on CocoaPods were not
updated in the past few weeks when the error started occurring.
was:
After runnign `cordova platform add ios --nofetch` and `pod install`, the
`cordova build ios --nofetch --device --release` command fails (also fails for
debug builds).
The reason it fails is because `platforms/ios/Pods/Target Support Files/` is
completely empty and during the build it errors because it cannot find configs
for the Pod dependencies in that folder. I have verified that the `Target
Support Files` folder is *not* empty after adding the platform nor is it empty
after running `pod install`. However, as soon as the build command runs it is
empty.
The errors are similar to these:
```
Ignoring configuration file
'/Users/jenkins/build/workspace/triggi-app-release/platforms/ios/cordova/build-release.xcconfig'
because it could not be loaded.
Reason: File could not be parsed due to preprocessing errors:
pods-release.xcconfig line 2: Unable to find included file "Pods/Target
Support Files/Pods-Olisto/Pods-Olisto.release.xcconfig"User defaults from
command line:
IDEArchivePathOverride =
/Users/jenkins/build/workspace/triggi-app-release/platforms/ios/Olisto.xcarchive
clang: error: no such file or directory:
'/Users/jenkins/build/workspace/triggi-app-release/platforms/ios/Pods/Target
Support Files/GoogleToolboxForMac/GoogleToolboxForMac-dummy.m'
clang: error: no input files
```
The weird thing is that, after the build fails, when I run the same `pod
install` command and thereafter `cordova build ios --nofetch --device
--release` the build succeeds. The output from CocoaPods isn't any different.
This problem started occurring about a week ago and never occurred in the
months before.
I have also verified that the plugins we use that depend on CocoaPods were not
updated in the past few weeks when the error started occurring.
> cordova build ios Failing due to "Pods/Target Support Files" being cleared
> --
>
> Key: CB-13952
> URL: https://issues.apache.org/jira/browse/CB-13952
> Project: Apache Cordova
> Issue Type: Bug
> Components: cordova-ios
>Affects Versions: cordova-ios@4.5.4
> Environment: cordova@7.1.0
> cordova-ios@4.5.4
> OS: OSx Sierra (10.12.6)
>Reporter: Thomas Meijers
>Assignee: Suraj Pindoria
>Priority: Critical
> Labels: build
>
> After runnign `cordova platform add ios --nofetch` and `pod install`, the
> `cordova build ios --nofetch --device --release` command fails (also fails
> for debug builds).
> The reason it fails is because `platforms/ios/Pods/Target Support Files/` is
> completely empty and during the build it errors because it cannot find
> configs for the Pod dependencies in that folder. I have verified that the
> `Target Support Files` folder is *not* empty after adding the platform nor is
> it empty after running `pod install`. However, as soon as the build
[jira] [Created] (CB-13952) cordova build ios Failing due to "Pods/Target Support Files" being cleared
Thomas Meijers created CB-13952: --- Summary: cordova build ios Failing due to "Pods/Target Support Files" being cleared Key: CB-13952 URL: https://issues.apache.org/jira/browse/CB-13952 Project: Apache Cordova Issue Type: Bug Components: cordova-ios Affects Versions: cordova-ios@4.5.4 Environment: cordova@7.1.0 cordova-ios@4.5.4 OS: OSx Sierra (10.12.6) Reporter: Thomas Meijers Assignee: Suraj Pindoria After runnign `cordova platform add ios --nofetch` and `pod install`, the `cordova build ios --nofetch --device --release` command fails (also fails for debug builds). The reason it fails is because `platforms/ios/Pods/Target Support Files/` is completely empty and during the build it errors because it cannot find configs for the Pod dependencies in that folder. I have verified that the `Target Support Files` folder is *not* empty after adding the platform nor is it empty after running `pod install`. However, as soon as the build command runs it is empty. The errors are similar to these: ``` Ignoring configuration file '/Users/jenkins/build/workspace/triggi-app-release/platforms/ios/cordova/build-release.xcconfig' because it could not be loaded. Reason: File could not be parsed due to preprocessing errors: pods-release.xcconfig line 2: Unable to find included file "Pods/Target Support Files/Pods-Olisto/Pods-Olisto.release.xcconfig"User defaults from command line: IDEArchivePathOverride = /Users/jenkins/build/workspace/triggi-app-release/platforms/ios/Olisto.xcarchive clang: error: no such file or directory: '/Users/jenkins/build/workspace/triggi-app-release/platforms/ios/Pods/Target Support Files/GoogleToolboxForMac/GoogleToolboxForMac-dummy.m' clang: error: no input files ``` The weird thing is that, after the build fails, when I run the same `pod install` command and thereafter `cordova build ios --nofetch --device --release` the build succeeds. The output from CocoaPods isn't any different. This problem started occurring about a week ago and never occurred in the months before. I have also verified that the plugins we use that depend on CocoaPods were not updated in the past few weeks when the error started occurring. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Closed] (CB-13932) APK Not Copied to Visual Studio bin Directory
[
https://issues.apache.org/jira/browse/CB-13932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
jcesarmobile closed CB-13932.
-
Resolution: Won't Fix
cordova-android version had a major bump because of this breaking change
(project structure changed to be in line with latest Android Studio native
structure), so tools using it should adapt to the change.
So closing as won't fix.
As workaround use the script provided in one of the comments.
> APK Not Copied to Visual Studio bin Directory
> -
>
> Key: CB-13932
> URL: https://issues.apache.org/jira/browse/CB-13932
> Project: Apache Cordova
> Issue Type: Improvement
> Components: cordova-android
>Affects Versions: cordova-android-7.0.0
> Environment: cordova@8.0
> cordova-android@7.1.0
> Visual Studio 2017
> Windows 10
>Reporter: Terence Bandoian
>Assignee: Joe Bowser
>Priority: Minor
>
> With Visual Studio 2017 configured to use the globally installed Cordova CLI
> (8.0) instead of the version packaged with Visual Studio, debug APKs
> generated with cordova-android@7.1.0 are not copied to the project bin
> directory.
> Debug APKs are written to:
> {code:java}
> platforms/android/app/build/outputs/apk/debug/app-debug.apk
> {code}
> Visual Studio apparently expects APKs to be written to:
> {code:java}
> bin/Android/Debug/android-debug.apk{code}
> This prevents initiatiation of a debug session on a device from within Visual
> Studio.
> A simple after_build script such as the following:
> {code:java}
> module.exports = function (ctx) {
> if (ctx.opts.platforms.indexOf('android') < 0) {
> return;
> }
> var fs = ctx.requireCordovaModule('fs'),
> path = ctx.requireCordovaModule('path');
> var src = path.join(
> ctx.opts.projectRoot,
> 'platforms/android/app/build/outputs/apk/debug/app-debug.apk');
> var dst = path.join(
> ctx.opts.projectRoot,
> 'bin/Android/Debug/android-debug.apk');
> fs.copyFileSync(src, dst);
> return 0;
> };
> {code}
> is an effective work-around but the development experience would be improved
> if it wasn't necessary to expend the extra effort to determine the cause and
> implement a solution.
> The most recent version of cordova-android that I know of where this is not
> necessary is 6.3.0. I haven't tested 6.4.0 or 7.0.0.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Created] (CB-13951) choose a Video with getPicture returns null as filelocation
Torsten Rosenberger created CB-13951: Summary: choose a Video with getPicture returns null as filelocation Key: CB-13951 URL: https://issues.apache.org/jira/browse/CB-13951 Project: Apache Cordova Issue Type: Bug Components: cordova-plugin-camera Affects Versions: cordova@8.0.0 Environment: Plattform android 6.3.0 cordova-plugin-camera 4.0.2 Samsung Galaxy S7 Reporter: Torsten Rosenberger Hello navigator.camera.getPicture returns null wenn i select a Video. Problem ist located in the FileHelper.java class on line 94 // TODO handle non-primary volumes so the method always returns null the uri ist set correct BR/Torsten -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Created] (CB-13950) All Exif data is stripped off under iOS when Camera.DestinationType is File_URI
Junran created CB-13950: --- Summary: All Exif data is stripped off under iOS when Camera.DestinationType is File_URI Key: CB-13950 URL: https://issues.apache.org/jira/browse/CB-13950 Project: Apache Cordova Issue Type: Bug Components: cordova-plugin-camera Affects Versions: cordova-ios 4.5.0 Reporter: Junran When Camera.DestinationType is File_URI All exif metadata is stripped off under iOS This is inconsistent with what it is under Android. It seems the code have implemented to reattached the exif metadata when writing to temporary file path, but it doesn't work. A way to retain the exif data when using File_URI under iOS is needed. Any idea is much appreciated. Thanks! -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
