[jira] [Commented] (CB-9205) Whitelist "launch-external" setting does nothing
[
https://issues.apache.org/jira/browse/CB-9205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15054837#comment-15054837
]
Jesse Monroy commented on CB-9205:
--
please see the response I left for Steve.
> Whitelist "launch-external" setting does nothing
>
>
> Key: CB-9205
> URL: https://issues.apache.org/jira/browse/CB-9205
> Project: Apache Cordova
> Issue Type: Bug
> Components: Plugin Whitelist
>Affects Versions: 3.8.0
> Environment: OSX 10.10
> Cordova 3.8.0
> iOS 8.3
>Reporter: Steve Hull
>
> according to [cordova
> docs|http://cordova.apache.org/docs/en/4.0.0/guide_appdev_whitelist_index.md.html#external-application-whitelist],
> you should be able to specify in the config file which urls will open in an
> external browser by setting:
> {{http://example.com/*; launch-external="yes" />}}
> However this does nothing.
> I've looked into the definition of {{shouldStartLoadWithRequest}}, and it
> does indeed have a line near the bottom that would load the url in the
> external system browser ({{[[UIApplication sharedApplication]
> openURL:url]}}), however it appears that it would be impossible for this line
> to be executed as long as the protocol is {{http}} or {{https}}.
> I'm not sure what the "correct" way is to address this, however it seems that
> old versions of the docs should be updated to reflect that
> {{launch-external}} does not do anything and maybe we could start paying
> attention to that config attribute going forward.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-9205) Whitelist "launch-external" setting does nothing
[
https://issues.apache.org/jira/browse/CB-9205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15054835#comment-15054835
]
Jesse Monroy commented on CB-9205:
--
[~shull] The item you describe was deprecated soon after it was created. The
documentation never kept pace. You should be on a more recent version;
something in the 5.x range.
For the feature you want, the new construct is: `` and
``. You can find up to date documentation in the
[whitelist
Guide|http://cordova.apache.org/docs/en/5.4.0/guide/appdev/whitelist/index.html]
and
[cordova-whitelist-plugin|https://www.npmjs.com/package/cordova-plugin-whitelist]
> Whitelist "launch-external" setting does nothing
>
>
> Key: CB-9205
> URL: https://issues.apache.org/jira/browse/CB-9205
> Project: Apache Cordova
> Issue Type: Bug
> Components: Plugin Whitelist
>Affects Versions: 3.8.0
> Environment: OSX 10.10
> Cordova 3.8.0
> iOS 8.3
>Reporter: Steve Hull
>
> according to [cordova
> docs|http://cordova.apache.org/docs/en/4.0.0/guide_appdev_whitelist_index.md.html#external-application-whitelist],
> you should be able to specify in the config file which urls will open in an
> external browser by setting:
> {{http://example.com/*; launch-external="yes" />}}
> However this does nothing.
> I've looked into the definition of {{shouldStartLoadWithRequest}}, and it
> does indeed have a line near the bottom that would load the url in the
> external system browser ({{[[UIApplication sharedApplication]
> openURL:url]}}), however it appears that it would be impossible for this line
> to be executed as long as the protocol is {{http}} or {{https}}.
> I'm not sure what the "correct" way is to address this, however it seems that
> old versions of the docs should be updated to reflect that
> {{launch-external}} does not do anything and maybe we could start paying
> attention to that config attribute going forward.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-10153) WKWebview does not respect the webkit-playsinline attribute
[ https://issues.apache.org/jira/browse/CB-10153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15054798#comment-15054798 ] Jesse Monroy commented on CB-10153: --- [~Wessberg] Can you add your meta tag for CSP? > WKWebview does not respect the webkit-playsinline attribute > --- > > Key: CB-10153 > URL: https://issues.apache.org/jira/browse/CB-10153 > Project: Apache Cordova > Issue Type: Bug > Components: Plugin WKWebViewEngine >Affects Versions: 4.0.0 > Environment: iPhone 5s, Cordova 5.4.1, iOS 9.1 >Reporter: Frederik Wessberg > Labels: cordova-ios-4.0.1 > > With the config.xml preference "AllowInlineMediaPlayback" set to true and the > attribute "webkit-playsinline" set on HTML5 video elements, you would expect > the media to play inline on iPhone devices such as on UIWebview. > Looking in the CDVWKWebViewEngine.m file, the property is correctly bound to > the WKWebview config object: > wkWebView.configuration.allowsInlineMediaPlayback = [settings > cordovaBoolSettingForKey:@"AllowInlineMediaPlayback" defaultValue:NO]; > However, video elements does NOT play inline. > Here's a repo that shows this behavior: > https://github.com/dlmma/NoInline -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-9989) Windows app throwing Internal server error when try to login. Cordova Ver: 4.1.0.
[ https://issues.apache.org/jira/browse/CB-9989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15054833#comment-15054833 ] Jesse Monroy commented on CB-9989: -- [~asmdevmob] were you able to test your app without the whitelist plugin? Was it still failing? > Windows app throwing Internal server error when try to login. Cordova Ver: > 4.1.0. > - > > Key: CB-9989 > URL: https://issues.apache.org/jira/browse/CB-9989 > Project: Apache Cordova > Issue Type: Bug > Components: Plugin Whitelist >Affects Versions: 4.0.0 > Environment: Windows >Reporter: asm > > Windows app throwing Internal server error when try to login. Cordova Ver: > 4.1.0. Is whitelist plugin is the issue? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Assigned] (CB-10193) Deprecate 'pre_package' hook for wp8/windows phone platform
[ https://issues.apache.org/jira/browse/CB-10193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Kotikov reassigned CB-10193: - Assignee: Vladimir Kotikov (was: Jesse MacFadyen) > Deprecate 'pre_package' hook for wp8/windows phone platform > --- > > Key: CB-10193 > URL: https://issues.apache.org/jira/browse/CB-10193 > Project: Apache Cordova > Issue Type: Task > Components: CordovaLib, Windows, WP8 >Reporter: Vladimir Kotikov >Assignee: Vladimir Kotikov > Labels: deprecation, pre_package > > We have a logic in Windows/wp8 parsers that fires a hooks, specific for these > particular platforms. There is some problems with this: > # This doesn't fits well into the concept of PlatformApi > # The original purpose of the hook is now lost. It was intended to be fired > in the [middle of > prepare|https://github.com/apache/cordova-lib/commit/bd2c667e947b3fda05541e0d1a124d23df60a132], > to allow to modify www folder before it will be packed into app package, but > now it get fired right before the end of platform preparation, and hence > almost equal to 'after_prepare'. > The only problem with using 'after_prepare' instead of 'pre_package' is when > plugin (or user) decides to modify www files, they won't be BOMed by > platform. This can be workarounded by moving 'add_bom' logic from prepare to > build in PlatformApi for Windows. This way BOM will still be added _after_ > 'pre_package'. > So the proposed plan is: > # Do not touch 'pre_package' if 'old' platform is used (via PlatformApi > polyfill) > # If the 'new' platform is used, 'pre_package' doesn't emitted by platform, > so we need to emit it manually (right before 'after_prepare' - to keep the > order of hooks unchanged) > # Move bomify from prepare to build in Windows PlatformApi, so www sources > will be not-yet-bomified in 'pre_package' > # Add a notice about 'pre_package' deprecation and removal to HookRunner -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Updated] (CB-10193) Deprecate 'pre_package' hook for wp8/windows phone platform
[ https://issues.apache.org/jira/browse/CB-10193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Kotikov updated CB-10193: -- Description: We have a logic in Windows/wp8 parsers that fires a hooks, specific for these particular platforms. There is some problems with this: # This doesn't fits well into the concept of PlatformApi # The original purpose of the hook is now lost. It was intended to be fired in the [middle of prepare|https://github.com/apache/cordova-lib/commit/bd2c667e947b3fda05541e0d1a124d23df60a132], to allow to modify www folder before it will be packed into app package, but now it get fired right before the end of platform preparation, and hence almost equal to 'after_prepare'. The only problem with using 'after_prepare' instead of 'pre_package' is when plugin (or user) decides to modify www files, they won't be BOMed by platform. This can be workarounded by moving 'add_bom' logic from prepare to build in PlatformApi for Windows. This way BOM will still be added _after_ 'pre_package'. So the proposed plan is: # Do not touch 'pre_package' if 'old' platform is used (via PlatformApi polyfill) # If the 'new' platform is used, 'pre_package' doesn't emitted by platform, so we need to emit it manually (right before 'after_prepare' - to keep the order of hooks unchanged) # Move bomify from prepare to build in Windows PlatformApi, so www sources will be not-yet-bomified in 'pre_package' # Add a notice about 'pre_package' deprecation and removal to HookRunner was: We have a logic in Windows/wp8 parsers that fires a hooks, specific for these particular platforms. There is some problems with this: 1 This doesn't fits well into the concept of PlatformApi 2 The original purpose of the hook is now lost. It was intended to be fired in the [middle of prepare|https://github.com/apache/cordova-lib/commit/bd2c667e947b3fda05541e0d1a124d23df60a132], to allow to modify www folder before it will be packed into app package, but now it get fired right before the end of platform preparation, and hence almost equal to 'after_prepare'. The only problem with using 'after_prepare' instead of 'pre_package' is when plugin (or user) decides to modify www files, they won't be BOMed by platform. This can be workarounded by moving 'add_bom' logic from prepare to build in PlatformApi for Windows. This way BOM will still be added _after_ 'pre_package'. So the proposed plan is: 1. Do not touch 'pre_package' if 'old' platform is used (via PlatformApi polyfill) 2. If the 'new' platform is used, 'pre_package' doesn't emitted by platform, so we need to emit it manually (right before 'after_prepare' - to keep the order of hooks unchanged) 3. Move bomify from prepare to build in Windows PlatformApi, so www sources will be not-yet-bomified in 'pre_package' 4. Add a notice about 'pre_package' deprecation and removal to HookRunner > Deprecate 'pre_package' hook for wp8/windows phone platform > --- > > Key: CB-10193 > URL: https://issues.apache.org/jira/browse/CB-10193 > Project: Apache Cordova > Issue Type: Task > Components: CordovaLib, Windows, WP8 >Reporter: Vladimir Kotikov >Assignee: Jesse MacFadyen > Labels: deprecation, pre_package > > We have a logic in Windows/wp8 parsers that fires a hooks, specific for these > particular platforms. There is some problems with this: > # This doesn't fits well into the concept of PlatformApi > # The original purpose of the hook is now lost. It was intended to be fired > in the [middle of > prepare|https://github.com/apache/cordova-lib/commit/bd2c667e947b3fda05541e0d1a124d23df60a132], > to allow to modify www folder before it will be packed into app package, but > now it get fired right before the end of platform preparation, and hence > almost equal to 'after_prepare'. > The only problem with using 'after_prepare' instead of 'pre_package' is when > plugin (or user) decides to modify www files, they won't be BOMed by > platform. This can be workarounded by moving 'add_bom' logic from prepare to > build in PlatformApi for Windows. This way BOM will still be added _after_ > 'pre_package'. > So the proposed plan is: > # Do not touch 'pre_package' if 'old' platform is used (via PlatformApi > polyfill) > # If the 'new' platform is used, 'pre_package' doesn't emitted by platform, > so we need to emit it manually (right before 'after_prepare' - to keep the > order of hooks unchanged) > # Move bomify from prepare to build in Windows PlatformApi, so www sources > will be not-yet-bomified in 'pre_package' > # Add a notice about 'pre_package' deprecation and removal to HookRunner -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe,
[jira] [Assigned] (CB-10193) Deprecate 'pre_package' hook for wp8/windows phone platform
[ https://issues.apache.org/jira/browse/CB-10193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Kotikov reassigned CB-10193: - Assignee: (was: Vladimir Kotikov) > Deprecate 'pre_package' hook for wp8/windows phone platform > --- > > Key: CB-10193 > URL: https://issues.apache.org/jira/browse/CB-10193 > Project: Apache Cordova > Issue Type: Task > Components: CordovaLib, Windows, WP8 >Reporter: Vladimir Kotikov > Labels: deprecation, pre_package > > We have a logic in Windows/wp8 parsers that fires a hooks, specific for these > particular platforms. There is some problems with this: > # This doesn't fits well into the concept of PlatformApi > # The original purpose of the hook is now lost. It was intended to be fired > in the [middle of > prepare|https://github.com/apache/cordova-lib/commit/bd2c667e947b3fda05541e0d1a124d23df60a132], > to allow to modify www folder before it will be packed into app package, but > now it get fired right before the end of platform preparation, and hence > almost equal to 'after_prepare'. > The only problem with using 'after_prepare' instead of 'pre_package' is when > plugin (or user) decides to modify www files, they won't be BOMed by > platform. This can be workarounded by moving 'add_bom' logic from prepare to > build in PlatformApi for Windows. This way BOM will still be added _after_ > 'pre_package'. > So the proposed plan is: > # Do not touch 'pre_package' if 'old' platform is used (via PlatformApi > polyfill) > # If the 'new' platform is used, 'pre_package' doesn't emitted by platform, > so we need to emit it manually (right before 'after_prepare' - to keep the > order of hooks unchanged) > # Move bomify from prepare to build in Windows PlatformApi, so www sources > will be not-yet-bomified in 'pre_package' > # Add a notice about 'pre_package' deprecation and removal to HookRunner -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Updated] (CB-10192) Native Android Contacts app crashed after creating new contact in Cordova app
[ https://issues.apache.org/jira/browse/CB-10192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Kotikov updated CB-10192: -- Labels: Android contact.save (was: contact.save) > Native Android Contacts app crashed after creating new contact in Cordova app > - > > Key: CB-10192 > URL: https://issues.apache.org/jira/browse/CB-10192 > Project: Apache Cordova > Issue Type: Bug > Components: Plugin Contacts > Environment: Google Nexus 6 Marshmallow >Reporter: Sumama Waheed > Labels: Android, contact.save > > I successfully create a new contact with minimal fields like First Name and > Given Name. > The contact is created successfully and you can see it in the native Android > contacts app if you scroll to the correct place. > However, if you search for the new contact by name, it crashes the Contacts > app every time until you delete that contact !!. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Created] (CB-10193) Deprecate 'pre_package' hook for wp8/windows phone platform
Vladimir Kotikov created CB-10193: - Summary: Deprecate 'pre_package' hook for wp8/windows phone platform Key: CB-10193 URL: https://issues.apache.org/jira/browse/CB-10193 Project: Apache Cordova Issue Type: Task Components: CordovaLib, Windows, WP8 Reporter: Vladimir Kotikov Assignee: Jesse MacFadyen We have a logic in Windows/wp8 parsers that fires a hooks, specific for these particular platforms. There is some problems with this: 1 This doesn't fits well into the concept of PlatformApi 2 The original purpose of the hook is now lost. It was intended to be fired in the [middle of prepare|https://github.com/apache/cordova-lib/commit/bd2c667e947b3fda05541e0d1a124d23df60a132], to allow to modify www folder before it will be packed into app package, but now it get fired right before the end of platform preparation, and hence almost equal to 'after_prepare'. The only problem with using 'after_prepare' instead of 'pre_package' is when plugin (or user) decides to modify www files, they won't be BOMed by platform. This can be workarounded by moving 'add_bom' logic from prepare to build in PlatformApi for Windows. This way BOM will still be added _after_ 'pre_package'. So the proposed plan is: 1. Do not touch 'pre_package' if 'old' platform is used (via PlatformApi polyfill) 2. If the 'new' platform is used, 'pre_package' doesn't emitted by platform, so we need to emit it manually (right before 'after_prepare' - to keep the order of hooks unchanged) 3. Move bomify from prepare to build in Windows PlatformApi, so www sources will be not-yet-bomified in 'pre_package' 4. Add a notice about 'pre_package' deprecation and removal to HookRunner -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-10192) Native Android Contacts app crashed after creating new contact in Cordova app
[
https://issues.apache.org/jira/browse/CB-10192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15054145#comment-15054145
]
Vladimir Kotikov commented on CB-10192:
---
[~swaheed2], please add more details to the bug: Cordova version (you can get
it by running {{cordova --version}} in console), platform and plugin version
({{cordova platform ls && cordova plugin ls}}), and the parameters, you're
passing to {{navigator.contacts.find()}}.
> Native Android Contacts app crashed after creating new contact in Cordova app
> -
>
> Key: CB-10192
> URL: https://issues.apache.org/jira/browse/CB-10192
> Project: Apache Cordova
> Issue Type: Bug
> Components: Plugin Contacts
> Environment: Google Nexus 6 Marshmallow
>Reporter: Sumama Waheed
> Labels: Android, contact.save
>
> I successfully create a new contact with minimal fields like First Name and
> Given Name.
> The contact is created successfully and you can see it in the native Android
> contacts app if you scroll to the correct place.
> However, if you search for the new contact by name, it crashes the Contacts
> app every time until you delete that contact !!.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-10109) Allow WKWebView to proxy file:// url loading in XmlHttpRequest.open
[ https://issues.apache.org/jira/browse/CB-10109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15054330#comment-15054330 ] Carlos Santana commented on CB-10109: - Well I think CB-10144 is not a as critical as this one, most REST APIs have CORS headers. So there is a sense workaround. But I agree, using UIWebView might be a good option for that corner case, I would prefer to fix local file, or better yet WebKit/Apple to fix this one. Allowing cross-domain or file://, I think Apple should provide a way to declare domain exceptions, similarly as ATS > Allow WKWebView to proxy file:// url loading in XmlHttpRequest.open > --- > > Key: CB-10109 > URL: https://issues.apache.org/jira/browse/CB-10109 > Project: Apache Cordova > Issue Type: Wish > Components: Plugin WKWebViewEngine >Reporter: Shazron Abdullah > Labels: wkwebview-known-issues > > Because of CORS, you can only open requests using http*:// schemes, not file. > Ultimately this might be a new plugin. The plugin needs to: > 1. Run a local webserver > 2. Proxy XmlHttpRequest.open and rewrite urls that go to (1) > The local webserver in (1) will route the requests using the appropriate > handler, and will need to utilize a secret to prevent unauthorized access. > Something like this: > https://github.com/phonegap/connect-phonegap/blob/master/res/middleware/proxy.js -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Created] (CB-10194) Whitelist plugin prints info message for other none android platforms
Carlos Santana created CB-10194: --- Summary: Whitelist plugin prints info message for other none android platforms Key: CB-10194 URL: https://issues.apache.org/jira/browse/CB-10194 Project: Apache Cordova Issue Type: Bug Components: Plugin Whitelist Affects Versions: 1.2.0 Reporter: Carlos Santana Assignee: Carlos Santana When adding ios platform the info message about andorid prints $ cordova platform add ios Adding ios project... iOS project created with cordova-ios@3.9.2 Discovered plugin "cordova-plugin-whitelist" in config.xml. Installing to the project Fetching plugin "cordova-plugin-whitelist@1" via npm Installing "cordova-plugin-whitelist" for ios This plugin is only applicable for versions of cordova-android greater than 4.0. If you have a previous platform version, you do *not* need this plugin since the whitelist will be built in. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Resolved] (CB-10194) Whitelist plugin prints info message for other none android platforms
[ https://issues.apache.org/jira/browse/CB-10194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Santana resolved CB-10194. - Resolution: Fixed Fix Version/s: Master > Whitelist plugin prints info message for other none android platforms > - > > Key: CB-10194 > URL: https://issues.apache.org/jira/browse/CB-10194 > Project: Apache Cordova > Issue Type: Bug > Components: Plugin Whitelist >Affects Versions: 1.2.0 >Reporter: Carlos Santana >Assignee: Carlos Santana > Labels: ios > Fix For: Master > > > When adding ios platform the info message about andorid prints > $ cordova platform add ios > Adding ios project... > iOS project created with cordova-ios@3.9.2 > Discovered plugin "cordova-plugin-whitelist" in config.xml. Installing to the > project > Fetching plugin "cordova-plugin-whitelist@1" via npm > Installing "cordova-plugin-whitelist" for ios > This plugin is only applicable for versions of cordova-android greater than > 4.0. If you have a previous platform version, you do *not* need this plugin > since the whitelist will be built in. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-10194) Whitelist plugin prints info message for other none android platforms
[ https://issues.apache.org/jira/browse/CB-10194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15054338#comment-15054338 ] ASF subversion and git services commented on CB-10194: -- Commit c2541d37a37dee4d7b4e6120118ce108b307002e in cordova-plugin-whitelist's branch refs/heads/master from [~csantana] [ https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-whitelist.git;h=c2541d3 ] CB-10194 info tag prints for ios when not applicable > Whitelist plugin prints info message for other none android platforms > - > > Key: CB-10194 > URL: https://issues.apache.org/jira/browse/CB-10194 > Project: Apache Cordova > Issue Type: Bug > Components: Plugin Whitelist >Affects Versions: 1.2.0 >Reporter: Carlos Santana >Assignee: Carlos Santana > Labels: ios > > When adding ios platform the info message about andorid prints > $ cordova platform add ios > Adding ios project... > iOS project created with cordova-ios@3.9.2 > Discovered plugin "cordova-plugin-whitelist" in config.xml. Installing to the > project > Fetching plugin "cordova-plugin-whitelist@1" via npm > Installing "cordova-plugin-whitelist" for ios > This plugin is only applicable for versions of cordova-android greater than > 4.0. If you have a previous platform version, you do *not* need this plugin > since the whitelist will be built in. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Created] (CB-10195) Ubuntu Cordova command failed with exit code 1 on cordova build ubuntu - 5.4.0
Tumiso created CB-10195: --- Summary: Ubuntu Cordova command failed with exit code 1 on cordova build ubuntu - 5.4.0 Key: CB-10195 URL: https://issues.apache.org/jira/browse/CB-10195 Project: Apache Cordova Issue Type: Bug Components: CLI Affects Versions: 5.4.0 Environment: Ubuntu 15.10, cordova 5.4.0 Reporter: Tumiso Fix For: 5.4.0 Folowed the ubuntu/ cordova installations here. Everything works fine until I get to the command cordova build ubuntu. I always get this error: Building Desktop Application... Missing icon ERROR building one of the platforms: Error: /var/www/html/bye/platforms/ubuntu/cordova/build: Command failed with exit code 1 You may not have the required environment or OS to build this project Error: /var/www/html/bye/platforms/ubuntu/cordova/build: Command failed with exit code 1 at ChildProcess.whenDone (/usr/share/cordova-cli/node_modules/cordova-lib/src/cordova/superspawn.js:131:23) at ChildProcess.EventEmitter.emit (events.js:98:17) at maybeClose (child_process.js:743:16) at Process.ChildProcess._handle.onexit (child_process.js:810:5)" Please could someone tell me how to fix this or what I'm doing wrong to get the error? I've tried reinstalling, creating an icon tag in the config.xml to replace the default icon and I've tried installing different version of Cordova (currently on 5.4.0). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
