[jira] [Commented] (CB-8047) [WKWebView][iOS8] wkwebview / local webserver plugin orientation issue

[Shazron Abdullah (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-8047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700743#comment-14700743
 ] 

Shazron Abdullah commented on CB-8047:
--

I like the active approach like you described versus the passive one that we 
had. 

cordova-ios CDVViewController already implements CDVScreenOrientationDelegate 
-- instead we could make the delegate a property on CDVViewController, then 
create an included plugin that implements CDVScreenOrientationDelegate but also 
is set as the orientation delegate for CDVViewController. This included plugin 
can then handle the JavaScript interface you described. This new plugin will 
also handle any orientation code that currently exists in CDVViewController 
(basically move all the orientation code there).

Users however will have to wait for the success callback from setting the 
orientation before seeing the effect, however. This might be undesirable during 
the duration of the call, not sure of the visual impact yet, will have to test 
it out. It might just be fast enough to not make a difference.



> [WKWebView][iOS8] wkwebview / local webserver plugin orientation issue
> --
>
> Key: CB-8047
> URL: https://issues.apache.org/jira/browse/CB-8047
> Project: Apache Cordova
>  Issue Type: Sub-task
>  Components: iOS
> Environment: IOS
>Reporter: Dustin Nielson
>Assignee: Shazron Abdullah
> Fix For: 4.0.0
>
>
> After installing the `wkwebview-engine` plugin on ios device (tested iPhone 
> 6, iPad mini 2, iPad retina) and enabling all orientations in xcode.  Upon 
> successful build the devices have fixed portrait orientation that doesn't 
> change when device is rotated.
> The `wkwebview` branch of cordova-ios was used. This problem does not occur 
> in the `master` branch.



--
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-8047) [WKWebView][iOS8] wkwebview / local webserver plugin orientation issue

[Andrey Kurdyumov (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-8047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700691#comment-14700691
 ] 

Andrey Kurdyumov commented on CB-8047:
--

I too think similar functionality is important. Maybe we could at least provide 
alternative where developer could dynamically set values which would be 
returned from {code}supportedInterfaceOrientations{code} and 
{code}preferredInterfaceOrientationForPresentation{code} methods.

Something like that:

{code}
// javscript
setSupportedInterfaceOrientations(...)
// This will save value passed in iOS side
...
// Later in iOS that value would be returned by supportedInterfaceOrientations 
{code}

> [WKWebView][iOS8] wkwebview / local webserver plugin orientation issue
> --
>
> Key: CB-8047
> URL: https://issues.apache.org/jira/browse/CB-8047
> Project: Apache Cordova
>  Issue Type: Sub-task
>  Components: iOS
> Environment: IOS
>Reporter: Dustin Nielson
>Assignee: Shazron Abdullah
> Fix For: 4.0.0
>
>
> After installing the `wkwebview-engine` plugin on ios device (tested iPhone 
> 6, iPad mini 2, iPad retina) and enabling all orientations in xcode.  Upon 
> successful build the devices have fixed portrait orientation that doesn't 
> change when device is rotated.
> The `wkwebview` branch of cordova-ios was used. This problem does not occur 
> in the `master` branch.



--
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-8047) [WKWebView][iOS8] wkwebview / local webserver plugin orientation issue

[Shazron Abdullah (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-8047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700677#comment-14700677
 ] 

Shazron Abdullah commented on CB-8047:
--

1. CB-5690 and CB-8893 were filed. The docs for this unfortunately were added 
in the cli docs starting with 5.x, very recently

2. Yes. That function has been deprecated since iOS 6.0, and the docs recommend 
users to use: "Override the supportedInterfaceOrientations and 
preferredInterfaceOrientationForPresentation methods instead."

Thanks Tony -- yeah I didn't want to remove this but I couldn't find and 
alternative.

> [WKWebView][iOS8] wkwebview / local webserver plugin orientation issue
> --
>
> Key: CB-8047
> URL: https://issues.apache.org/jira/browse/CB-8047
> Project: Apache Cordova
>  Issue Type: Sub-task
>  Components: iOS
> Environment: IOS
>Reporter: Dustin Nielson
>Assignee: Shazron Abdullah
> Fix For: 4.0.0
>
>
> After installing the `wkwebview-engine` plugin on ios device (tested iPhone 
> 6, iPad mini 2, iPad retina) and enabling all orientations in xcode.  Upon 
> successful build the devices have fixed portrait orientation that doesn't 
> change when device is rotated.
> The `wkwebview` branch of cordova-ios was used. This problem does not occur 
> in the `master` branch.



--
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-9490) LG G4 camera application saves photos when using destinationType DATA_URL

[Cody Balos (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-9490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700664#comment-14700664
 ] 

Cody Balos commented on CB-9490:


A decision needs to be made about how this patch is implemented. I have a 
working, and tested fix ready to go, however, it introduces a potential "issue" 
that is actually kind of in existence already. Currently, the camera plugin 
checks the number of pictures saved to the device before any pictures are 
captured using the camera started via the plugin, and then checks the 
difference between the amount of photos before and after. Relying on this 
method introduces the possibility of deleting photos a user takes outside the 
cordova started camera. For example, consider this scenario: 

A user of a cordova application utilizes a cordova-plugin-camera backed camera 
feature , and while in the camera activity, switches to a different 
application. While in this different application the user takes a photo. Now 
the user returns to the cordova application, and is still in the camera 
activity. They take the photo, and accept it. Now the cleanup process inside 
cordova-plugin-camera begins, but, because of relying on the difference between 
the amount of photos before and after the activity, the photo the user took 
outside of the cordova application is deleted. 

Now the reason, I say this issue is kind of in existence already, is because 
the checkForDuplicateImage function, does have the ill behavior from the above 
example. However, it is limited by its implementation to removing no more than 
2 of the photos taken outside of the cordova application. 

So the question is, does this new issue from the example get ignored because of 
the low probability of it happening in actual use? If, not, what is the best 
way around this?

> LG G4 camera application saves photos when using destinationType DATA_URL
> -
>
> Key: CB-9490
> URL: https://issues.apache.org/jira/browse/CB-9490
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Plugin Camera
> Environment: LG G4, Android 5.1
>Reporter: Cody Balos
>Assignee: Cody Balos
>  Time Spent: 6h
>  Remaining Estimate: 0h
>
> So far this issue only happens on an LG G4 using the stock camera application:
> Using the camera plugin, with destinationType set to DATA_URL,
> the expected functionality is for the base64 string to be returned to the 
> javascript interface, and not saved to the file system without explicitly 
> saving it separately. Using the LG G4 stock camera application, all photos 
> are saved even when using destinationType DATA_URL if the retake option is 
> used. 
> The issue does not occur when using the Google Camera application or Camera 
> 360 (both on the Play Store). 



--
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-9500) [CB-8485] Not allowed to have XCodeProject display name different from Cordova project name

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700590#comment-14700590
 ] 

ASF GitHub Bot commented on CB-9500:


Github user nikhilkh commented on the pull request:

https://github.com/apache/cordova-ios/pull/152#issuecomment-132024453
  
Another option is to use 'xcode' node module to parse the `productname` 
which corresponds with the .app name and find it .app file to sign. 
Alternative, shell.ls can be used to find the .app file and create an ipa. 

I want to question why would you have a different name for the .xcodeproj 
and the app name? I noticed, we allow changing the name in config.xml and 
thereafter being able to update .xcodeproj name and the product name - does 
that not work for you?


> [CB-8485] Not allowed to have XCodeProject display name different from 
> Cordova project name
> ---
>
> Key: CB-9500
> URL: https://issues.apache.org/jira/browse/CB-9500
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: iOS
>Affects Versions: 5.2.0
> Environment: Mac OS X
>Reporter: Nicholas Farley
>Priority: Minor
>  Labels: compile, compile-error, compilerconfiguration, 
> conversion, error, ios, name, xcode
> Fix For: 5.2.0
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> The recent changes to the compile command (CB-8485) have introduced an issue 
> on iOS. Specifically, the inline creation of the signed archive, have made it 
> impossible to have an iOS applications display name be different from the 
> Cordova project name. 
> The archive generation process expects the .app name to have the same 
> basename as the name listed in the XCodeProject. If it does not find the .app 
> at this position, it fails the conversion and the entire compile process. 
> The .app it creates is based upon the Cordova project name. The name in the 
> XCodeProject is the name used for applications name when it is on a device, 
> so now this name must match the project name or the signed archive won't be 
> created.
> This can be fixed in a number of ways. 
>  - Include a "no-sign" option, which would mimic the old behavior.
>  - Include a way to pass the desired name to compile.
>  - Have the .app name be pulled from some other configuration that isn't tied 
> to a the iOS display name. 



--
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-9504) cordova-plugin-file release, August 17, 2015

[Steve Gill (JIRA)]

Steve Gill created CB-9504:
--

 Summary: cordova-plugin-file release, August 17, 2015
 Key: CB-9504
 URL: https://issues.apache.org/jira/browse/CB-9504
 Project: Apache Cordova
  Issue Type: Task
  Components: Plugin File
Affects Versions: 2.1.0
Reporter: Steve Gill
Assignee: Steve Gill
 Fix For: 3.0.0


Following 
https://github.com/apache/cordova-coho/blob/master/docs/plugins-release-process.md



--
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-9464) Cordova-WebOS Platform Release August 5, 2015

[Steve Gill (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CB-9464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Gill resolved CB-9464.

Resolution: Fixed

> Cordova-WebOS Platform Release August 5, 2015
> -
>
> Key: CB-9464
> URL: https://issues.apache.org/jira/browse/CB-9464
> Project: Apache Cordova
>  Issue Type: Task
>Reporter: Suraj Pindoria
>
> Following steps at 
> https://github.com/apache/cordova-coho/blob/master/docs/platforms-release-process.md



--
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-8054) Camera getPicture photo library not supported on Windows?

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-8054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700518#comment-14700518
 ] 

ASF GitHub Bot commented on CB-8054:


Github user ekambarrao commented on the pull request:


https://github.com/apache/cordova-plugin-camera/pull/86#issuecomment-132004684
  
i have a question...do i need to capture the state of the app while 
capturing the photo or gone to library? or the plugin will take care of that?


> Camera getPicture photo library not supported on Windows?
> -
>
> Key: CB-8054
> URL: https://issues.apache.org/jira/browse/CB-8054
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Plugin Camera, Windows
>Affects Versions: 3.7.1
> Environment: Windows Phone 8.1
> Lumia 635
> Windows universal app platform
> Camera plugin v0.3.3
>Reporter: Boston Dell-Vandenberg
>Assignee: Murat Sutunc
>
> On the Windows platform when calling getPicture() with "sourceType" of 
> "PHOTOLIBRARY" or "SAVEDPHOTOALBUM" it returns "Not supported" error. 
> The plugin documentation says Windows is supported but is that not the case?



--
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-9446) Samsung device returns null from Cursor in Camera getRealPath

[Charles Verge (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CB-9446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Charles Verge updated CB-9446:
--
Labels: samsung  (was: )

> Samsung device returns null from Cursor in Camera getRealPath
> -
>
> Key: CB-9446
> URL: https://issues.apache.org/jira/browse/CB-9446
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android, Plugin Camera, Plugin Media Capture
>Affects Versions: 1.2.1
> Environment: Samsung 4.1.2 GT-N8010
>Reporter: Charles Verge
>  Labels: samsung
> Fix For: 1.2.1
>
> Attachments: realpath.diff
>
>
> Using a Samsung Galaxy Note GT-N8010 with android 4.1.2 produces an exception 
> in the Exif class. This is due to a filePath being null on line 66 of 
> src/android/ExifHelper.java
> {code} new ExifInterface(filePath){code}
> This error has been introduced when the switch was made to using Cursors. 
> This error did not happen in with the camera plugin bundled with Phone Gap 
> 3.4.
> This has been duplicated by other developers independently 
> http://stackoverflow.com/questions/30616846/phonegap-app-crash-when-take-a-new-photo-with-camera-plugin



--
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-8054) Camera getPicture photo library not supported on Windows?

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-8054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700507#comment-14700507
 ] 

ASF GitHub Bot commented on CB-8054:


Github user ekambarrao commented on the pull request:


https://github.com/apache/cordova-plugin-camera/pull/86#issuecomment-13200
  
Thanks guys...for taking time on this


> Camera getPicture photo library not supported on Windows?
> -
>
> Key: CB-8054
> URL: https://issues.apache.org/jira/browse/CB-8054
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Plugin Camera, Windows
>Affects Versions: 3.7.1
> Environment: Windows Phone 8.1
> Lumia 635
> Windows universal app platform
> Camera plugin v0.3.3
>Reporter: Boston Dell-Vandenberg
>Assignee: Murat Sutunc
>
> On the Windows platform when calling getPicture() with "sourceType" of 
> "PHOTOLIBRARY" or "SAVEDPHOTOALBUM" it returns "Not supported" error. 
> The plugin documentation says Windows is supported but is that not the case?



--
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-8054) Camera getPicture photo library not supported on Windows?

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-8054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700506#comment-14700506
 ] 

ASF GitHub Bot commented on CB-8054:


Github user nikhilkh commented on the pull request:


https://github.com/apache/cordova-plugin-camera/pull/86#issuecomment-132002862
  
I agree with @purplecabbage that this is not the correct forum for this. 
Please use stack overflow and mark it with visual studio cordova. People from 
the product team look at that forum and will respond to you.


> Camera getPicture photo library not supported on Windows?
> -
>
> Key: CB-8054
> URL: https://issues.apache.org/jira/browse/CB-8054
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Plugin Camera, Windows
>Affects Versions: 3.7.1
> Environment: Windows Phone 8.1
> Lumia 635
> Windows universal app platform
> Camera plugin v0.3.3
>Reporter: Boston Dell-Vandenberg
>Assignee: Murat Sutunc
>
> On the Windows platform when calling getPicture() with "sourceType" of 
> "PHOTOLIBRARY" or "SAVEDPHOTOALBUM" it returns "Not supported" error. 
> The plugin documentation says Windows is supported but is that not the case?



--
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-8054) Camera getPicture photo library not supported on Windows?

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-8054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700501#comment-14700501
 ] 

ASF GitHub Bot commented on CB-8054:


Github user purplecabbage commented on the pull request:


https://github.com/apache/cordova-plugin-camera/pull/86#issuecomment-132002001
  
Okay, it appears you are doing some magic with the Visual Studio TACO ( 
tools for apache cordova )
You will need to bring this up with the visual studio team, as ultimately 
what you are running is NOT strictly a cordova project.  
I was able to run your javascript(2) version as posted, but the 
BlankCordovaApp1 app was missing multiple files and could not be built.
Ultimately this is not the place to have this discussion, as it has nothing 
to do with this pull request.
If you need to discuss this further, please open a jira issue, or contact 
me on the cordova slack channel.
to join :
http://slack.cordova.io/ 
to view :
https://cordova.slack.com/

I am @purplecabbage everywhere.




> Camera getPicture photo library not supported on Windows?
> -
>
> Key: CB-8054
> URL: https://issues.apache.org/jira/browse/CB-8054
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Plugin Camera, Windows
>Affects Versions: 3.7.1
> Environment: Windows Phone 8.1
> Lumia 635
> Windows universal app platform
> Camera plugin v0.3.3
>Reporter: Boston Dell-Vandenberg
>Assignee: Murat Sutunc
>
> On the Windows platform when calling getPicture() with "sourceType" of 
> "PHOTOLIBRARY" or "SAVEDPHOTOALBUM" it returns "Not supported" error. 
> The plugin documentation says Windows is supported but is that not the case?



--
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-8054) Camera getPicture photo library not supported on Windows?

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-8054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700409#comment-14700409
 ] 

ASF GitHub Bot commented on CB-8054:


Github user ekambarrao commented on the pull request:


https://github.com/apache/cordova-plugin-camera/pull/86#issuecomment-131989448
  
https://onedrive.live.com/embed?cid=463D607901FE1563&resid=463D607901FE1563%21114&authkey=ADmtINFmJhqVSBI";
 width="165" height="128" frameborder="0" scrolling="no"> 


> Camera getPicture photo library not supported on Windows?
> -
>
> Key: CB-8054
> URL: https://issues.apache.org/jira/browse/CB-8054
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Plugin Camera, Windows
>Affects Versions: 3.7.1
> Environment: Windows Phone 8.1
> Lumia 635
> Windows universal app platform
> Camera plugin v0.3.3
>Reporter: Boston Dell-Vandenberg
>Assignee: Murat Sutunc
>
> On the Windows platform when calling getPicture() with "sourceType" of 
> "PHOTOLIBRARY" or "SAVEDPHOTOALBUM" it returns "Not supported" error. 
> The plugin documentation says Windows is supported but is that not the case?



--
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-9447) Cordova-Windows Platform Release August 18, 2015

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-9447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700395#comment-14700395
 ] 

ASF subversion and git services commented on CB-9447:
-

Commit 27daf92767d0fbc5fe5101cac9389d1e68775d02 in cordova-windows's branch 
refs/heads/master from [~robpaveza]
[ https://git-wip-us.apache.org/repos/asf?p=cordova-windows.git;h=27daf92 ]

CB-9447 updated RELEASENOTES


> Cordova-Windows Platform Release August 18, 2015
> 
>
> Key: CB-9447
> URL: https://issues.apache.org/jira/browse/CB-9447
> Project: Apache Cordova
>  Issue Type: Task
>  Components: Windows
>Affects Versions: 4.1.0
>Reporter: Rob Paveza
>Assignee: Rob Paveza
>
> Following steps at 
> https://github.com/apache/cordova-coho/blob/master/docs/platforms-release-process.md



--
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-9447) Cordova-Windows Platform Release August 18, 2015

[Rob Paveza (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CB-9447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Paveza updated CB-9447:
---
Summary: Cordova-Windows Platform Release August 18, 2015  (was: 
Cordova-Windows Platform Release August 5, 2015)

> Cordova-Windows Platform Release August 18, 2015
> 
>
> Key: CB-9447
> URL: https://issues.apache.org/jira/browse/CB-9447
> Project: Apache Cordova
>  Issue Type: Task
>  Components: Windows
>Affects Versions: 4.1.0
>Reporter: Rob Paveza
>Assignee: Rob Paveza
>
> Following steps at 
> https://github.com/apache/cordova-coho/blob/master/docs/platforms-release-process.md



--
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-9499) Windows 10: x64-build fails to run when running on an x86 version of Node.js

[Rob Paveza (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CB-9499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Paveza resolved CB-9499.

Resolution: Fixed

> Windows 10: x64-build fails to run when running on an x86 version of Node.js
> 
>
> Key: CB-9499
> URL: https://issues.apache.org/jira/browse/CB-9499
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: mobile-spec, Windows
>Reporter: Rob Paveza
>Assignee: Rob Paveza
>Priority: Critical
>
> When running an x64 version of a Cordova app, if the Node.js process is 
> 32-bit, it will spawn 32-bit shells (like cmd.exe or PowerShell).  In such a 
> case, installing a 64-bit app with 64-bit dependencies will fail because of a 
> bug in the VS-packaged installation script, which doesn't check for package 
> architecture, but rather the system's processor architecture, which in a 
> 32-bit shell is reported as x86.
> This is particularly important because Mobilespec uses .NET components.  On 
> Windows 10, these components must be .NET Native compiled, which means that 
> they must be platform-specific compiled.  As a result, when running with 
> cordova run windows -- --archs=x64 --appx=uap
> Mobilespec will build but fail to be run, reporting missing dependencies in 
> the graph.



--
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-9499) Windows 10: x64-build fails to run when running on an x86 version of Node.js

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-9499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700341#comment-14700341
 ] 

ASF GitHub Bot commented on CB-9499:


Github user asfgit closed the pull request at:

https://github.com/apache/cordova-windows/pull/116


> Windows 10: x64-build fails to run when running on an x86 version of Node.js
> 
>
> Key: CB-9499
> URL: https://issues.apache.org/jira/browse/CB-9499
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: mobile-spec, Windows
>Reporter: Rob Paveza
>Assignee: Rob Paveza
>Priority: Critical
>
> When running an x64 version of a Cordova app, if the Node.js process is 
> 32-bit, it will spawn 32-bit shells (like cmd.exe or PowerShell).  In such a 
> case, installing a 64-bit app with 64-bit dependencies will fail because of a 
> bug in the VS-packaged installation script, which doesn't check for package 
> architecture, but rather the system's processor architecture, which in a 
> 32-bit shell is reported as x86.
> This is particularly important because Mobilespec uses .NET components.  On 
> Windows 10, these components must be .NET Native compiled, which means that 
> they must be platform-specific compiled.  As a result, when running with 
> cordova run windows -- --archs=x64 --appx=uap
> Mobilespec will build but fail to be run, reporting missing dependencies in 
> the graph.



--
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-9499) Windows 10: x64-build fails to run when running on an x86 version of Node.js

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-9499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700340#comment-14700340
 ] 

ASF subversion and git services commented on CB-9499:
-

Commit 0a1ef0ae04acc46dd7384cd50eaf42ad97d3d9da in cordova-windows's branch 
refs/heads/master from [~robpaveza]
[ https://git-wip-us.apache.org/repos/asf?p=cordova-windows.git;h=0a1ef0a ]

CB-9499: There is a run failure when trying to deploy an x64 app when running 
on an x86 version of Node.  This change addresses the problem by modifying the 
run process by detecting an x64 app package as the primary, and setting the 
environment architecture to x64 before invoking PowerShell.. This closes #116


> Windows 10: x64-build fails to run when running on an x86 version of Node.js
> 
>
> Key: CB-9499
> URL: https://issues.apache.org/jira/browse/CB-9499
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: mobile-spec, Windows
>Reporter: Rob Paveza
>Assignee: Rob Paveza
>Priority: Critical
>
> When running an x64 version of a Cordova app, if the Node.js process is 
> 32-bit, it will spawn 32-bit shells (like cmd.exe or PowerShell).  In such a 
> case, installing a 64-bit app with 64-bit dependencies will fail because of a 
> bug in the VS-packaged installation script, which doesn't check for package 
> architecture, but rather the system's processor architecture, which in a 
> 32-bit shell is reported as x86.
> This is particularly important because Mobilespec uses .NET components.  On 
> Windows 10, these components must be .NET Native compiled, which means that 
> they must be platform-specific compiled.  As a result, when running with 
> cordova run windows -- --archs=x64 --appx=uap
> Mobilespec will build but fail to be run, reporting missing dependencies in 
> the graph.



--
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-9499) Windows 10: x64-build fails to run when running on an x86 version of Node.js

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-9499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700317#comment-14700317
 ] 

ASF GitHub Bot commented on CB-9499:


Github user robpaveza commented on a diff in the pull request:

https://github.com/apache/cordova-windows/pull/116#discussion_r37243479
  
--- Diff: template/cordova/lib/package.js ---
@@ -215,13 +215,20 @@ module.exports.deployToDesktop = function (package, 
deployTarget) {
 
 return utils.getAppStoreUtils().then(function(appStoreUtils) {
 return getPackageName(path.join(__dirname, '..', 
'..')).then(function(pkgname) {
+
+var oldArch;
 // uninstalls previous application instance (if exists)
 console.log('Attempt to uninstall previous application 
version...');
 return spawn('powershell', ['-ExecutionPolicy', 
'RemoteSigned', 'Import-Module "' + appStoreUtils + '"; Uninstall-App ' + 
pkgname])
 .then(function() {
 console.log('Attempt to install application...');
+oldArch = process.env.PROCESSOR_ARCHITECTURE;
+if (package.arch === 'x64') {
+process.env.PROCESSOR_ARCHITECTURE = 'AMD64';
+}
 return spawn('powershell', ['-ExecutionPolicy', 
'RemoteSigned', 'Import-Module "' + appStoreUtils + '"; Install-App', 
utils.quote(package.script)]);
--- End diff --

Addressed by update.  Thx.


> Windows 10: x64-build fails to run when running on an x86 version of Node.js
> 
>
> Key: CB-9499
> URL: https://issues.apache.org/jira/browse/CB-9499
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: mobile-spec, Windows
>Reporter: Rob Paveza
>Assignee: Rob Paveza
>Priority: Critical
>
> When running an x64 version of a Cordova app, if the Node.js process is 
> 32-bit, it will spawn 32-bit shells (like cmd.exe or PowerShell).  In such a 
> case, installing a 64-bit app with 64-bit dependencies will fail because of a 
> bug in the VS-packaged installation script, which doesn't check for package 
> architecture, but rather the system's processor architecture, which in a 
> 32-bit shell is reported as x86.
> This is particularly important because Mobilespec uses .NET components.  On 
> Windows 10, these components must be .NET Native compiled, which means that 
> they must be platform-specific compiled.  As a result, when running with 
> cordova run windows -- --archs=x64 --appx=uap
> Mobilespec will build but fail to be run, reporting missing dependencies in 
> the graph.



--
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-9445) executeScript callbacks not working for iOS

[jcesarmobile (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-9445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700303#comment-14700303
 ] 

jcesarmobile commented on CB-9445:
--

I can reproduce with your code, will take a look



> executeScript callbacks not working for iOS
> ---
>
> Key: CB-9445
> URL: https://issues.apache.org/jira/browse/CB-9445
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: iOS, Plugin InAppBrowser
>Affects Versions: 5.1.1
> Environment: Cordova 5.1.1 (CLI), ios 3.8.0, android 4.0.2, 
> cordova-plugin-inappbrowser 1.0.1 (NPM)
>Reporter: Scott Seitz
>Assignee: jcesarmobile
>
> Can someone please check to see if they are encountering the same problem I 
> am in the environment I've listed? (latest released builds of everything I 
> think)
> I open an inappbrowser window and then run an executeScript command using 
> "code:" (not "file:").  Everything works fine on Android, but on iOS, it 
> simply will NOT fire the callback function after executing the injected code. 
>  Make the "code:" as simple as you like to test it and see if you can get a 
> callback to fire.  I've dumbed it down as much as possible and can't get one 
> to fire.  I know that all instances of code I've injected have run fine in 
> the iab by using the console (against the iab) to check for the variables I 
> was creating in the code.  I can't even get a callback to fire that doesn't 
> expect a parameter to be passed back...
> Many thanks,
> Scott



--
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-9503) Adding a plugin with a caret version fails to resolve

[Tom Vincent (JIRA)]

Tom Vincent created CB-9503:
---

 Summary: Adding a plugin with a caret version fails to resolve
 Key: CB-9503
 URL: https://issues.apache.org/jira/browse/CB-9503
 Project: Apache Cordova
  Issue Type: Bug
  Components: CordovaLib
Affects Versions: 5.2.0
Reporter: Tom Vincent


A regression seems to have been introduced after CB-9147 whereby caret 
versioned plugins cannot be installed even when the resolved version is a valid 
install target.

For example, the latest publish release of cordova-plugin-crosswalk-webview on 
npm is 1.2.0. However, when I {{cordova plugin add 
cordova-plugin-crosswalk-webview@\^1.2.0}}, it fails with "No compatible 
version found". The same thing succeeds with a tilde, or by reverting to 
cordova-lib 5.1.1.

Fuller example:

{code}
❯ ../../../node_modules/.bin/cordova -v
5.2.0

❯ ../../../node_modules/.bin/cordova plugin add 
cordova-plugin-crosswalk-webview@\^1.2.0
Fetching plugin "cordova-plugin-crosswalk-webview@^1.2.0" via npm
Failed to fetch plugin cordova-plugin-crosswalk-webview@^1.2.0 via registry.
Probably this is either a connection problem, or plugin spec is incorrect.
Check your connection and plugin name/version/URL.
Error: No compatible version found: cordova-plugin-crosswalk-webview@'">=1.2.0 
<2.0.0"'
Valid install targets:
["1.0.0","1.1.0","1.2.0"]

❯ npm i cordova@5.1.1

❯ ../../../node_modules/.bin/cordova -v
5.1.1

❯ ../../../node_modules/.bin/cordova plugin add 
cordova-plugin-crosswalk-webview@\^1.2.0
Fetching plugin "cordova-plugin-crosswalk-webview@^1.2.0" via npm
npm http GET https://registry.npmjs.org/cordova-plugin-crosswalk-webview
npm http 304 https://registry.npmjs.org/cordova-plugin-crosswalk-webview
Installing "cordova-plugin-crosswalk-webview" for android
{code}



--
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-9503) Adding a plugin with a caret version fails to resolve

[Tom Vincent (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CB-9503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tom Vincent updated CB-9503:

Description: 
A regression seems to have been introduced after CB-9147 whereby caret 
versioned plugins cannot be installed even when the resolved version is a valid 
install target.

For example, the latest published release of cordova-plugin-crosswalk-webview 
on npm is 1.2.0. However, when I {{cordova plugin add 
cordova-plugin-crosswalk-webview@\^1.2.0}}, it fails with "No compatible 
version found". The same thing succeeds with a tilde, or by reverting to 
cordova-lib 5.1.1.

Fuller example:

{code}
❯ ../../../node_modules/.bin/cordova -v
5.2.0

❯ ../../../node_modules/.bin/cordova plugin add 
cordova-plugin-crosswalk-webview@\^1.2.0
Fetching plugin "cordova-plugin-crosswalk-webview@^1.2.0" via npm
Failed to fetch plugin cordova-plugin-crosswalk-webview@^1.2.0 via registry.
Probably this is either a connection problem, or plugin spec is incorrect.
Check your connection and plugin name/version/URL.
Error: No compatible version found: cordova-plugin-crosswalk-webview@'">=1.2.0 
<2.0.0"'
Valid install targets:
["1.0.0","1.1.0","1.2.0"]

❯ npm i cordova@5.1.1

❯ ../../../node_modules/.bin/cordova -v
5.1.1

❯ ../../../node_modules/.bin/cordova plugin add 
cordova-plugin-crosswalk-webview@\^1.2.0
Fetching plugin "cordova-plugin-crosswalk-webview@^1.2.0" via npm
npm http GET https://registry.npmjs.org/cordova-plugin-crosswalk-webview
npm http 304 https://registry.npmjs.org/cordova-plugin-crosswalk-webview
Installing "cordova-plugin-crosswalk-webview" for android
{code}

  was:
A regression seems to have been introduced after CB-9147 whereby caret 
versioned plugins cannot be installed even when the resolved version is a valid 
install target.

For example, the latest publish release of cordova-plugin-crosswalk-webview on 
npm is 1.2.0. However, when I {{cordova plugin add 
cordova-plugin-crosswalk-webview@\^1.2.0}}, it fails with "No compatible 
version found". The same thing succeeds with a tilde, or by reverting to 
cordova-lib 5.1.1.

Fuller example:

{code}
❯ ../../../node_modules/.bin/cordova -v
5.2.0

❯ ../../../node_modules/.bin/cordova plugin add 
cordova-plugin-crosswalk-webview@\^1.2.0
Fetching plugin "cordova-plugin-crosswalk-webview@^1.2.0" via npm
Failed to fetch plugin cordova-plugin-crosswalk-webview@^1.2.0 via registry.
Probably this is either a connection problem, or plugin spec is incorrect.
Check your connection and plugin name/version/URL.
Error: No compatible version found: cordova-plugin-crosswalk-webview@'">=1.2.0 
<2.0.0"'
Valid install targets:
["1.0.0","1.1.0","1.2.0"]

❯ npm i cordova@5.1.1

❯ ../../../node_modules/.bin/cordova -v
5.1.1

❯ ../../../node_modules/.bin/cordova plugin add 
cordova-plugin-crosswalk-webview@\^1.2.0
Fetching plugin "cordova-plugin-crosswalk-webview@^1.2.0" via npm
npm http GET https://registry.npmjs.org/cordova-plugin-crosswalk-webview
npm http 304 https://registry.npmjs.org/cordova-plugin-crosswalk-webview
Installing "cordova-plugin-crosswalk-webview" for android
{code}


> Adding a plugin with a caret version fails to resolve
> -
>
> Key: CB-9503
> URL: https://issues.apache.org/jira/browse/CB-9503
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: CordovaLib
>Affects Versions: 5.2.0
>Reporter: Tom Vincent
>
> A regression seems to have been introduced after CB-9147 whereby caret 
> versioned plugins cannot be installed even when the resolved version is a 
> valid install target.
> For example, the latest published release of cordova-plugin-crosswalk-webview 
> on npm is 1.2.0. However, when I {{cordova plugin add 
> cordova-plugin-crosswalk-webview@\^1.2.0}}, it fails with "No compatible 
> version found". The same thing succeeds with a tilde, or by reverting to 
> cordova-lib 5.1.1.
> Fuller example:
> {code}
> ❯ ../../../node_modules/.bin/cordova -v
> 5.2.0
> ❯ ../../../node_modules/.bin/cordova plugin add 
> cordova-plugin-crosswalk-webview@\^1.2.0
> Fetching plugin "cordova-plugin-crosswalk-webview@^1.2.0" via npm
> Failed to fetch plugin cordova-plugin-crosswalk-webview@^1.2.0 via registry.
> Probably this is either a connection problem, or plugin spec is incorrect.
> Check your connection and plugin name/version/URL.
> Error: No compatible version found: 
> cordova-plugin-crosswalk-webview@'">=1.2.0 <2.0.0"'
> Valid install targets:
> ["1.0.0","1.1.0","1.2.0"]
> ❯ npm i cordova@5.1.1
> ❯ ../../../node_modules/.bin/cordova -v
> 5.1.1
> ❯ ../../../node_modules/.bin/cordova plugin add 
> cordova-plugin-crosswalk-webview@\^1.2.0
> Fetching plugin "cordova-plugin-crosswalk-webview@^1.2.0" via npm
> npm http GET https://registry.npmjs.org/cordova-plugin-crosswalk-webview
> npm http 304 https://registry.npmjs.org/cordova-plugin-crosswa

[jira] [Commented] (CB-8875) Splash screen no longer fades when FadeSplashScreen=true

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-8875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700152#comment-14700152
 ] 

ASF GitHub Bot commented on CB-8875:


Github user idpaterson commented on the pull request:


https://github.com/apache/cordova-plugin-splashscreen/pull/44#issuecomment-131947531
  
Should the `createViews` and `destroyViews` calls (the entire if/else 
structure) be dispatched to the main thread as well? It seems that calling 
those off of the main thread could lead to unexpected behavior since they 
interact with views.


> Splash screen no longer fades when FadeSplashScreen=true
> 
>
> Key: CB-8875
> URL: https://issues.apache.org/jira/browse/CB-8875
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Plugin SplashScreen
>Reporter: Chris Karcher
>
> After upgrading to the latest version of the plugin with the fix for 
> [CB-8836], the splash screen in my iOS app no longer fades even though 
> FadeSplashScreen=true.
> This is the commit that addresses CB-8836:
> [https://github.com/apache/cordova-plugin-splashscreen/commit/559b300d29ba6eb2f951eb19b9bbf7ba9238a862]
> I've found that wrapping the entire call to [UIView transitionWithView] with 
> a dispatch_async (rather than the individual animation and completion blocks) 
> fixes 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] [Commented] (CB-8836) Crashes after animating splashscreen

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-8836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700147#comment-14700147
 ] 

ASF GitHub Bot commented on CB-8836:


Github user idpaterson commented on the pull request:


https://github.com/apache/cordova-plugin-splashscreen/pull/56#issuecomment-131946308
  
The `dispatch_async` calls were added 
[here](https://github.com/apache/cordova-plugin-splashscreen/commit/559b300d29ba6eb2f951eb19b9bbf7ba9238a862)
 and reports on the commit of fading no longer working were disregarded. 
Further discussion on [the original 
issue](https://issues.apache.org/jira/browse/CB-8836) noted that the 
`dispatch_async` calls did not fully resolve whatever crash was being 
experienced.

Certainly removing these calls outright is not a complete solution since it 
disregards the earlier problem of crashes due to operating off the main thread, 
but this pull request thus far identifies that changes in the animation block 
must be synchronous in order to actually animate.

The related issue in Jira for fading no longer working on iOS is 
[CB-8875](https://issues.apache.org/jira/browse/CB-8875) for which there is an 
outstanding pull request #44 by @chrskrchr. This is a better but possibly not a 
complete solution either since the calls to `destroyViews` and `createViews` 
should probably also only be called on the main thread. 


> Crashes after animating splashscreen
> 
>
> Key: CB-8836
> URL: https://issues.apache.org/jira/browse/CB-8836
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Plugin SplashScreen
> Environment: iOS
>Reporter: Shazron Abdullah
>Assignee: Shazron Abdullah
> Attachments: CRASH LOG 1, CRASH LOG 2
>
>
> Discussion in https://github.com/apache/cordova-plugin-splashscreen/pull/21
> Fix here: 
> https://gist.github.com/shazron/e45705f76bef4448139a/e6e1820943197e48fd6baf44b765ebdea0252b04
> Affected lines:
> https://github.com/apache/cordova-plugin-splashscreen/blob/35272415d3b75440b1ea5fe9a5baab5e1586b3c1/src/ios/CDVSplashScreen.m#L292-L304
> Crash causes:
> 1. retain cycle problem on self in the block
> 2. performing UIKit operations while not in the main thread.



--
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-9499) Windows 10: x64-build fails to run when running on an x86 version of Node.js

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-9499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700139#comment-14700139
 ] 

ASF GitHub Bot commented on CB-9499:


Github user muratsu commented on a diff in the pull request:

https://github.com/apache/cordova-windows/pull/116#discussion_r37230334
  
--- Diff: template/cordova/lib/package.js ---
@@ -215,13 +215,20 @@ module.exports.deployToDesktop = function (package, 
deployTarget) {
 
 return utils.getAppStoreUtils().then(function(appStoreUtils) {
 return getPackageName(path.join(__dirname, '..', 
'..')).then(function(pkgname) {
+
+var oldArch;
 // uninstalls previous application instance (if exists)
 console.log('Attempt to uninstall previous application 
version...');
 return spawn('powershell', ['-ExecutionPolicy', 
'RemoteSigned', 'Import-Module "' + appStoreUtils + '"; Uninstall-App ' + 
pkgname])
 .then(function() {
 console.log('Attempt to install application...');
+oldArch = process.env.PROCESSOR_ARCHITECTURE;
+if (package.arch === 'x64') {
+process.env.PROCESSOR_ARCHITECTURE = 'AMD64';
+}
 return spawn('powershell', ['-ExecutionPolicy', 
'RemoteSigned', 'Import-Module "' + appStoreUtils + '"; Install-App', 
utils.quote(package.script)]);
--- End diff --

If we throw here the PROCESSOR_ARCHITECTURE will remain changed. While this 
currently has no side effects, we probably want to have a catch promise and set 
the PROCESSOR_ARCHITECTURE to the original value since it's a shared value. 
LGTM otherwise.


> Windows 10: x64-build fails to run when running on an x86 version of Node.js
> 
>
> Key: CB-9499
> URL: https://issues.apache.org/jira/browse/CB-9499
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: mobile-spec, Windows
>Reporter: Rob Paveza
>Assignee: Rob Paveza
>Priority: Critical
>
> When running an x64 version of a Cordova app, if the Node.js process is 
> 32-bit, it will spawn 32-bit shells (like cmd.exe or PowerShell).  In such a 
> case, installing a 64-bit app with 64-bit dependencies will fail because of a 
> bug in the VS-packaged installation script, which doesn't check for package 
> architecture, but rather the system's processor architecture, which in a 
> 32-bit shell is reported as x86.
> This is particularly important because Mobilespec uses .NET components.  On 
> Windows 10, these components must be .NET Native compiled, which means that 
> they must be platform-specific compiled.  As a result, when running with 
> cordova run windows -- --archs=x64 --appx=uap
> Mobilespec will build but fail to be run, reporting missing dependencies in 
> the graph.



--
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-9502) Amazon Fireos - InAppBrowser plugin fails to compile

[Alex Belch (JIRA)]

Alex Belch created CB-9502:
--

 Summary: Amazon Fireos - InAppBrowser plugin fails to compile
 Key: CB-9502
 URL: https://issues.apache.org/jira/browse/CB-9502
 Project: Apache Cordova
  Issue Type: Bug
  Components: Amazon FireOS
Affects Versions: 3.5.0
 Environment: Unix Mac
cordova-plugin-inappbrowser 1.0.1 "InAppBrowser"
cordova version 5.2.0
Reporter: Alex Belch
Assignee: Archana Naik
 Fix For: Master


Issue for cordova-plugin-inappbrowser on the amazon-vireos platform,
plug in compilation fails due to missing methods in the Amazon 

Type: 
cordova plugin add cordova-plugin-inappbrowser
cordova build amazon-fireos

Output is:
 [javac] Compiling 26 source files to 
/Users/alex/Scrumster/Projects/Scrum/platforms/amazon-fireos/ant-build/classes
[javac] warning: [options] source value 1.5 is obsolete and will be removed 
in a future release
[javac] warning: [options] target value 1.5 is obsolete and will be removed 
in a future release
[javac] warning: [options] To suppress warnings about obsolete options, use 
-Xlint:-options.
[javac] 
/Users/alex/Scrumster/Projects/Scrum/platforms/amazon-fireos/src/org/apache/cordova/inappbrowser/InAppBrowserDialog.java:51:
 error: cannot find symbol
[javac] if (this.inAppBrowser.hardwareBack() && 
this.inAppBrowser.canGoBack()) {
[javac]  ^
[javac]   symbol:   method hardwareBack()
[javac]   location: variable inAppBrowser of type InAppBrowser
[javac] 
/Users/alex/Scrumster/Projects/Scrum/platforms/amazon-fireos/src/org/apache/cordova/inappbrowser/InAppBrowserDialog.java:51:
 error: cannot find symbol
[javac] if (this.inAppBrowser.hardwareBack() && 
this.inAppBrowser.canGoBack()) {
[javac] 
 ^
[javac]   symbol:   method canGoBack()
[javac]   location: variable inAppBrowser of type InAppBrowser
[javac] 
/Users/alex/Scrumster/Projects/Scrum/platforms/amazon-fireos/src/org/apache/cordova/inappbrowser/InAppBrowserDialog.java:52:
 error: goBack() has private access in InAppBrowser
[javac] this.inAppBrowser.goBack();
[javac]  ^
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] 3 errors
[javac] 3 warnings

The reason is that the InAppBrowser.java class is missing methods: 
hardwareBack(), canGoBack() and goBack()
presumably these can be added as dummy methods or for goBack() method made 
public.




--
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-9501) Amazon Fireos - plugins for File add fails

[Alex Belch (JIRA)]

Alex Belch created CB-9501:
--

 Summary: Amazon Fireos - plugins for File add fails
 Key: CB-9501
 URL: https://issues.apache.org/jira/browse/CB-9501
 Project: Apache Cordova
  Issue Type: Bug
  Components: Amazon FireOS
Affects Versions: 5.2.0
 Environment: cordova version 5.2.0
cordova-plugin-file 2.1.0 "File"
Reporter: Alex Belch
Assignee: Archana Naik
 Fix For: Master


Issue around adding the cordova-plugin-file for amazon-fireos platform
on plugin version 2.1.0 of File

Type: cordova plugin add cordova-plugin-file

Output observed is: 
Failed to install 'cordova-plugin-file':Error: Uh oh!
"/Users/alex/Scrumster/Projects/Scrum/plugins/cordova-plugin-file/src/android/FileHelper.java"
 not found!
at Object.module.exports.common.copyFile 
(/usr/local/lib/node_modules/cordova/node_modules/cordova-lib/src/plugman/platforms/common.js:38:40)
at Object.module.exports.common.copyNewFile 
(/usr/local/lib/node_modules/cordova/node_modules/cordova-lib/src/plugman/platforms/common.js:69:16)
at Object.module.exports.source-file.install 
(/usr/local/lib/node_modules/cordova/node_modules/cordova-lib/src/plugman/platforms/amazon-fireos.js:57:20)
at installWrapper 
(/usr/local/lib/node_modules/cordova/node_modules/cordova-lib/src/platforms/platforms.js:77:32)
at Object.ActionStack.process 
(/usr/local/lib/node_modules/cordova/node_modules/cordova-lib/src/plugman/util/action-stack.js:68:25)
at handleInstall 
(/usr/local/lib/node_modules/cordova/node_modules/cordova-lib/src/plugman/install.js:576:20)
at 
/usr/local/lib/node_modules/cordova/node_modules/cordova-lib/src/plugman/install.js:363:28
at _fulfilled 
(/usr/local/lib/node_modules/cordova/node_modules/q/q.js:787:54)
at self.promiseDispatch.done 
(/usr/local/lib/node_modules/cordova/node_modules/q/q.js:816:30)
at Promise.promise.promiseDispatch 
(/usr/local/lib/node_modules/cordova/node_modules/q/q.js:749:13)
Error: Uh oh!
"/Users/alex/Scrumster/Projects/Scrum/plugins/cordova-plugin-file/src/android/FileHelper.java"
 not found!
at Object.module.exports.common.copyFile 
(/usr/local/lib/node_modules/cordova/node_modules/cordova-lib/src/plugman/platforms/common.js:38:40)
at Object.module.exports.common.copyNewFile 
(/usr/local/lib/node_modules/cordova/node_modules/cordova-lib/src/plugman/platforms/common.js:69:16)
at Object.module.exports.source-file.install 
(/usr/local/lib/node_modules/cordova/node_modules/cordova-lib/src/plugman/platforms/amazon-fireos.js:57:20)
at installWrapper 
(/usr/local/lib/node_modules/cordova/node_modules/cordova-lib/src/platforms/platforms.js:77:32)
at Object.ActionStack.process 
(/usr/local/lib/node_modules/cordova/node_modules/cordova-lib/src/plugman/util/action-stack.js:68:25)
at handleInstall 
(/usr/local/lib/node_modules/cordova/node_modules/cordova-lib/src/plugman/install.js:576:20)
at 
/usr/local/lib/node_modules/cordova/node_modules/cordova-lib/src/plugman/install.js:363:28
at _fulfilled 
(/usr/local/lib/node_modules/cordova/node_modules/q/q.js:787:54)
at self.promiseDispatch.done 
(/usr/local/lib/node_modules/cordova/node_modules/q/q.js:816:30)
at Promise.promise.promiseDispatch 
(/usr/local/lib/node_modules/cordova/node_modules/q/q.js:749:13)

The plugin-xml is incorrect for the amazon-vireos section
it should list the same java files as the android version.



--
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-5753) iOS: CDVLocation locationManager didFailWithError

[Adam Back (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-5753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700074#comment-14700074
 ] 

Adam Back commented on CB-5753:
---

Thanks for the PR [~fsmichaelgo].

Community, any chance of getting this merged?

> iOS: CDVLocation locationManager didFailWithError
> -
>
> Key: CB-5753
> URL: https://issues.apache.org/jira/browse/CB-5753
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Plugin Geolocation
>Affects Versions: 2.9.0, 2.9.1
> Environment: iOS
>Reporter: Martin Robin
>Assignee: Shazron Abdullah
>  Labels: patch
>
> The delegate handler for didFailWithError appears to have a couple of 
> issues...
> According to the 
> [documentation|https://developer.apple.com/library/ios/documentation/CoreLocation/Reference/CLLocationManagerDelegate_Protocol/CLLocationManagerDelegate/CLLocationManagerDelegate.html#//apple_ref/occ/intfm/CLLocationManagerDelegate/locationManager:didFailWithError:],
>  {quote}If the location service is unable to retrieve a location right away, 
> it reports a kCLErrorLocationUnknown error and keeps trying. In such a 
> situation, you can simply ignore the error and wait for a new event.{quote}
> The handler within CDVLocation does not however take this into account and as 
> a result if this error is raised it causes the location manager to be shut 
> down without any warning.
> Within the same handler, there appears to be code to send a notification back 
> to the JavaScript by way of the onError function. This notification is never 
> received in the JavaScript so the error cannot be handled (by calling 
> clearWatch and then restarting with a call to watchPosition for example).
> The first problem is (I believe) fairly easily resolved; simply ignoring the 
> error (though possibly notifying the JavaScript) would suffice.
> I have no idea how to resolve the second problem. I have tried tracing the 
> code and it appears to call commandDelegate::sendPluginResult (via 
> returnLocationError) but the onError function in the (my) JavaScript does not 
> receive the error. I do not understand how the plug-in model works enough to 
> be able to follow up any further for myself.



--
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-8936) Surface platform-specific logs in buildbot

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-8936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700066#comment-14700066
 ] 

ASF GitHub Bot commented on CB-8936:


Github user nikhilkh commented on the pull request:

https://github.com/apache/cordova-medic/pull/59#issuecomment-131933828
  
How will this work - since mobilespec launch does not run with admin 
permissions? Do you expect enabling the log be a one-time machine setup process?


> Surface platform-specific logs in buildbot
> --
>
> Key: CB-8936
> URL: https://issues.apache.org/jira/browse/CB-8936
> Project: Apache Cordova
>  Issue Type: Task
>  Components: Medic
>Reporter: Alexander Sorokin
>Assignee: Alexander Sorokin
>
> Platform specific logs (e.g. logcat for android, stderr.log and stdin.log for 
> iOS etc.) should be gathered and displayed in buildbot.



--
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-8936) Surface platform-specific logs in buildbot

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-8936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700061#comment-14700061
 ] 

ASF GitHub Bot commented on CB-8936:


Github user nikhilkh commented on a diff in the pull request:

https://github.com/apache/cordova-medic/pull/59#discussion_r37225154
  
--- Diff: medic/medic-run.js ---
@@ -238,6 +241,16 @@ function windowsSpecificPreparation(argv) {
 );
 }
 
+// start logging
+var logScriptPath = path.join(platformPath, 'cordova', 'log');
+if (fs.existsSync(logScriptPath)) {
+logProcess = cp.fork(logScriptPath, [], { silent: true });
+
+logProcess.stdout.on('data', function (data) {
--- End diff --

Should we listen for error and log a message with the error?


> Surface platform-specific logs in buildbot
> --
>
> Key: CB-8936
> URL: https://issues.apache.org/jira/browse/CB-8936
> Project: Apache Cordova
>  Issue Type: Task
>  Components: Medic
>Reporter: Alexander Sorokin
>Assignee: Alexander Sorokin
>
> Platform specific logs (e.g. logcat for android, stderr.log and stdin.log for 
> iOS etc.) should be gathered and displayed in buildbot.



--
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-8936) Surface platform-specific logs in buildbot

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-8936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700062#comment-14700062
 ] 

ASF GitHub Bot commented on CB-8936:


Github user nikhilkh commented on a diff in the pull request:

https://github.com/apache/cordova-medic/pull/59#discussion_r37225188
  
--- Diff: medic/medic-run.js ---
@@ -238,6 +241,16 @@ function windowsSpecificPreparation(argv) {
 );
 }
 
+// start logging
+var logScriptPath = path.join(platformPath, 'cordova', 'log');
+if (fs.existsSync(logScriptPath)) {
+logProcess = cp.fork(logScriptPath, [], { silent: true });
--- End diff --

Probably good to create a medic log message 'Starting log..."


> Surface platform-specific logs in buildbot
> --
>
> Key: CB-8936
> URL: https://issues.apache.org/jira/browse/CB-8936
> Project: Apache Cordova
>  Issue Type: Task
>  Components: Medic
>Reporter: Alexander Sorokin
>Assignee: Alexander Sorokin
>
> Platform specific logs (e.g. logcat for android, stderr.log and stdin.log for 
> iOS etc.) should be gathered and displayed in buildbot.



--
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-9500) [CB-8485] Not allowed to have XCodeProject display name different from Cordova project name

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700057#comment-14700057
 ] 

ASF GitHub Bot commented on CB-9500:


GitHub user njtman opened a pull request:

https://github.com/apache/cordova-ios/pull/152

CB-9500 Added no sign argument to iOS build

As of Cordova iOS 3.9.0, Xcode signing is automatically added to the build
step when compiling for device.  An argument has been added to skip
the signing step (xcrun command) when building for an iOS device. 

Simply supply:

--noSign

argument when running the compile / build command to skip iOS app signing.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/njtman/cordova-ios 
CB-9500-iOS-Build-No-Sign-Arg

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-ios/pull/152.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #152


commit 5bfb1eefc15a81096ae9106f87c893716d1f9cd0
Author: Jon Tancer 
Date:   2015-08-17T19:08:31Z

CB-9500 Added no sign argument to iOS build

As of Cordova iOS 3.9.0, Xcode signing is automatically added to build
step when compiling for device.  An argument has been added to skip
this step of signing when building for an iOS device.  Simply supply
the —noSign argument when running the compile / build command.




> [CB-8485] Not allowed to have XCodeProject display name different from 
> Cordova project name
> ---
>
> Key: CB-9500
> URL: https://issues.apache.org/jira/browse/CB-9500
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: iOS
>Affects Versions: 5.2.0
> Environment: Mac OS X
>Reporter: Nicholas Farley
>Priority: Minor
>  Labels: compile, compile-error, compilerconfiguration, 
> conversion, error, ios, name, xcode
> Fix For: 5.2.0
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> The recent changes to the compile command (CB-8485) have introduced an issue 
> on iOS. Specifically, the inline creation of the signed archive, have made it 
> impossible to have an iOS applications display name be different from the 
> Cordova project name. 
> The archive generation process expects the .app name to have the same 
> basename as the name listed in the XCodeProject. If it does not find the .app 
> at this position, it fails the conversion and the entire compile process. 
> The .app it creates is based upon the Cordova project name. The name in the 
> XCodeProject is the name used for applications name when it is on a device, 
> so now this name must match the project name or the signed archive won't be 
> created.
> This can be fixed in a number of ways. 
>  - Include a "no-sign" option, which would mimic the old behavior.
>  - Include a way to pass the desired name to compile.
>  - Have the .app name be pulled from some other configuration that isn't tied 
> to a the iOS display name. 



--
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-8054) Camera getPicture photo library not supported on Windows?

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-8054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700056#comment-14700056
 ] 

ASF GitHub Bot commented on CB-8054:


Github user purplecabbage commented on the pull request:


https://github.com/apache/cordova-plugin-camera/pull/86#issuecomment-131932455
  
I don't see anything at the url you posted.



My team is hiring!
@purplecabbage
risingj.com

On Mon, Aug 17, 2015 at 10:23 AM, ekambarrao 
wrote:

> @purplecabbage  this is like light in
> darkyour offer itself is like a great savior to me:-)
>
> I have uploaded the solutions @ the following onedrive
>
>
> 
https://onedrive.live.com/?id=463D607901FE1563%21114&cid=463D607901FE1563&group=0
>
> blankcordovaapp1 is failing where I experimented.
>
> javascript(2) has been working fine.
>
> they were in VS 2013 and it is picking up cordova 3.7.1
>
> I have moved the code to VS 2015 and I selected 5.1.1 s platform but it is
> showing 4.0 folder in .cordova folder.
>
> 2015 working as long as the device in debug when disconnected again the
> same.
>
> —
> Reply to this email directly or view it on GitHub
> 

> .
>



> Camera getPicture photo library not supported on Windows?
> -
>
> Key: CB-8054
> URL: https://issues.apache.org/jira/browse/CB-8054
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Plugin Camera, Windows
>Affects Versions: 3.7.1
> Environment: Windows Phone 8.1
> Lumia 635
> Windows universal app platform
> Camera plugin v0.3.3
>Reporter: Boston Dell-Vandenberg
>Assignee: Murat Sutunc
>
> On the Windows platform when calling getPicture() with "sourceType" of 
> "PHOTOLIBRARY" or "SAVEDPHOTOALBUM" it returns "Not supported" error. 
> The plugin documentation says Windows is supported but is that not the case?



--
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-8936) Surface platform-specific logs in buildbot

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-8936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700054#comment-14700054
 ] 

ASF GitHub Bot commented on CB-8936:


Github user asfgit closed the pull request at:

https://github.com/apache/cordova-windows/pull/115


> Surface platform-specific logs in buildbot
> --
>
> Key: CB-8936
> URL: https://issues.apache.org/jira/browse/CB-8936
> Project: Apache Cordova
>  Issue Type: Task
>  Components: Medic
>Reporter: Alexander Sorokin
>Assignee: Alexander Sorokin
>
> Platform specific logs (e.g. logcat for android, stderr.log and stdin.log for 
> iOS etc.) should be gathered and displayed in buildbot.



--
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-8936) Surface platform-specific logs in buildbot

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-8936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700053#comment-14700053
 ] 

ASF subversion and git services commented on CB-8936:
-

Commit 1b415a69607c18469c3091c907754d1c11364636 in cordova-windows's branch 
refs/heads/master from [~alsorokin]
[ https://git-wip-us.apache.org/repos/asf?p=cordova-windows.git;h=1b415a6 ]

CB-8936 Logs: Stability and formatting improvements


> Surface platform-specific logs in buildbot
> --
>
> Key: CB-8936
> URL: https://issues.apache.org/jira/browse/CB-8936
> Project: Apache Cordova
>  Issue Type: Task
>  Components: Medic
>Reporter: Alexander Sorokin
>Assignee: Alexander Sorokin
>
> Platform specific logs (e.g. logcat for android, stderr.log and stdin.log for 
> iOS etc.) should be gathered and displayed in buildbot.



--
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-8936) Surface platform-specific logs in buildbot

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-8936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700037#comment-14700037
 ] 

ASF GitHub Bot commented on CB-8936:


Github user nikhilkh commented on the pull request:

https://github.com/apache/cordova-windows/pull/115#issuecomment-131930329
  
LGTM


> Surface platform-specific logs in buildbot
> --
>
> Key: CB-8936
> URL: https://issues.apache.org/jira/browse/CB-8936
> Project: Apache Cordova
>  Issue Type: Task
>  Components: Medic
>Reporter: Alexander Sorokin
>Assignee: Alexander Sorokin
>
> Platform specific logs (e.g. logcat for android, stderr.log and stdin.log for 
> iOS etc.) should be gathered and displayed in buildbot.



--
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-9500) [CB-8485] Not allowed to have XCodeProject display name different from Cordova project name

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1478#comment-1478
 ] 

ASF GitHub Bot commented on CB-9500:


Github user njtman commented on the pull request:

https://github.com/apache/cordova-ios/pull/151#issuecomment-131923188
  
Sorry, I messed up this pull request.  I will be opening up another shortly.


> [CB-8485] Not allowed to have XCodeProject display name different from 
> Cordova project name
> ---
>
> Key: CB-9500
> URL: https://issues.apache.org/jira/browse/CB-9500
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: iOS
>Affects Versions: 5.2.0
> Environment: Mac OS X
>Reporter: Nicholas Farley
>Priority: Minor
>  Labels: compile, compile-error, compilerconfiguration, 
> conversion, error, ios, name, xcode
> Fix For: 5.2.0
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> The recent changes to the compile command (CB-8485) have introduced an issue 
> on iOS. Specifically, the inline creation of the signed archive, have made it 
> impossible to have an iOS applications display name be different from the 
> Cordova project name. 
> The archive generation process expects the .app name to have the same 
> basename as the name listed in the XCodeProject. If it does not find the .app 
> at this position, it fails the conversion and the entire compile process. 
> The .app it creates is based upon the Cordova project name. The name in the 
> XCodeProject is the name used for applications name when it is on a device, 
> so now this name must match the project name or the signed archive won't be 
> created.
> This can be fixed in a number of ways. 
>  - Include a "no-sign" option, which would mimic the old behavior.
>  - Include a way to pass the desired name to compile.
>  - Have the .app name be pulled from some other configuration that isn't tied 
> to a the iOS display name. 



--
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-9500) [CB-8485] Not allowed to have XCodeProject display name different from Cordova project name

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1479#comment-1479
 ] 

ASF GitHub Bot commented on CB-9500:


Github user njtman closed the pull request at:

https://github.com/apache/cordova-ios/pull/151


> [CB-8485] Not allowed to have XCodeProject display name different from 
> Cordova project name
> ---
>
> Key: CB-9500
> URL: https://issues.apache.org/jira/browse/CB-9500
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: iOS
>Affects Versions: 5.2.0
> Environment: Mac OS X
>Reporter: Nicholas Farley
>Priority: Minor
>  Labels: compile, compile-error, compilerconfiguration, 
> conversion, error, ios, name, xcode
> Fix For: 5.2.0
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> The recent changes to the compile command (CB-8485) have introduced an issue 
> on iOS. Specifically, the inline creation of the signed archive, have made it 
> impossible to have an iOS applications display name be different from the 
> Cordova project name. 
> The archive generation process expects the .app name to have the same 
> basename as the name listed in the XCodeProject. If it does not find the .app 
> at this position, it fails the conversion and the entire compile process. 
> The .app it creates is based upon the Cordova project name. The name in the 
> XCodeProject is the name used for applications name when it is on a device, 
> so now this name must match the project name or the signed archive won't be 
> created.
> This can be fixed in a number of ways. 
>  - Include a "no-sign" option, which would mimic the old behavior.
>  - Include a way to pass the desired name to compile.
>  - Have the .app name be pulled from some other configuration that isn't tied 
> to a the iOS display name. 



--
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-9500) [CB-8485] Not allowed to have XCodeProject display name different from Cordova project name

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1474#comment-1474
 ] 

ASF GitHub Bot commented on CB-9500:


GitHub user njtman opened a pull request:

https://github.com/apache/cordova-ios/pull/151

CB-9500 iOS build no sign arg

As of Cordova iOS 3.9.0, Xcode signing is automatically added to the build 
step when compiling for device.  There are use cases where we would not want 
this to automatically happen (see CB-9500).  An argument has been added to skip 
the code signing when building for an iOS device.  Simply supply the   

--noSign

argument when running the compile / build command for iOS to skip code 
signing.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/njtman/cordova-ios 
CB-9500-iOS-Build-No-Sign-Arg

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-ios/pull/151.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #151


commit aa5d0e937ac68b10aa846d439bb1baba4da12049
Author: Shazron Abdullah 
Date:   2014-07-14T19:03:19Z

WKWebView - squashed commit.

commit da7a3546f809c331cf230af180b3e6f1fb99cb2b
Author: Shazron Abdullah 
Date:   Thu Jul 10 17:48:15 2014 -0700

Support alert/confirm/prompt in WKWebView

commit 63552fd3f2548f407aec1bbfda997809d1f2a89d
Author: Shazron Abdullah 
Date:   Thu Jul 10 14:52:44 2014 -0700

Support config.xml preferences for WKWebView, and style fixups

commit e67e6bf2577c776c887453801af05f973fb90094
Author: Shazron Abdullah 
Date:   Wed Jul 9 18:44:03 2014 -0700

Use weakSelf in block

commit fc83f068388f3402935819f7891906ffa9029cc1
Author: Shazron Abdullah 
Date:   Wed Jul 9 18:38:30 2014 -0700

Support config.xml preferences for WKWebView

commit 4eeaf0c8730a30b8709d0d98aba4b2996e34d9f4
Author: Shazron Abdullah 
Date:   Wed Jul 9 18:27:51 2014 -0700

Break out config.xml preferences for UIWebView (related to WKWebView 
prefs support)

commit 9ba496297116f20a4ea0d7b83a9f142ceec2bc84
Author: Shazron Abdullah 
Date:   Wed Jul 9 17:51:11 2014 -0700

Re-add pragma message for iOS 8

commit 2e17db94a87da80a7d50f202eef40178c0a688c0
Author: Shazron Abdullah 
Date:   Wed Jul 9 17:46:00 2014 -0700

Removed unused WKWebView+Private header

commit 601eea1c8784e1acf00b0a39ca4a3ea5085b2098
Author: Shazron Abdullah 
Date:   Mon Jul 7 15:59:30 2014 -0700

Removed WKWebView+Private category since the functions it covers are 
already now in iOS 8 beta 3

commit 69c86d641c8a14e23843566ff2024ce77238fd79
Author: Shazron Abdullah 
Date:   Mon Jun 23 11:59:51 2014 -0700

Changed @import WebKit back to the old #import (for supporting older 
IPHONE_OS_DEPLOYMENT_TARGET reasons, bug in Xcode), add #pragma message to add 
WebKit.framework for iOS 8

commit c133640d264eba5456b3ffd2d3be83e3fd90bf42
Author: Shazron Abdullah 
Date:   Sat Jun 21 22:14:26 2014 -0700

Removed WebKit.framework from templates.

commit b4832d132e6628a7ae0ef681eab54554ed913b77
Author: Shazron Abdullah 
Date:   Sat Jun 21 21:45:10 2014 -0700

Using @import instead of #import for WebKit, which doesn't require us 
to list the framework in the project explicitly.
This gives us a true Xcode 5 / 6 compile solution. HOWEVER there is a 
bug in Xcode (was there since 5) where if you do an @import for a framework, it 
won't link if your Deployment Target OS version does not also include the 
framework itself, when compiling for the Simulator. For example, if you @import 
WebKit, and build for the Simulator, your Deployment Target MUST be iOS 8.

The workaround is, this bug does not appear if you build for a device. 
To make it work for the Simulator, you will have to explicitly add the 
framework in Build Phases -> Link Binary with Libraries.

commit df3d8391546b2bb6da659ca2102609beb7038f7d
Author: Shazron Abdullah 
Date:   Sat Jun 21 00:20:36 2014 -0700

Unified the implementations to switch to WKWebView when available and 
fall back to UIWebView. The implementation even compiles under Xcode 5.1 -- 
however, the linker will complain under Xcode 5.1 that WebKit.framework is not 
available. Just remove the framework in "Link Binary With Libraries" Build 
Phase and it should run.

commit 52e27adcd4227621d329fea4743be73bfcb7f4bf
Author: Shazron Abdullah 
Date:   Fri Jun 20 16:59:48 2014 -0700

Re-add deprecated CDVPlugin functions

commit e16e914c3ba2f30324f25d

[jira] [Commented] (CB-9499) Windows 10: x64-build fails to run when running on an x86 version of Node.js

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-9499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1471#comment-1471
 ] 

ASF GitHub Bot commented on CB-9499:


Github user purplecabbage commented on the pull request:

https://github.com/apache/cordova-windows/pull/116#issuecomment-131921926
  
lgtm!


> Windows 10: x64-build fails to run when running on an x86 version of Node.js
> 
>
> Key: CB-9499
> URL: https://issues.apache.org/jira/browse/CB-9499
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: mobile-spec, Windows
>Reporter: Rob Paveza
>Assignee: Rob Paveza
>Priority: Critical
>
> When running an x64 version of a Cordova app, if the Node.js process is 
> 32-bit, it will spawn 32-bit shells (like cmd.exe or PowerShell).  In such a 
> case, installing a 64-bit app with 64-bit dependencies will fail because of a 
> bug in the VS-packaged installation script, which doesn't check for package 
> architecture, but rather the system's processor architecture, which in a 
> 32-bit shell is reported as x86.
> This is particularly important because Mobilespec uses .NET components.  On 
> Windows 10, these components must be .NET Native compiled, which means that 
> they must be platform-specific compiled.  As a result, when running with 
> cordova run windows -- --archs=x64 --appx=uap
> Mobilespec will build but fail to be run, reporting missing dependencies in 
> the graph.



--
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-9499) Windows 10: x64-build fails to run when running on an x86 version of Node.js

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-9499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699921#comment-14699921
 ] 

ASF GitHub Bot commented on CB-9499:


GitHub user robpaveza opened a pull request:

https://github.com/apache/cordova-windows/pull/116

CB-9499: There is a run failure when trying to deploy an x64 app when…

… running on an x86 version of Node.  This change addresses the problem by 
modifying the run process by detecting an x64 app package as the primary, and 
setting the environment architecture to x64 before invoking PowerShell.

Also, small build item to point to the correct location of WinJS.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/MSOpenTech/cordova-windows CB-9499

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-windows/pull/116.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #116


commit af880a3629f6e69bae41c671b4fbd1b44b7714ee
Author: Rob Paveza 
Date:   2015-08-17T17:47:11Z

CB-9499: There is a run failure when trying to deploy an x64 app when 
running on an x86 version of Node.  This change addresses the problem by 
modifying the run process by detecting an x64 app package as the primary, and 
setting the environment architecture to x64 before invoking PowerShell.




> Windows 10: x64-build fails to run when running on an x86 version of Node.js
> 
>
> Key: CB-9499
> URL: https://issues.apache.org/jira/browse/CB-9499
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: mobile-spec, Windows
>Reporter: Rob Paveza
>Assignee: Rob Paveza
>Priority: Critical
>
> When running an x64 version of a Cordova app, if the Node.js process is 
> 32-bit, it will spawn 32-bit shells (like cmd.exe or PowerShell).  In such a 
> case, installing a 64-bit app with 64-bit dependencies will fail because of a 
> bug in the VS-packaged installation script, which doesn't check for package 
> architecture, but rather the system's processor architecture, which in a 
> 32-bit shell is reported as x86.
> This is particularly important because Mobilespec uses .NET components.  On 
> Windows 10, these components must be .NET Native compiled, which means that 
> they must be platform-specific compiled.  As a result, when running with 
> cordova run windows -- --archs=x64 --appx=uap
> Mobilespec will build but fail to be run, reporting missing dependencies in 
> the graph.



--
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-9500) [CB-8485] Not allowed to have XCodeProject display name different from Cordova project name

[Nicholas Farley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CB-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nicholas Farley updated CB-9500:

Description: 
The recent changes to the compile command (CB-8485) have introduced an issue on 
iOS. Specifically, the inline creation of the signed archive, have made it 
impossible to have an iOS applications display name be different from the 
Cordova project name. 

The archive generation process expects the .app name to have the same basename 
as the name listed in the XCodeProject. If it does not find the .app at this 
position, it fails the conversion and the entire compile process. 

The .app it creates is based upon the Cordova project name. The name in the 
XCodeProject is the name used for applications name when it is on a device, so 
now this name must match the project name or the signed archive won't be 
created.

This can be fixed in a number of ways. 
 - Include a "no-sign" option, which would mimic the old behavior.
 - Include a way to pass the desired name to compile.
 - Have the .app name be pulled from some other configuration that isn't tied 
to a the iOS display name. 

  was:
The recent changes to the compile command (CB-8485) have introduced an issue on 
iOS. Specifically, the inline app-to-ipa conversion have made it impossible to 
have an iOS applications display name be different from the Cordova project 
name. 

The conversion process expects the .app name to have the same basename as the 
name listed in the XCodeProject. If it does not find the .app at this position, 
it fails the conversion and the entire compile process. 

The .app it creates is based upon the Cordova project name. The name in the 
XCodeProject is the name used for applications name when it is on a device, so 
now this name must match the project name or conversion won't work. 

This can be fixed in a number of ways. 
 - Include a "no-conversion" option, which would mimic the old behavior.
 - Include a way to pass the desired name to compile.
 - Have the .app name be pulled from some other configuration that isn't tied 
to a the iOS display name. 


> [CB-8485] Not allowed to have XCodeProject display name different from 
> Cordova project name
> ---
>
> Key: CB-9500
> URL: https://issues.apache.org/jira/browse/CB-9500
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: iOS
>Affects Versions: 5.2.0
> Environment: Mac OS X
>Reporter: Nicholas Farley
>Priority: Minor
>  Labels: compile, compile-error, compilerconfiguration, 
> conversion, error, ios, name, xcode
> Fix For: 5.2.0
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> The recent changes to the compile command (CB-8485) have introduced an issue 
> on iOS. Specifically, the inline creation of the signed archive, have made it 
> impossible to have an iOS applications display name be different from the 
> Cordova project name. 
> The archive generation process expects the .app name to have the same 
> basename as the name listed in the XCodeProject. If it does not find the .app 
> at this position, it fails the conversion and the entire compile process. 
> The .app it creates is based upon the Cordova project name. The name in the 
> XCodeProject is the name used for applications name when it is on a device, 
> so now this name must match the project name or the signed archive won't be 
> created.
> This can be fixed in a number of ways. 
>  - Include a "no-sign" option, which would mimic the old behavior.
>  - Include a way to pass the desired name to compile.
>  - Have the .app name be pulled from some other configuration that isn't tied 
> to a the iOS display name. 



--
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-9500) [CB-8485] Not allowed to have XCodeProject display name different from Cordova project name

[Nicholas Farley (JIRA)]

Nicholas Farley created CB-9500:
---

 Summary: [CB-8485] Not allowed to have XCodeProject display name 
different from Cordova project name
 Key: CB-9500
 URL: https://issues.apache.org/jira/browse/CB-9500
 Project: Apache Cordova
  Issue Type: Bug
  Components: iOS
Affects Versions: 5.2.0
 Environment: Mac OS X
Reporter: Nicholas Farley
Priority: Minor
 Fix For: 5.2.0


The recent changes to the compile command (CB-8485) have introduced an issue on 
iOS. Specifically, the inline app-to-ipa conversion have made it impossible to 
have an iOS applications display name be different from the Cordova project 
name. 

The conversion process expects the .app name to have the same basename as the 
name listed in the XCodeProject. If it does not find the .app at this position, 
it fails the conversion and the entire compile process. 

The .app it creates is based upon the Cordova project name. The name in the 
XCodeProject is the name used for applications name when it is on a device, so 
now this name must match the project name or conversion won't work. 

This can be fixed in a number of ways. 
 - Include a "no-conversion" option, which would mimic the old behavior.
 - Include a way to pass the desired name to compile.
 - Have the .app name be pulled from some other configuration that isn't tied 
to a the iOS display name. 



--
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-8054) Camera getPicture photo library not supported on Windows?

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-8054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699865#comment-14699865
 ] 

ASF GitHub Bot commented on CB-8054:


Github user ekambarrao commented on the pull request:


https://github.com/apache/cordova-plugin-camera/pull/86#issuecomment-131895353
  
@purplecabbage this is like light in darkyour offer itself is like a 
great savior to me:-)

I have uploaded the solutions @ the following onedrive


https://onedrive.live.com/?id=463D607901FE1563%21114&cid=463D607901FE1563&group=0

blankcordovaapp1 is failing where I experimented.

javascript(2) has been working fine.

they were in VS 2013 and it is picking up cordova 3.7.1

I have moved the code to VS 2015 and I selected 5.1.1 s platform but it is 
showing 4.0 folder in .cordova folder.

2015 working as long as the device in debug when disconnected again the 
same.


> Camera getPicture photo library not supported on Windows?
> -
>
> Key: CB-8054
> URL: https://issues.apache.org/jira/browse/CB-8054
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Plugin Camera, Windows
>Affects Versions: 3.7.1
> Environment: Windows Phone 8.1
> Lumia 635
> Windows universal app platform
> Camera plugin v0.3.3
>Reporter: Boston Dell-Vandenberg
>Assignee: Murat Sutunc
>
> On the Windows platform when calling getPicture() with "sourceType" of 
> "PHOTOLIBRARY" or "SAVEDPHOTOALBUM" it returns "Not supported" error. 
> The plugin documentation says Windows is supported but is that not the case?



--
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-9499) Windows 10: x64-build fails to run when running on an x86 version of Node.js

[Rob Paveza (JIRA)]

Rob Paveza created CB-9499:
--

 Summary: Windows 10: x64-build fails to run when running on an x86 
version of Node.js
 Key: CB-9499
 URL: https://issues.apache.org/jira/browse/CB-9499
 Project: Apache Cordova
  Issue Type: Bug
  Components: mobile-spec, Windows
Reporter: Rob Paveza
Assignee: Rob Paveza
Priority: Critical


When running an x64 version of a Cordova app, if the Node.js process is 32-bit, 
it will spawn 32-bit shells (like cmd.exe or PowerShell).  In such a case, 
installing a 64-bit app with 64-bit dependencies will fail because of a bug in 
the VS-packaged installation script, which doesn't check for package 
architecture, but rather the system's processor architecture, which in a 32-bit 
shell is reported as x86.

This is particularly important because Mobilespec uses .NET components.  On 
Windows 10, these components must be .NET Native compiled, which means that 
they must be platform-specific compiled.  As a result, when running with 

cordova run windows -- --archs=x64 --appx=uap

Mobilespec will build but fail to be run, reporting missing dependencies in the 
graph.



--
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-8054) Camera getPicture photo library not supported on Windows?

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-8054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699787#comment-14699787
 ] 

ASF GitHub Bot commented on CB-8054:


Github user purplecabbage commented on the pull request:


https://github.com/apache/cordova-plugin-camera/pull/86#issuecomment-131881725
  
Please post your non-working example, and I will look at it.
Speculation is dangerous.

This has nothing to do with cordovaApp_temporarykey.pfx
Define 'rolled back changes'... via version control? did you run 'cordova 
prepare'?



> Camera getPicture photo library not supported on Windows?
> -
>
> Key: CB-8054
> URL: https://issues.apache.org/jira/browse/CB-8054
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Plugin Camera, Windows
>Affects Versions: 3.7.1
> Environment: Windows Phone 8.1
> Lumia 635
> Windows universal app platform
> Camera plugin v0.3.3
>Reporter: Boston Dell-Vandenberg
>Assignee: Murat Sutunc
>
> On the Windows platform when calling getPicture() with "sourceType" of 
> "PHOTOLIBRARY" or "SAVEDPHOTOALBUM" it returns "Not supported" error. 
> The plugin documentation says Windows is supported but is that not the case?



--
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-8936) Surface platform-specific logs in buildbot

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-8936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699621#comment-14699621
 ] 

ASF GitHub Bot commented on CB-8936:


GitHub user alsorokin opened a pull request:

https://github.com/apache/cordova-windows/pull/115

CB-8936 Logs: Stability and formatting improvements

https://issues.apache.org/jira/browse/CB-8936

- Filter out logs from other applications
- Eliminated synchronous shelljs execution
- Minor formatting changes

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/MSOpenTech/cordova-windows CB-8936

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-windows/pull/115.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #115


commit 1b415a69607c18469c3091c907754d1c11364636
Author: alsorokin 
Date:   2015-08-17T14:47:18Z

CB-8936 Logs: Stability and formatting improvements




> Surface platform-specific logs in buildbot
> --
>
> Key: CB-8936
> URL: https://issues.apache.org/jira/browse/CB-8936
> Project: Apache Cordova
>  Issue Type: Task
>  Components: Medic
>Reporter: Alexander Sorokin
>Assignee: Alexander Sorokin
>
> Platform specific logs (e.g. logcat for android, stderr.log and stdin.log for 
> iOS etc.) should be gathered and displayed in buildbot.



--
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-8054) Camera getPicture photo library not supported on Windows?

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-8054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699495#comment-14699495
 ] 

ASF GitHub Bot commented on CB-8054:


Github user ekambarrao commented on the pull request:


https://github.com/apache/cordova-plugin-camera/pull/86#issuecomment-131809954
  
I used a cordova navigation sample. 

worked perfectly alright up to some extent. 

When I click on the camera, it perfectly returns to library, 

click save, 

Important Point: "it returns to page then tries to render the image"

I started making changes line by line and was testing it..to see if 
this makes difference or that makes difference...it broke at one point...

i rolled back changes...but it was not rolling back

Does this have any thing to do cordovaApp_temporarykey.pfx?

do we need to have this file in the solution to have this work?

when i create another application with the same lines of code it was not 
working..what is happening guyscordova is really very bad in managing 
its state or I am using winjs for navigation, it is bad in managing the 
stateit is not hitting the resume event in index.js at all to capture 
the reason for failure.


> Camera getPicture photo library not supported on Windows?
> -
>
> Key: CB-8054
> URL: https://issues.apache.org/jira/browse/CB-8054
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Plugin Camera, Windows
>Affects Versions: 3.7.1
> Environment: Windows Phone 8.1
> Lumia 635
> Windows universal app platform
> Camera plugin v0.3.3
>Reporter: Boston Dell-Vandenberg
>Assignee: Murat Sutunc
>
> On the Windows platform when calling getPicture() with "sourceType" of 
> "PHOTOLIBRARY" or "SAVEDPHOTOALBUM" it returns "Not supported" error. 
> The plugin documentation says Windows is supported but is that not the case?



--
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-8054) Camera getPicture photo library not supported on Windows?

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-8054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699491#comment-14699491
 ] 

ASF GitHub Bot commented on CB-8054:


Github user ekambarrao commented on the pull request:


https://github.com/apache/cordova-plugin-camera/pull/86#issuecomment-131806741
  
@purplecabbage , mine is cordova javascript application. I am really in a 
very bad shape due to lack of support from all OEM of these techs. Very bad 
Its been 500 hours of trials after trails to figure out how to make this work 
consistent way without fail but could not resolve this. Stackoverflow did not 
help, slack did not help.what is the wrong .wheregod only knows


> Camera getPicture photo library not supported on Windows?
> -
>
> Key: CB-8054
> URL: https://issues.apache.org/jira/browse/CB-8054
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Plugin Camera, Windows
>Affects Versions: 3.7.1
> Environment: Windows Phone 8.1
> Lumia 635
> Windows universal app platform
> Camera plugin v0.3.3
>Reporter: Boston Dell-Vandenberg
>Assignee: Murat Sutunc
>
> On the Windows platform when calling getPicture() with "sourceType" of 
> "PHOTOLIBRARY" or "SAVEDPHOTOALBUM" it returns "Not supported" error. 
> The plugin documentation says Windows is supported but is that not the case?



--
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-9498) FileReader.prototype.readAsText runs malfunctionnally in mobilespec

[Dong Hanlin (JIRA)]

Dong Hanlin created CB-9498:
---

 Summary: FileReader.prototype.readAsText runs malfunctionnally in 
mobilespec
 Key: CB-9498
 URL: https://issues.apache.org/jira/browse/CB-9498
 Project: Apache Cordova
  Issue Type: Bug
  Components: Android, mobile-spec, Plugin File
Affects Versions: 4.0.1
 Environment: Android 4.4, 5.0
Reporter: Dong Hanlin
Priority: Minor


When running tests of cordova-plugin-file with Mobilespec, file.spec.83 failed. 
Error messages are listed below:

Error: Expected null to be 'asdfasdf'.
at 
stack(file:///android_asset/www/cdvtests/jasmine-2.0.0/jasmine.js:1292:17)
at 
buildExpectationResult(file:///android_asset/www/cdvtests/jasmine-2.0.0/jasmine.js:1269:14)
at 
Spec.Env.expectationResultFactory(file:///android_asset/www/cdvtests/jasmine-2.0.0/jasmine.js:483:18)
at 
Spec.addExpectationResult(file:///android_asset/www/cdvtests/jasmine-2.0.0/jasmine.js:259:46)
at 
Expectation.addExpectationResult(file:///android_asset/www/cdvtests/jasmine-2.0.0/jasmine.js/441:21)
at 
Expectation.toBe(file:///android_asset/www/cdvtests/jasmine-2.0.0/jasmine.js:1208:12)
at 
FileReader.verifier(file:///android_asset/www/plugins/cordova-plugin-file-tests/tests.js:2190:47)

When looking into the source code FileReader.js, it is found that readAsText is 
overrided. However, this function didn't return the expected result we want. 
*And this problem happens only in tests. In daily usage, such problems don't 
appear.*



--
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