[jira] [Commented] (CB-4862) ios 7 keyboard resizes the page even with KeyboardShrinksView set to false
[ https://issues.apache.org/jira/browse/CB-4862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13884003#comment-13884003 ] Chris Emerson commented on CB-4862: --- Thanks Shazron. Unfortunately hooks are just above my grasp at the moment - I've read some articles on them but I just don't get them yet (i.e. not sure how to really create/use them in even a general way let alone the specific way I'd need them for this issue). Any chance you can predict how this issue is going to pan out with Cordova? Will we have to have two different viewports for Android/iOS forever or will the ShrinkKeyboard behavior in iOS get fixed/reverted back to how it behaved prior to iOS7? Any insight you could share would help me plan things on my end. My main concern is that this loose end is going to remain a painful step in our deployment and testing process. ios 7 keyboard resizes the page even with KeyboardShrinksView set to false -- Key: CB-4862 URL: https://issues.apache.org/jira/browse/CB-4862 Project: Apache Cordova Issue Type: Bug Components: iOS Affects Versions: 2.8.0 Environment: ipod 5th gen ios 7 and simulator for ios 7 Reporter: Jake Williams Assignee: Shazron Abdullah Labels: ios7, keyboard-plugin We have a page with a fixed footer and some inputs. In previous ios versions the page would be pushed up when an input was focused and the keyboard came up. In ios 7, the page height is reduced to the available space after the keyboard appears and the footer covers the input (depends on the position of the footer, but it does happen sometimes). There is also a problem where the input could be beneath the keyboard if you have multiple inputs and you use next/previous to move between them. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CB-5915) Change iOS filesystem root location
Ian Clelland created CB-5915:
Summary: Change iOS filesystem root location
Key: CB-5915
URL: https://issues.apache.org/jira/browse/CB-5915
Project: Apache Cordova
Issue Type: Sub-task
Components: iOS, Plugin File
Reporter: Ian Clelland
Assignee: Ian Clelland
iOS Persistent files are stored in an inconvenient place by default: The
application's documents directory, which means that all files created are
exposed by default in itunes.
Extensive discussion here: http://apache.markmail.org/thread/vlu55ppwkgh2bn56
There should be a single preference in config.xml for iOS persistent files. It
can take one of two values (currently; additional values may be added later if
we have better ideas)
{code}
preference name=iosPersistentFileLocation value=Documents / (Old location)
preference name=iosPersistentFileLocation value=Library / (New location)
{code}
Library will put persistent files under {{Application Library Path/files}}
-- the extra {{/files}} means that other filesystem plugins can register roots
at different places under {{Application Library Path}} which will not be
visible to one another.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (CB-5916) Change Android filesystem root location
Ian Clelland created CB-5916:
Summary: Change Android filesystem root location
Key: CB-5916
URL: https://issues.apache.org/jira/browse/CB-5916
Project: Apache Cordova
Issue Type: Sub-task
Components: Android, Plugin File
Reporter: Ian Clelland
Assignee: Ian Clelland
Android Persistent files are (also) stored in an inconvenient place by default:
Either the application data directory (not accounting for a possible multi-user
environment), or the root of the SD Card, if it is mounted (And on Nexus
devices, the emulated SD Card is *always* mounted)
See CB-285 for much more discussion, and
http://developer.android.com/guide/topics/data/data-storage.html for a good
explanation of the properties of various storage locations.
There should be a single preference in config.xml for Android persistent files.
It can take one of two values (currently; additional values may be added later
if we have better ideas)
{code}
preference name=AndroidPersistentFileLocation value=Compatibility / (Old
location logic)
preference name=AndroidPersistentFileLocation value=Internal / (New
location)
{code}
{{Internal}} will put persistent files under the user's application internal
storage directory {{Activity.getFilesDir() + /files}} -- the extra {{/files}}
means that other filesystem plugins can register roots at different places
under {{getFilesDir()}} which will not be visible to one another.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (CB-5915) Change iOS filesystem root location
[
https://issues.apache.org/jira/browse/CB-5915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ian Clelland updated CB-5915:
-
Description:
iOS Persistent files are stored in an inconvenient place by default: The
application's documents directory, which means that all files created are
exposed by default in itunes.
Extensive discussion here: http://apache.markmail.org/thread/vlu55ppwkgh2bn56
There should be a single preference in config.xml for iOS persistent files. It
can take one of two values (currently; additional values may be added later if
we have better ideas)
{code}
preference name=iosPersistentFileLocation value=Compatibility / (Old
location)
preference name=iosPersistentFileLocation value=Library / (New location)
{code}
Library will put persistent files under {{Application Library Path/files}}
-- the extra {{/files}} means that other filesystem plugins can register roots
at different places under {{Application Library Path}} which will not be
visible to one another.
was:
iOS Persistent files are stored in an inconvenient place by default: The
application's documents directory, which means that all files created are
exposed by default in itunes.
Extensive discussion here: http://apache.markmail.org/thread/vlu55ppwkgh2bn56
There should be a single preference in config.xml for iOS persistent files. It
can take one of two values (currently; additional values may be added later if
we have better ideas)
{code}
preference name=iosPersistentFileLocation value=Documents / (Old location)
preference name=iosPersistentFileLocation value=Library / (New location)
{code}
Library will put persistent files under {{Application Library Path/files}}
-- the extra {{/files}} means that other filesystem plugins can register roots
at different places under {{Application Library Path}} which will not be
visible to one another.
Change iOS filesystem root location
---
Key: CB-5915
URL: https://issues.apache.org/jira/browse/CB-5915
Project: Apache Cordova
Issue Type: Sub-task
Components: iOS, Plugin File
Reporter: Ian Clelland
Assignee: Ian Clelland
iOS Persistent files are stored in an inconvenient place by default: The
application's documents directory, which means that all files created are
exposed by default in itunes.
Extensive discussion here: http://apache.markmail.org/thread/vlu55ppwkgh2bn56
There should be a single preference in config.xml for iOS persistent files.
It can take one of two values (currently; additional values may be added
later if we have better ideas)
{code}
preference name=iosPersistentFileLocation value=Compatibility / (Old
location)
preference name=iosPersistentFileLocation value=Library / (New location)
{code}
Library will put persistent files under {{Application Library
Path/files}} -- the extra {{/files}} means that other filesystem plugins can
register roots at different places under {{Application Library Path}} which
will not be visible to one another.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CB-5916) Change Android filesystem root location
[
https://issues.apache.org/jira/browse/CB-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13884214#comment-13884214
]
ASF subversion and git services commented on CB-5916:
-
Commit edf6b27b06bf2479f14298a83707456640c1efc3 in branch refs/heads/master
from [~iclelland]
[ https://git-wip-us.apache.org/repos/asf?p=cordova-mobile-spec.git;h=edf6b27 ]
CB-5916: Add preference for Android persistent location
Change Android filesystem root location
---
Key: CB-5916
URL: https://issues.apache.org/jira/browse/CB-5916
Project: Apache Cordova
Issue Type: Sub-task
Components: Android, Plugin File
Reporter: Ian Clelland
Assignee: Ian Clelland
Android Persistent files are (also) stored in an inconvenient place by
default: Either the application data directory (not accounting for a possible
multi-user environment), or the root of the SD Card, if it is mounted (And on
Nexus devices, the emulated SD Card is *always* mounted)
See CB-285 for much more discussion, and
http://developer.android.com/guide/topics/data/data-storage.html for a good
explanation of the properties of various storage locations.
There should be a single preference in config.xml for Android persistent
files. It can take one of two values (currently; additional values may be
added later if we have better ideas)
{code}
preference name=AndroidPersistentFileLocation value=Compatibility /
(Old location logic)
preference name=AndroidPersistentFileLocation value=Internal / (New
location)
{code}
{{Internal}} will put persistent files under the user's application
internal storage directory {{Activity.getFilesDir() + /files}} -- the extra
{{/files}} means that other filesystem plugins can register roots at
different places under {{getFilesDir()}} which will not be visible to one
another.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CB-5915) Change iOS filesystem root location
[
https://issues.apache.org/jira/browse/CB-5915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13884217#comment-13884217
]
ASF subversion and git services commented on CB-5915:
-
Commit 40df005f6d4f3b4a984b3eae0275a16ac8f86513 in branch refs/heads/dev from
[~iclelland]
[ https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-file.git;h=40df005 ]
CB-5915: ios: Update config preference (and docs) to match issue
Change iOS filesystem root location
---
Key: CB-5915
URL: https://issues.apache.org/jira/browse/CB-5915
Project: Apache Cordova
Issue Type: Sub-task
Components: iOS, Plugin File
Reporter: Ian Clelland
Assignee: Ian Clelland
iOS Persistent files are stored in an inconvenient place by default: The
application's documents directory, which means that all files created are
exposed by default in itunes.
Extensive discussion here: http://apache.markmail.org/thread/vlu55ppwkgh2bn56
There should be a single preference in config.xml for iOS persistent files.
It can take one of two values (currently; additional values may be added
later if we have better ideas)
{code}
preference name=iosPersistentFileLocation value=Compatibility / (Old
location)
preference name=iosPersistentFileLocation value=Library / (New location)
{code}
Library will put persistent files under {{Application Library
Path/files}} -- the extra {{/files}} means that other filesystem plugins can
register roots at different places under {{Application Library Path}} which
will not be visible to one another.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CB-5916) Change Android filesystem root location
[
https://issues.apache.org/jira/browse/CB-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13884216#comment-13884216
]
ASF subversion and git services commented on CB-5916:
-
Commit 3fa16d04cd1b5e68ad8075c22ba549c4fa24fff5 in branch refs/heads/dev from
[~iclelland]
[ https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-file.git;h=3fa16d0 ]
CB-5916: Android: Add config preference for Android persistent storage location
Change Android filesystem root location
---
Key: CB-5916
URL: https://issues.apache.org/jira/browse/CB-5916
Project: Apache Cordova
Issue Type: Sub-task
Components: Android, Plugin File
Reporter: Ian Clelland
Assignee: Ian Clelland
Android Persistent files are (also) stored in an inconvenient place by
default: Either the application data directory (not accounting for a possible
multi-user environment), or the root of the SD Card, if it is mounted (And on
Nexus devices, the emulated SD Card is *always* mounted)
See CB-285 for much more discussion, and
http://developer.android.com/guide/topics/data/data-storage.html for a good
explanation of the properties of various storage locations.
There should be a single preference in config.xml for Android persistent
files. It can take one of two values (currently; additional values may be
added later if we have better ideas)
{code}
preference name=AndroidPersistentFileLocation value=Compatibility /
(Old location logic)
preference name=AndroidPersistentFileLocation value=Internal / (New
location)
{code}
{{Internal}} will put persistent files under the user's application
internal storage directory {{Activity.getFilesDir() + /files}} -- the extra
{{/files}} means that other filesystem plugins can register roots at
different places under {{getFilesDir()}} which will not be visible to one
another.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CB-5917) Add a loadUrlIntoView overload that doesn't always recreate plugins.
[ https://issues.apache.org/jira/browse/CB-5917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13884250#comment-13884250 ] ASF subversion and git services commented on CB-5917: - Commit ac2034561ddf626027c87434a3994636d448e0a0 in branch refs/heads/master from [~agrieve] [ https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;h=ac20345 ] CB-5917 Add a loadUrlIntoView overload that doesn't recreate plugins. Add a loadUrlIntoView overload that doesn't always recreate plugins. Key: CB-5917 URL: https://issues.apache.org/jira/browse/CB-5917 Project: Apache Cordova Issue Type: Bug Components: Android Reporter: Andrew Grieve Assignee: Andrew Grieve Priority: Minor Right now, plugins can navigate by calling loadUrl() or loadUrlIntoView(), but both of these cause plugins to be re-created instead of a regular navigation, which calls onReset() on the plugins instead. We should support either way. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CB-5917) Add a loadUrlIntoView overload that doesn't always recreate plugins.
[ https://issues.apache.org/jira/browse/CB-5917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Grieve resolved CB-5917. --- Resolution: Fixed Fix Version/s: 3.4.0 Add a loadUrlIntoView overload that doesn't always recreate plugins. Key: CB-5917 URL: https://issues.apache.org/jira/browse/CB-5917 Project: Apache Cordova Issue Type: Bug Components: Android Reporter: Andrew Grieve Assignee: Andrew Grieve Priority: Minor Fix For: 3.4.0 Right now, plugins can navigate by calling loadUrl() or loadUrlIntoView(), but both of these cause plugins to be re-created instead of a regular navigation, which calls onReset() on the plugins instead. We should support either way. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CB-5917) Add a loadUrlIntoView overload that doesn't always recreate plugins.
[ https://issues.apache.org/jira/browse/CB-5917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13884253#comment-13884253 ] ASF subversion and git services commented on CB-5917: - Commit 6760d0378a35b076ea8ffb5088a3883a1c414f66 in branch refs/heads/3.4.x from [~agrieve] [ https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;h=6760d03 ] CB-5917 Add a loadUrlIntoView overload that doesn't recreate plugins. Add a loadUrlIntoView overload that doesn't always recreate plugins. Key: CB-5917 URL: https://issues.apache.org/jira/browse/CB-5917 Project: Apache Cordova Issue Type: Bug Components: Android Reporter: Andrew Grieve Assignee: Andrew Grieve Priority: Minor Right now, plugins can navigate by calling loadUrl() or loadUrlIntoView(), but both of these cause plugins to be re-created instead of a regular navigation, which calls onReset() on the plugins instead. We should support either way. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CB-5917) Add a loadUrlIntoView overload that doesn't always recreate plugins.
Andrew Grieve created CB-5917: - Summary: Add a loadUrlIntoView overload that doesn't always recreate plugins. Key: CB-5917 URL: https://issues.apache.org/jira/browse/CB-5917 Project: Apache Cordova Issue Type: Bug Components: Android Reporter: Andrew Grieve Assignee: Andrew Grieve Priority: Minor Right now, plugins can navigate by calling loadUrl() or loadUrlIntoView(), but both of these cause plugins to be re-created instead of a regular navigation, which calls onReset() on the plugins instead. We should support either way. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CB-5905) Cordova hook saved on Windows fails on OS X
[ https://issues.apache.org/jira/browse/CB-5905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Grieve resolved CB-5905. --- Resolution: Won't Fix Assignee: Andrew Grieve This problem is generally dealt with by your source control system. E.g. for git, see https://help.github.com/articles/dealing-with-line-endings Cordova hook saved on Windows fails on OS X Key: CB-5905 URL: https://issues.apache.org/jira/browse/CB-5905 Project: Apache Cordova Issue Type: Bug Components: CLI Affects Versions: 3.3.0 Environment: cordova 3.3.1-0.1.2 node v0.10.22 OS X 10.8.5 Reporter: Bruce Lefebvre Assignee: Andrew Grieve Priority: Minor Cordova CLI fails to run hooks that have been saved and archived on a Windows system. To reproduce: - on OS X, download endofline.zip (archive of a CLI project) from [0] - extract it - cd to the extracted 'endofline' directory - `cordova platform add ios` Output: /usr/local/share/npm/lib/node_modules/cordova/node_modules/q/q.js:126 throw e; ^ Error: Script /user dir/Downloads/endofline/.cordova/hooks/before_platform_add/01_log_something.js exited with status code 127. Aborting. Output: env: node\r: No such file or directory at /usr/local/share/npm/lib/node_modules/cordova/src/hooker.js:138:34 at ChildProcess.exithandler (child_process.js:641:7) at ChildProcess.EventEmitter.emit (events.js:98:17) at maybeClose (child_process.js:735:16) at Socket.anonymous (child_process.js:948:11) at Socket.EventEmitter.emit (events.js:95:17) at Pipe.close (net.js:466:12) [0] https://bitbucket.org/brucelefebvre/phonegap-cli-node-r-no-such-file-or-directory-issue/downloads -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CB-5915) Change iOS filesystem root location
[
https://issues.apache.org/jira/browse/CB-5915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13884315#comment-13884315
]
ASF subversion and git services commented on CB-5915:
-
Commit d5478e561277a80d54021c5ad5112a0b2bf06e6a in branch refs/heads/dev from
[~iclelland]
[ https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-file.git;h=d5478e5 ]
CB-5915: Create documents directories if they don't exist
Change iOS filesystem root location
---
Key: CB-5915
URL: https://issues.apache.org/jira/browse/CB-5915
Project: Apache Cordova
Issue Type: Sub-task
Components: iOS, Plugin File
Reporter: Ian Clelland
Assignee: Ian Clelland
iOS Persistent files are stored in an inconvenient place by default: The
application's documents directory, which means that all files created are
exposed by default in itunes.
Extensive discussion here: http://apache.markmail.org/thread/vlu55ppwkgh2bn56
There should be a single preference in config.xml for iOS persistent files.
It can take one of two values (currently; additional values may be added
later if we have better ideas)
{code}
preference name=iosPersistentFileLocation value=Compatibility / (Old
location)
preference name=iosPersistentFileLocation value=Library / (New location)
{code}
Library will put persistent files under {{Application Library
Path/files}} -- the extra {{/files}} means that other filesystem plugins can
register roots at different places under {{Application Library Path}} which
will not be visible to one another.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CB-5852) Keyboard plugin on iOS7 can cause re-layout bugs with fixed position bottom elements
[ https://issues.apache.org/jira/browse/CB-5852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13884316#comment-13884316 ] Michal Mocny commented on CB-5852: -- Alright, cleanup up the patch and did a bunch of testing on ios6 and 7. Not all the cases are ever perfect on any of the platforms :( but we don't currently implement a non shrinking view on iOS7 either way, and shrinking it explicitly is causing layout issues which is a problem. So I changed the shrinkview handler to just no-op on iOS7 until we actually look at implementing a non-shrinking webview (if even possible). The one downside is that now webview scrolling cannot be disabled on ios7 now. I will look into re-adding that. But it seems to only work when shrinkview is enabled and keyboard is open -- not sure what the use case is here? Keyboard plugin on iOS7 can cause re-layout bugs with fixed position bottom elements Key: CB-5852 URL: https://issues.apache.org/jira/browse/CB-5852 Project: Apache Cordova Issue Type: Bug Components: iOS, Plugins Reporter: Michal Mocny Assignee: Michal Mocny Priority: Minor Labels: keyboard-plugin Pull Request for fix: https://github.com/apache/cordova-plugins/pull/2 Copying the description here: If there is a fixed position, bottom positioned element on the page, this keyboard plugin causes awkward re-layouts of the element on keyboard pop up -- but only occasionally (I can attach screenshots if you cannot reproduce). Repro steps: 1. Add to blank app: 2. 'cordova emulate ios' on ios7 simulator 3. click the input box to open keyboard 4. See input briefly in right position, then migrate to the top of page It appears there is a race of some kind, since it happens consistently when run in simulator outside of xcode via 'cordova emulate ios', but does not happen when using xcode debugging or when run on device. While this doesn't seem high priority, as far as I can tell, this code is not doing anything useful on ios7, so can just safely just be no-oped. WDYT? -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CB-5916) Change Android filesystem root location
[
https://issues.apache.org/jira/browse/CB-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13884317#comment-13884317
]
ASF subversion and git services commented on CB-5916:
-
Commit 620bb7cd8b47fe67e71e96eaaffa56831b577def in branch refs/heads/dev from
[~iclelland]
[ https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-file.git;h=620bb7c ]
CB-5916: Create documents directories if they don't exist
Change Android filesystem root location
---
Key: CB-5916
URL: https://issues.apache.org/jira/browse/CB-5916
Project: Apache Cordova
Issue Type: Sub-task
Components: Android, Plugin File
Reporter: Ian Clelland
Assignee: Ian Clelland
Android Persistent files are (also) stored in an inconvenient place by
default: Either the application data directory (not accounting for a possible
multi-user environment), or the root of the SD Card, if it is mounted (And on
Nexus devices, the emulated SD Card is *always* mounted)
See CB-285 for much more discussion, and
http://developer.android.com/guide/topics/data/data-storage.html for a good
explanation of the properties of various storage locations.
There should be a single preference in config.xml for Android persistent
files. It can take one of two values (currently; additional values may be
added later if we have better ideas)
{code}
preference name=AndroidPersistentFileLocation value=Compatibility /
(Old location logic)
preference name=AndroidPersistentFileLocation value=Internal / (New
location)
{code}
{{Internal}} will put persistent files under the user's application
internal storage directory {{Activity.getFilesDir() + /files}} -- the extra
{{/files}} means that other filesystem plugins can register roots at
different places under {{getFilesDir()}} which will not be visible to one
another.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CB-5852) Keyboard plugin on iOS7 can cause re-layout bugs with fixed position bottom elements
[ https://issues.apache.org/jira/browse/CB-5852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13884310#comment-13884310 ] ASF subversion and git services commented on CB-5852: - Commit 20215013bf91b659b73d5f428ae91dd58be1273a in branch refs/heads/master from [~mmocny] [ https://git-wip-us.apache.org/repos/asf?p=cordova-plugins.git;h=2021501 ] CB-5852: Disable iOS7 keyboard shrinkview, because of layout issues. Keyboard plugin on iOS7 can cause re-layout bugs with fixed position bottom elements Key: CB-5852 URL: https://issues.apache.org/jira/browse/CB-5852 Project: Apache Cordova Issue Type: Bug Components: iOS, Plugins Reporter: Michal Mocny Assignee: Michal Mocny Priority: Minor Labels: keyboard-plugin Pull Request for fix: https://github.com/apache/cordova-plugins/pull/2 Copying the description here: If there is a fixed position, bottom positioned element on the page, this keyboard plugin causes awkward re-layouts of the element on keyboard pop up -- but only occasionally (I can attach screenshots if you cannot reproduce). Repro steps: 1. Add to blank app: 2. 'cordova emulate ios' on ios7 simulator 3. click the input box to open keyboard 4. See input briefly in right position, then migrate to the top of page It appears there is a race of some kind, since it happens consistently when run in simulator outside of xcode via 'cordova emulate ios', but does not happen when using xcode debugging or when run on device. While this doesn't seem high priority, as far as I can tell, this code is not doing anything useful on ios7, so can just safely just be no-oped. WDYT? -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CB-5918) Cordova on Windows: RangeError: Maximum call stack size exceeded
Benjamin Reed created CB-5918:
-
Summary: Cordova on Windows: RangeError: Maximum call stack size
exceeded
Key: CB-5918
URL: https://issues.apache.org/jira/browse/CB-5918
Project: Apache Cordova
Issue Type: Bug
Components: WP7
Affects Versions: 3.3.0
Environment: Windows 7 SP1
Reporter: Benjamin Reed
Assignee: Jesse MacFadyen
Priority: Blocker
I have an existing project (http://github.com/RangerRick/CruiseMonkey) which
builds and works on iOS and Android on my mac.
I'm attempting to add WP7 support. I've checked out my project on my Windows 7
PC, installed Cordova, and when I run cordova platform add wp7 I get the
following error:
{code}D:\Users\ranger\rcs\CruiseMonkeycordova platform add wp7
path.js:226
joined = joined.replace(/^[\\\/]{2,}/, '\\');
^
RangeError: Maximum call stack size exceeded
D:\Users\ranger\rcs\CruiseMonkeycordova --version
3.3.1-0.1.2{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (CB-5907) Update: list actual version from update
[ https://issues.apache.org/jira/browse/CB-5907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Soref resolved CB-5907. Resolution: Fixed Fix Version/s: 3.4.0 Update: list actual version from update --- Key: CB-5907 URL: https://issues.apache.org/jira/browse/CB-5907 Project: Apache Cordova Issue Type: Bug Components: CLI Reporter: Josh Soref Assignee: Josh Soref Priority: Minor Fix For: 3.4.0 Cordova platform update assumes that the version in its manifest matches the version that the platform scripts are creating. This isn't always reliable, and it would be better to actually ask the platform scripts (since they'll be in place after an update) what version the platform is. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CB-5918) Cordova on Windows: RangeError: Maximum call stack size exceeded
[
https://issues.apache.org/jira/browse/CB-5918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13884323#comment-13884323
]
Benjamin Reed commented on CB-5918:
---
Some additional info:
* Windows 7 64-bit
* node.js is installed in C:\Program Files\nodejs
* npm data is in C:\Users\Benjamin Reed\AppData\Roaming\npm
* project is in D:\Users\ranger\rcs\CruiseMonkey
Cordova on Windows: RangeError: Maximum call stack size exceeded
Key: CB-5918
URL: https://issues.apache.org/jira/browse/CB-5918
Project: Apache Cordova
Issue Type: Bug
Components: WP7
Affects Versions: 3.3.0
Environment: Windows 7 SP1
Reporter: Benjamin Reed
Assignee: Jesse MacFadyen
Priority: Blocker
Labels: windows-phone
I have an existing project (http://github.com/RangerRick/CruiseMonkey) which
builds and works on iOS and Android on my mac.
I'm attempting to add WP7 support. I've checked out my project on my Windows
7 PC, installed Cordova, and when I run cordova platform add wp7 I get the
following error:
{code}D:\Users\ranger\rcs\CruiseMonkeycordova platform add wp7
path.js:226
joined = joined.replace(/^[\\\/]{2,}/, '\\');
^
RangeError: Maximum call stack size exceeded
D:\Users\ranger\rcs\CruiseMonkeycordova --version
3.3.1-0.1.2{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CB-5918) Cordova on Windows: RangeError: Maximum call stack size exceeded
[
https://issues.apache.org/jira/browse/CB-5918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13884339#comment-13884339
]
Benjamin Reed commented on CB-5918:
---
Aha! Looks like it fails when the project isn't in the same place as node.js.
If I check out my project to my C: I don't get the path.js error.
Cordova on Windows: RangeError: Maximum call stack size exceeded
Key: CB-5918
URL: https://issues.apache.org/jira/browse/CB-5918
Project: Apache Cordova
Issue Type: Bug
Components: WP7
Affects Versions: 3.3.0
Environment: Windows 7 SP1
Reporter: Benjamin Reed
Assignee: Jesse MacFadyen
Priority: Blocker
Labels: windows-phone
I have an existing project (http://github.com/RangerRick/CruiseMonkey) which
builds and works on iOS and Android on my mac.
I'm attempting to add WP7 support. I've checked out my project on my Windows
7 PC, installed Cordova, and when I run cordova platform add wp7 I get the
following error:
{code}D:\Users\ranger\rcs\CruiseMonkeycordova platform add wp7
path.js:226
joined = joined.replace(/^[\\\/]{2,}/, '\\');
^
RangeError: Maximum call stack size exceeded
D:\Users\ranger\rcs\CruiseMonkeycordova --version
3.3.1-0.1.2{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (CB-5919) Blackberry10 with InAppBrowser plugin
Boston Dell-Vandenberg created CB-5919:
--
Summary: Blackberry10 with InAppBrowser plugin
Key: CB-5919
URL: https://issues.apache.org/jira/browse/CB-5919
Project: Apache Cordova
Issue Type: Bug
Components: BlackBerry, Plugin InAppBrowser
Affects Versions: 3.3.0
Environment: Blackberry 10.2.1
Reporter: Boston Dell-Vandenberg
InAppBrowser plugin when installed via the CLI gets installed on the
blackberry10 platform. References to the plugin are added to cordova_plugins.js
that clobber window.open and cause the native inappbrowser to fail.
{code}
Error: 'undefined' is not an object (evaluating 'event.type')
_eventHandler@local:///plugins/org.apache.cordova.inappbrowser/www/InAppBrowser.js:39:17
cb@local:///plugins/org.apache.cordova.inappbrowser/www/InAppBrowser.js:94:24
callbackFromNative@local:///cordova.js:294:52
exports@local:///cordova.js:874:38
exports@local:///plugins/org.apache.cordova.inappbrowser/www/InAppBrowser.js:97:8
getRemoteFileFromOnlineStorage@local:///scripts/controllers/fax.js:599:32
...
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CB-5748) Media status change not reported on recording start.
[
https://issues.apache.org/jira/browse/CB-5748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13884352#comment-13884352
]
Mark Bradshaw commented on CB-5748:
---
I have located and patched the problem code in
https://github.com/mbradshawabs/cordova-plugin-media/commit/3ed29082a1898dbf4384076aabe923a38f2b0ada.
I will issue a pull request to the github repo to get this fix into the
plugin.
Media status change not reported on recording start.
Key: CB-5748
URL: https://issues.apache.org/jira/browse/CB-5748
Project: Apache Cordova
Issue Type: Bug
Components: iOS, Plugin Media
Affects Versions: 3.3.0
Reporter: Niels Snoeck
Priority: Minor
The {{mediaStatus}} callback is not executed when audio recording starts on
iOS. Expected behavior is to receive a call with the only parameter set to
{{Media.MEDIA_RUNNING}}, equivalent to the behavior on Android.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CB-5841) [mobile spec-Capture-Capture 10 secs of video] Can't play the captured video on iPad!
[ https://issues.apache.org/jira/browse/CB-5841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13884392#comment-13884392 ] ASF subversion and git services commented on CB-5841: - Commit f38fbda71a6980fb96e7e1b9e9f4e7291776d638 in branch refs/heads/master from [~glmnbeyond] [ https://git-wip-us.apache.org/repos/asf?p=cordova-mobile-spec.git;h=f38fbda ] CB-5841:Update Capture test to fix the captured video can't be displayed! [mobile spec-Capture-Capture 10 secs of video] Can't play the captured video on iPad! --- Key: CB-5841 URL: https://issues.apache.org/jira/browse/CB-5841 Project: Apache Cordova Issue Type: Bug Components: iOS, mobile-spec, Plugin Media Capture Affects Versions: 3.3.0 Environment: cordova version: 3.3.1-0.1.2 iPad 2：iOS 6.1.3 Reporter: glmnbeyond Steps to reproduce it: 1. Load mobile spec-Capture 2. Click Capture 10 secs of video 3. Try to play the Captured video, but the video can't be played! -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CB-5841) [mobile spec-Capture-Capture 10 secs of video] Can't play the captured video on iPad!
[ https://issues.apache.org/jira/browse/CB-5841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13884393#comment-13884393 ] ASF subversion and git services commented on CB-5841: - Commit 4cef6e7aeb7aca3eab39053e519d4668197f1431 in branch refs/heads/master from [~stevegill] [ https://git-wip-us.apache.org/repos/asf?p=cordova-mobile-spec.git;h=4cef6e7 ] Merge branch 'CB-5841' of github.com:lmnbeyond/cordova-mobile-spec [mobile spec-Capture-Capture 10 secs of video] Can't play the captured video on iPad! --- Key: CB-5841 URL: https://issues.apache.org/jira/browse/CB-5841 Project: Apache Cordova Issue Type: Bug Components: iOS, mobile-spec, Plugin Media Capture Affects Versions: 3.3.0 Environment: cordova version: 3.3.1-0.1.2 iPad 2：iOS 6.1.3 Reporter: glmnbeyond Steps to reproduce it: 1. Load mobile spec-Capture 2. Click Capture 10 secs of video 3. Try to play the Captured video, but the video can't be played! -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CB-5920) android:installLocation=preferExternal
cesine created CB-5920: -- Summary: android:installLocation=preferExternal Key: CB-5920 URL: https://issues.apache.org/jira/browse/CB-5920 Project: Apache Cordova Issue Type: Improvement Components: Android Environment: Phones with 512 Ram Reporter: cesine I created a PR on github suggesting to add preferExternal https://github.com/apache/cordova-android/pull/91#issuecomment-33513325 for phones with small amounts of internal storage (512MB and even 1GB, android 2.2 and 2.3 and even some 4.0) the user wont be able to install the app (or keep it) unless you let them put it on the sdcard instead of the internal phone storage. Very few cordova apps are the kind of app which shouldn't be on external storage. more details: http://developer.android.com/guide/topics/data/install-location.html#Should -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CB-5920) android:installLocation=preferExternal
[ https://issues.apache.org/jira/browse/CB-5920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13884496#comment-13884496 ] cesine commented on CB-5920: Can you create a JIRA issue? I'm pretty sure we'll need more than just an AndroidManifest change to add this feature! android:installLocation=preferExternal Key: CB-5920 URL: https://issues.apache.org/jira/browse/CB-5920 Project: Apache Cordova Issue Type: Improvement Components: Android Environment: Phones with 512 Ram Reporter: cesine Labels: patch I created a PR on github suggesting to add preferExternal https://github.com/apache/cordova-android/pull/91#issuecomment-33513325 for phones with small amounts of internal storage (512MB and even 1GB, android 2.2 and 2.3 and even some 4.0) the user wont be able to install the app (or keep it) unless you let them put it on the sdcard instead of the internal phone storage. Very few cordova apps are the kind of app which shouldn't be on external storage. more details: http://developer.android.com/guide/topics/data/install-location.html#Should -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CB-5920) android:installLocation=preferExternal
[ https://issues.apache.org/jira/browse/CB-5920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13884504#comment-13884504 ] cesine commented on CB-5920: Hi @infil00p the ramifications of preferExternal are discussed in the link above. Having read the ramifications you still think that we should not use preferExternal, or should turn it into a config option? provide additional services when inactive cordova uses services yes, but not when the app is in active? requires several megabytes - this is true of every cordova app ive built android:installLocation=preferExternal Key: CB-5920 URL: https://issues.apache.org/jira/browse/CB-5920 Project: Apache Cordova Issue Type: Improvement Components: Android Environment: Phones with 512 Ram Reporter: cesine Labels: patch I created a PR on github suggesting to add preferExternal https://github.com/apache/cordova-android/pull/91#issuecomment-33513325 for phones with small amounts of internal storage (512MB and even 1GB, android 2.2 and 2.3 and even some 4.0) the user wont be able to install the app (or keep it) unless you let them put it on the sdcard instead of the internal phone storage. Very few cordova apps are the kind of app which shouldn't be on external storage. more details: http://developer.android.com/guide/topics/data/install-location.html#Should -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CB-5920) android:installLocation=preferExternal
[ https://issues.apache.org/jira/browse/CB-5920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13884509#comment-13884509 ] cesine commented on CB-5920: I don't mind adding it to my own apps, but the real concern here is for Cordova users who actually don't know much Android. They will have lots of deactivations, and loose users, and not know why... In Montreal, many of the apps for events and festivals use Cordova, these apps are huge with lots of image and video assets, they should be on the sdcard but the developers who make them only know iOS, and wouldnt think there was an option they could choose that would reduce the space the app consumed. android:installLocation=preferExternal Key: CB-5920 URL: https://issues.apache.org/jira/browse/CB-5920 Project: Apache Cordova Issue Type: Improvement Components: Android Environment: Phones with 512 Ram Reporter: cesine Labels: patch I created a PR on github suggesting to add preferExternal https://github.com/apache/cordova-android/pull/91#issuecomment-33513325 for phones with small amounts of internal storage (512MB and even 1GB, android 2.2 and 2.3 and even some 4.0) the user wont be able to install the app (or keep it) unless you let them put it on the sdcard instead of the internal phone storage. Very few cordova apps are the kind of app which shouldn't be on external storage. more details: http://developer.android.com/guide/topics/data/install-location.html#Should -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CB-4862) ios 7 keyboard resizes the page even with KeyboardShrinksView set to false
[ https://issues.apache.org/jira/browse/CB-4862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13884549#comment-13884549 ] Shazron Abdullah commented on CB-4862: -- This *might* be resolved with the change in CB-5852. If you can take a look. ios 7 keyboard resizes the page even with KeyboardShrinksView set to false -- Key: CB-4862 URL: https://issues.apache.org/jira/browse/CB-4862 Project: Apache Cordova Issue Type: Bug Components: iOS Affects Versions: 2.8.0 Environment: ipod 5th gen ios 7 and simulator for ios 7 Reporter: Jake Williams Assignee: Shazron Abdullah Labels: ios7, keyboard-plugin We have a page with a fixed footer and some inputs. In previous ios versions the page would be pushed up when an input was focused and the keyboard came up. In ios 7, the page height is reduced to the available space after the keyboard appears and the footer covers the input (depends on the position of the footer, but it does happen sometimes). There is also a problem where the input could be beneath the keyboard if you have multiple inputs and you use next/previous to move between them. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CB-5748) Media status change not reported on recording start.
[
https://issues.apache.org/jira/browse/CB-5748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13884553#comment-13884553
]
Shazron Abdullah commented on CB-5748:
--
Awesome - thanks [~mark.bradshaw]
Media status change not reported on recording start.
Key: CB-5748
URL: https://issues.apache.org/jira/browse/CB-5748
Project: Apache Cordova
Issue Type: Bug
Components: iOS, Plugin Media
Affects Versions: 3.3.0
Reporter: Niels Snoeck
Priority: Minor
The {{mediaStatus}} callback is not executed when audio recording starts on
iOS. Expected behavior is to receive a call with the only parameter set to
{{Media.MEDIA_RUNNING}}, equivalent to the behavior on Android.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CB-5852) Keyboard plugin on iOS7 can cause re-layout bugs with fixed position bottom elements
[ https://issues.apache.org/jira/browse/CB-5852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13884556#comment-13884556 ] Shazron Abdullah commented on CB-5852: -- Leaving that out is fine I think, this plugin has too many moving parts I think getting the main parts right is more important. We'll just have to bump the version and remove the docs for that API call. Keyboard plugin on iOS7 can cause re-layout bugs with fixed position bottom elements Key: CB-5852 URL: https://issues.apache.org/jira/browse/CB-5852 Project: Apache Cordova Issue Type: Bug Components: iOS, Plugins Reporter: Michal Mocny Assignee: Michal Mocny Priority: Minor Labels: keyboard-plugin Pull Request for fix: https://github.com/apache/cordova-plugins/pull/2 Copying the description here: If there is a fixed position, bottom positioned element on the page, this keyboard plugin causes awkward re-layouts of the element on keyboard pop up -- but only occasionally (I can attach screenshots if you cannot reproduce). Repro steps: 1. Add to blank app: 2. 'cordova emulate ios' on ios7 simulator 3. click the input box to open keyboard 4. See input briefly in right position, then migrate to the top of page It appears there is a race of some kind, since it happens consistently when run in simulator outside of xcode via 'cordova emulate ios', but does not happen when using xcode debugging or when run on device. While this doesn't seem high priority, as far as I can tell, this code is not doing anything useful on ios7, so can just safely just be no-oped. WDYT? -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CB-5921) Cordova on iOS should use an XCWorkspace, or at least support using one.
Graham Mueller created CB-5921: -- Summary: Cordova on iOS should use an XCWorkspace, or at least support using one. Key: CB-5921 URL: https://issues.apache.org/jira/browse/CB-5921 Project: Apache Cordova Issue Type: Bug Components: CLI, iOS Reporter: Graham Mueller Hi Guys, Not sure what to log this as. It's not so much a bug as an incompatibility with other frameworks. Anyway, this is specifically an issue with the build process on iOS. Do with it what you will. If you're familiar with the CocoaPods framework, you'll know that on initial install, it creates an XCWorkspace file, and instructs you to exclusively use that afterwards. This is because the CocoaPods library adds itself as a linked project that must be built, similar to Cordova/Phonegap. The difference is that Cordova adds itself as a sub project, instead of a sibling project (which is effectively the workspace goal, from my understanding, though I'm having a hard time finding a good link to explain it better). So, I would suggest that Cordova moves to this setup as well -- it should create the workspace that has both the Cordova project and your app project. Alternatively, if you don't want to go through and change that creation code, it would be great if the CLI offered someway to specify what you want it to build. I found the actual build script that's calling xcodebuild with a -project flag in it (this is where -workspace would go). There is currently no way to override this, so there is currently no way at all to support workspaces (and consequently no way to use CocoaPods). Any thoughts or reasons not to do so? Thanks, Graham -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CB-5660) [BlackBerry10] init.bat fails when parentheses exist within PATH
[ https://issues.apache.org/jira/browse/CB-5660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13884708#comment-13884708 ] JennyGee commented on CB-5660: -- verified on 3.4.x [BlackBerry10] init.bat fails when parentheses exist within PATH Key: CB-5660 URL: https://issues.apache.org/jira/browse/CB-5660 Project: Apache Cordova Issue Type: Bug Components: BlackBerry Affects Versions: 3.3.0 Reporter: Bryan Higgins Assignee: Josh Soref Priority: Blocker CB-5443 introduced a change to init.bat which breaks the platform for some Windows users. Specifically, if they have (x86) somewhere in their path it will fail to parse the file. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CB-5922) 3.4 translation - Chinese Simplified
Lisa Seacat DeLuca created CB-5922: -- Summary: 3.4 translation - Chinese Simplified Key: CB-5922 URL: https://issues.apache.org/jira/browse/CB-5922 Project: Apache Cordova Issue Type: Improvement Components: Translation Affects Versions: 3.4.0 Reporter: Lisa Seacat DeLuca Assignee: Lisa Seacat DeLuca Priority: Minor Translate cordova 3.4 docs into Simplified Chinese -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CB-5923) 3.4 Translation for Spanish
Lisa Seacat DeLuca created CB-5923: -- Summary: 3.4 Translation for Spanish Key: CB-5923 URL: https://issues.apache.org/jira/browse/CB-5923 Project: Apache Cordova Issue Type: Improvement Components: Translation Affects Versions: 3.4.0 Reporter: Lisa Seacat DeLuca Assignee: Lisa Seacat DeLuca Priority: Minor -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CB-5924) 3.4 Translation for French
Lisa Seacat DeLuca created CB-5924: -- Summary: 3.4 Translation for French Key: CB-5924 URL: https://issues.apache.org/jira/browse/CB-5924 Project: Apache Cordova Issue Type: Improvement Components: Translation Affects Versions: 3.4.0 Reporter: Lisa Seacat DeLuca Assignee: Lisa Seacat DeLuca Priority: Minor -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CB-5926) 3.4 Translation for Italian
Lisa Seacat DeLuca created CB-5926: -- Summary: 3.4 Translation for Italian Key: CB-5926 URL: https://issues.apache.org/jira/browse/CB-5926 Project: Apache Cordova Issue Type: Improvement Components: Translation Affects Versions: 3.4.0 Reporter: Lisa Seacat DeLuca Assignee: Lisa Seacat DeLuca Priority: Minor -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CB-5927) 3.4 Translation for Japanese
Lisa Seacat DeLuca created CB-5927: -- Summary: 3.4 Translation for Japanese Key: CB-5927 URL: https://issues.apache.org/jira/browse/CB-5927 Project: Apache Cordova Issue Type: Improvement Components: Translation Affects Versions: 3.4.0 Reporter: Lisa Seacat DeLuca Assignee: Lisa Seacat DeLuca Priority: Minor -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CB-5925) 3.4 Translation for German
Lisa Seacat DeLuca created CB-5925: -- Summary: 3.4 Translation for German Key: CB-5925 URL: https://issues.apache.org/jira/browse/CB-5925 Project: Apache Cordova Issue Type: Improvement Components: Translation Affects Versions: 3.4.0 Reporter: Lisa Seacat DeLuca Assignee: Lisa Seacat DeLuca Priority: Minor -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CB-5928) 3.4 Translation for Chinese Traditional
Lisa Seacat DeLuca created CB-5928: -- Summary: 3.4 Translation for Chinese Traditional Key: CB-5928 URL: https://issues.apache.org/jira/browse/CB-5928 Project: Apache Cordova Issue Type: Improvement Components: Translation Affects Versions: 3.4.0 Reporter: Lisa Seacat DeLuca Assignee: Lisa Seacat DeLuca Priority: Minor -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CB-5929) 3.4 Translation for Russian
Lisa Seacat DeLuca created CB-5929: -- Summary: 3.4 Translation for Russian Key: CB-5929 URL: https://issues.apache.org/jira/browse/CB-5929 Project: Apache Cordova Issue Type: Improvement Components: Translation Affects Versions: 3.4.0 Reporter: Lisa Seacat DeLuca Assignee: Lisa Seacat DeLuca Priority: Minor -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CB-5931) 3.4 Translation for Korean
Lisa Seacat DeLuca created CB-5931: -- Summary: 3.4 Translation for Korean Key: CB-5931 URL: https://issues.apache.org/jira/browse/CB-5931 Project: Apache Cordova Issue Type: Improvement Components: Translation Affects Versions: 3.4.0 Reporter: Lisa Seacat DeLuca Assignee: Lisa Seacat DeLuca Priority: Minor -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CB-5930) 3.4 Translation for Slovenian
Lisa Seacat DeLuca created CB-5930: -- Summary: 3.4 Translation for Slovenian Key: CB-5930 URL: https://issues.apache.org/jira/browse/CB-5930 Project: Apache Cordova Issue Type: Improvement Components: Translation Affects Versions: 3.4.0 Reporter: Lisa Seacat DeLuca Assignee: Lisa Seacat DeLuca Priority: Minor -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CB-5018) bin/create on iOS should use --arc by default
[ https://issues.apache.org/jira/browse/CB-5018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13884747#comment-13884747 ] Shazron Abdullah commented on CB-5018: -- Agreed, ARC should be the default now, let's remove it. Plugins have a declarative way of specifying non-arc compilation for source files so its not a problem bin/create on iOS should use --arc by default - Key: CB-5018 URL: https://issues.apache.org/jira/browse/CB-5018 Project: Apache Cordova Issue Type: Bug Components: iOS Reporter: Andrew Grieve Assignee: Shazron Abdullah Labels: core CLI uses --arc by default, and plugins assume --arc, so it really should be the default. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (CB-5854) [Release + 3.4.0] Parent Issue
[ https://issues.apache.org/jira/browse/CB-5854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Gill reassigned CB-5854: -- Assignee: Steve Gill (was: Jesse MacFadyen) [Release + 3.4.0] Parent Issue -- Key: CB-5854 URL: https://issues.apache.org/jira/browse/CB-5854 Project: Apache Cordova Issue Type: Task Components: Amazon FireOS, Android, App Hello World, BlackBerry, CLI, CordovaJS, Docs, FirefoxOS, iOS, mobile-spec, Ubuntu, Windows 8, WP8 Reporter: Steve Gill Assignee: Steve Gill Fix For: 3.4.0 Parent bug for the 3.4.0 Cordova Release. Workflow here: http://wiki.apache.org/cordova/CuttingReleases Release Master: ? Component Leads: Refer to assignee of Test Tag sub-tasks. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CB-5920) android:installLocation=preferExternal
[ https://issues.apache.org/jira/browse/CB-5920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13884780#comment-13884780 ] Joe Bowser commented on CB-5920: Oh yeah, we only support phones that are 2.3.0 and above for Android. android:installLocation=preferExternal Key: CB-5920 URL: https://issues.apache.org/jira/browse/CB-5920 Project: Apache Cordova Issue Type: Improvement Components: Android, CLI Environment: Phones with 512 Ram Reporter: cesine Labels: patch I created a PR on github suggesting to add preferExternal https://github.com/apache/cordova-android/pull/91#issuecomment-33513325 for phones with small amounts of internal storage (512MB and even 1GB, android 2.2 and 2.3 and even some 4.0) the user wont be able to install the app (or keep it) unless you let them put it on the sdcard instead of the internal phone storage. Very few cordova apps are the kind of app which shouldn't be on external storage. more details: http://developer.android.com/guide/topics/data/install-location.html#Should -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CB-5920) android:installLocation=preferExternal
[ https://issues.apache.org/jira/browse/CB-5920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13884779#comment-13884779 ] Joe Bowser commented on CB-5920: I don't ever remember hearing of this problem until now. But yeah, the reason I asked for this to be added to JIRA is because I think this should be exposed to the CLI for the reasons you just mentioned, because Cordova users who don't know much Android will most likely be using the CLI (even though I don't). android:installLocation=preferExternal Key: CB-5920 URL: https://issues.apache.org/jira/browse/CB-5920 Project: Apache Cordova Issue Type: Improvement Components: Android, CLI Environment: Phones with 512 Ram Reporter: cesine Labels: patch I created a PR on github suggesting to add preferExternal https://github.com/apache/cordova-android/pull/91#issuecomment-33513325 for phones with small amounts of internal storage (512MB and even 1GB, android 2.2 and 2.3 and even some 4.0) the user wont be able to install the app (or keep it) unless you let them put it on the sdcard instead of the internal phone storage. Very few cordova apps are the kind of app which shouldn't be on external storage. more details: http://developer.android.com/guide/topics/data/install-location.html#Should -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CB-5920) android:installLocation=preferExternal
[ https://issues.apache.org/jira/browse/CB-5920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Bowser updated CB-5920: --- Component/s: CLI android:installLocation=preferExternal Key: CB-5920 URL: https://issues.apache.org/jira/browse/CB-5920 Project: Apache Cordova Issue Type: Improvement Components: Android, CLI Environment: Phones with 512 Ram Reporter: cesine Labels: patch I created a PR on github suggesting to add preferExternal https://github.com/apache/cordova-android/pull/91#issuecomment-33513325 for phones with small amounts of internal storage (512MB and even 1GB, android 2.2 and 2.3 and even some 4.0) the user wont be able to install the app (or keep it) unless you let them put it on the sdcard instead of the internal phone storage. Very few cordova apps are the kind of app which shouldn't be on external storage. more details: http://developer.android.com/guide/topics/data/install-location.html#Should -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CB-4984) Can't name my class CordovaActivity
[
https://issues.apache.org/jira/browse/CB-4984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Bowser resolved CB-4984.
Resolution: Fixed
Assignee: Joe Bowser
Looks good, accepting the patch!
Can't name my class CordovaActivity
---
Key: CB-4984
URL: https://issues.apache.org/jira/browse/CB-4984
Project: Apache Cordova
Issue Type: Bug
Components: Android
Affects Versions: 3.1.0
Environment: android sdk tools 22.2.1
android sdk platform-tools 18.0.1
Android 4.3 (API 18)
Reporter: Anis Kadri
Assignee: Joe Bowser
Priority: Minor
Fix For: 3.4.0
Yes it's super silly but the node create script should fail if user enters
in: CordovaActivity as an activity name since we inherit from a class that
has that name. Might also apply to package names.
steps to reproduce
{code}
./bin/create /path/to/project mypackage.name CordovaActivity
{code}
Results:
{code}
-compile:
[javac] Compiling 6 source files to /private/tmp/android/bin/classes
[javac] /private/tmp/android/src/io/cordova/CordovaActivity.java:25:
cyclic inheritance involving io.cordova.CordovaActivity
[javac] public class CordovaActivity extends CordovaActivity
[javac]^
[javac] 1 error
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (CB-5908) Splashscreen docs are conflicting
[ https://issues.apache.org/jira/browse/CB-5908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Bowser updated CB-5908: --- Component/s: (was: Android) Docs Priority: Minor (was: Major) Splashscreen docs are conflicting - Key: CB-5908 URL: https://issues.apache.org/jira/browse/CB-5908 Project: Apache Cordova Issue Type: Bug Components: Docs Affects Versions: 3.3.0 Reporter: John M. Wargo Priority: Minor the documentation her: http://cordova.apache.org/docs/en/3.3.0/config_ref_images.md.html#Icons%20and%20Splash%20Screens is inaccurate. The res folder was dropped in a previous version of the CLI, but the instructions still say to copy the files from the res folder. the instructions also say that you want to copy the files to screen.png, but what follows those instructions says you want to set the files to splash. The two are in conflict. Later it mentions to change it to screen, but why tell me screen then splash then tell me to change splash to screen? Lastly, it tells me I need to add some settings to the config.xml, but which of the three config.xml files? It says the project's www folder, and I'm assuming that's the high level www folder, but these are Android-specific settings, so what happens with them on other platforms? this is all really unclear. Here's the sections from the docs: If you want to use the default splash screen images provided in Cordova, you'll need to copy the png files from platforms/android/www/res/screen/android to platforms/android/res/drawable*/: cd platforms/android/res mkdir drawable-port-ldpi cp -p ../assets/www/res/screen/android/screen-ldpi-portrait.png drawable-port-ldpi/screen.png mkdir drawable-land-ldpi cp -p ../assets/www/res/screen/android/screen-ldpi-landscape.png drawable-land-ldpi/screen.png mkdir drawable-port-mdpi cp -p ../assets/www/res/screen/android/screen-mdpi-portrait.png drawable-port-mdpi/screen.png mkdir drawable-land-mdpi cp -p ../assets/www/res/screen/android/screen-mdpi-landscape.png drawable-land-mdpi/screen.png mkdir drawable-port-hdpi cp -p ../assets/www/res/screen/android/screen-hdpi-portrait.png drawable-port-hdpi/screen.png mkdir drawable-land-hdpi cp -p ../assets/www/res/screen/android/screen-hdpi-landscape.png drawable-land-hdpi/screen.png mkdir drawable-port-xhdpi cp -p ../assets/www/res/screen/android/screen-xhdpi-portrait.png drawable-port-xhdpi/screen.png mkdir drawable-land-xhdpi cp -p ../assets/www/res/screen/android/screen-xhdpi-landscape.png drawable-land-xhdpi/screen.png The drawable directory names must follow the Android conventions for supporting screen sizes and alternate resources. In config.xml in the project's www directory, add the following preferences: preference name=SplashScreen value=splash / preference name=SplashScreenDelay value=1 / -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CB-4984) Can't name my class CordovaActivity
[
https://issues.apache.org/jira/browse/CB-4984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13884789#comment-13884789
]
ASF subversion and git services commented on CB-4984:
-
Commit 438a8d8b75ce4fb2656c9f2698ceb563134c22df in branch refs/heads/master
from [~BBosman]
[ https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;h=438a8d8 ]
CB-4984 Don't create on CordovaActivity name
Can't name my class CordovaActivity
---
Key: CB-4984
URL: https://issues.apache.org/jira/browse/CB-4984
Project: Apache Cordova
Issue Type: Bug
Components: Android
Affects Versions: 3.1.0
Environment: android sdk tools 22.2.1
android sdk platform-tools 18.0.1
Android 4.3 (API 18)
Reporter: Anis Kadri
Assignee: Joe Bowser
Priority: Minor
Fix For: 3.4.0
Yes it's super silly but the node create script should fail if user enters
in: CordovaActivity as an activity name since we inherit from a class that
has that name. Might also apply to package names.
steps to reproduce
{code}
./bin/create /path/to/project mypackage.name CordovaActivity
{code}
Results:
{code}
-compile:
[javac] Compiling 6 source files to /private/tmp/android/bin/classes
[javac] /private/tmp/android/src/io/cordova/CordovaActivity.java:25:
cyclic inheritance involving io.cordova.CordovaActivity
[javac] public class CordovaActivity extends CordovaActivity
[javac]^
[javac] 1 error
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (CB-5860) [Release + 3.4.0] Branch Test Tag RC1 for Windows Phone 7 8
[ https://issues.apache.org/jira/browse/CB-5860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse MacFadyen resolved CB-5860. - Resolution: Fixed [Release + 3.4.0] Branch Test Tag RC1 for Windows Phone 7 8 - Key: CB-5860 URL: https://issues.apache.org/jira/browse/CB-5860 Project: Apache Cordova Issue Type: Sub-task Components: WP8 Reporter: Steve Gill Assignee: Jesse MacFadyen Fix For: 3.4.0 Refer to Workflow here: http://wiki.apache.org/cordova/CuttingReleases -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CB-5921) Cordova on iOS should use an XCWorkspace, or at least support using one.
[ https://issues.apache.org/jira/browse/CB-5921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shazron Abdullah updated CB-5921: - Issue Type: Wish (was: Bug) Cordova on iOS should use an XCWorkspace, or at least support using one. Key: CB-5921 URL: https://issues.apache.org/jira/browse/CB-5921 Project: Apache Cordova Issue Type: Wish Components: iOS Reporter: Graham Mueller Priority: Minor Labels: core Hi Guys, Not sure what to log this as. It's not so much a bug as an incompatibility with other frameworks. Anyway, this is specifically an issue with the build process on iOS. Do with it what you will. If you're familiar with the CocoaPods framework, you'll know that on initial install, it creates an XCWorkspace file, and instructs you to exclusively use that afterwards. This is because the CocoaPods library adds itself as a linked project that must be built, similar to Cordova/Phonegap. The difference is that Cordova adds itself as a sub project, instead of a sibling project (which is effectively the workspace goal, from my understanding, though I'm having a hard time finding a good link to explain it better). So, I would suggest that Cordova moves to this setup as well -- it should create the workspace that has both the Cordova project and your app project. Alternatively, if you don't want to go through and change that creation code, it would be great if the CLI offered someway to specify what you want it to build. I found the actual build script that's calling xcodebuild with a -project flag in it (this is where -workspace would go). There is currently no way to override this, so there is currently no way at all to support workspaces (and consequently no way to use CocoaPods). Any thoughts or reasons not to do so? Thanks, Graham -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CB-5921) Cordova on iOS should use an XCWorkspace, or at least support using one.
[ https://issues.apache.org/jira/browse/CB-5921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shazron Abdullah updated CB-5921: - Priority: Minor (was: Major) Cordova on iOS should use an XCWorkspace, or at least support using one. Key: CB-5921 URL: https://issues.apache.org/jira/browse/CB-5921 Project: Apache Cordova Issue Type: Bug Components: iOS Reporter: Graham Mueller Priority: Minor Labels: core Hi Guys, Not sure what to log this as. It's not so much a bug as an incompatibility with other frameworks. Anyway, this is specifically an issue with the build process on iOS. Do with it what you will. If you're familiar with the CocoaPods framework, you'll know that on initial install, it creates an XCWorkspace file, and instructs you to exclusively use that afterwards. This is because the CocoaPods library adds itself as a linked project that must be built, similar to Cordova/Phonegap. The difference is that Cordova adds itself as a sub project, instead of a sibling project (which is effectively the workspace goal, from my understanding, though I'm having a hard time finding a good link to explain it better). So, I would suggest that Cordova moves to this setup as well -- it should create the workspace that has both the Cordova project and your app project. Alternatively, if you don't want to go through and change that creation code, it would be great if the CLI offered someway to specify what you want it to build. I found the actual build script that's calling xcodebuild with a -project flag in it (this is where -workspace would go). There is currently no way to override this, so there is currently no way at all to support workspaces (and consequently no way to use CocoaPods). Any thoughts or reasons not to do so? Thanks, Graham -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CB-5921) Cordova on iOS should use an XCWorkspace, or at least support using one.
[ https://issues.apache.org/jira/browse/CB-5921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shazron Abdullah updated CB-5921: - Labels: core (was: ) Cordova on iOS should use an XCWorkspace, or at least support using one. Key: CB-5921 URL: https://issues.apache.org/jira/browse/CB-5921 Project: Apache Cordova Issue Type: Bug Components: iOS Reporter: Graham Mueller Labels: core Hi Guys, Not sure what to log this as. It's not so much a bug as an incompatibility with other frameworks. Anyway, this is specifically an issue with the build process on iOS. Do with it what you will. If you're familiar with the CocoaPods framework, you'll know that on initial install, it creates an XCWorkspace file, and instructs you to exclusively use that afterwards. This is because the CocoaPods library adds itself as a linked project that must be built, similar to Cordova/Phonegap. The difference is that Cordova adds itself as a sub project, instead of a sibling project (which is effectively the workspace goal, from my understanding, though I'm having a hard time finding a good link to explain it better). So, I would suggest that Cordova moves to this setup as well -- it should create the workspace that has both the Cordova project and your app project. Alternatively, if you don't want to go through and change that creation code, it would be great if the CLI offered someway to specify what you want it to build. I found the actual build script that's calling xcodebuild with a -project flag in it (this is where -workspace would go). There is currently no way to override this, so there is currently no way at all to support workspaces (and consequently no way to use CocoaPods). Any thoughts or reasons not to do so? Thanks, Graham -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CB-5921) Cordova on iOS should use an XCWorkspace, or at least support using one.
[ https://issues.apache.org/jira/browse/CB-5921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shazron Abdullah updated CB-5921: - Component/s: (was: CLI) Cordova on iOS should use an XCWorkspace, or at least support using one. Key: CB-5921 URL: https://issues.apache.org/jira/browse/CB-5921 Project: Apache Cordova Issue Type: Bug Components: iOS Reporter: Graham Mueller Labels: core Hi Guys, Not sure what to log this as. It's not so much a bug as an incompatibility with other frameworks. Anyway, this is specifically an issue with the build process on iOS. Do with it what you will. If you're familiar with the CocoaPods framework, you'll know that on initial install, it creates an XCWorkspace file, and instructs you to exclusively use that afterwards. This is because the CocoaPods library adds itself as a linked project that must be built, similar to Cordova/Phonegap. The difference is that Cordova adds itself as a sub project, instead of a sibling project (which is effectively the workspace goal, from my understanding, though I'm having a hard time finding a good link to explain it better). So, I would suggest that Cordova moves to this setup as well -- it should create the workspace that has both the Cordova project and your app project. Alternatively, if you don't want to go through and change that creation code, it would be great if the CLI offered someway to specify what you want it to build. I found the actual build script that's calling xcodebuild with a -project flag in it (this is where -workspace would go). There is currently no way to override this, so there is currently no way at all to support workspaces (and consequently no way to use CocoaPods). Any thoughts or reasons not to do so? Thanks, Graham -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CB-2421) On Windows 8 , FileTransfer.upload returns wrong FileUploadResult
[
https://issues.apache.org/jira/browse/CB-2421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13884821#comment-13884821
]
Jesse MacFadyen commented on CB-2421:
-
A similar pull request is here:
https://github.com/TNKSoftware/cordova-windows/commit/f0cf26a1624a83dcff6fbfb4cede6a6feff8c160
Although that attempts to modify cordova.js directly, which will not work.
On Windows 8 , FileTransfer.upload returns wrong FileUploadResult
-
Key: CB-2421
URL: https://issues.apache.org/jira/browse/CB-2421
Project: Apache Cordova
Issue Type: Bug
Components: Plugin File Transfer, Windows 8
Affects Versions: 2.4.0
Reporter: Youval Bronicki
Assignee: Jesse MacFadyen
When reporting success, the existing code attempts to read the original file
as a string and report it as a response (instead of the server's response).
It also calls a non-existent constructor new
FileUploadResult(basicProperties.size, code, fileContent).
When the uploaded file is not textual (e.g. a JPEG image), the current code
fails altogether because dataReader.readString throws an exception.
Here is a possible correction:
*Old Code:*
storageFile.getBasicPropertiesAsync().done(function (basicProperties) {
Windows.Storage.FileIO.readBufferAsync(storageFile).done(function (buffer)
{
var dataReader = Windows.Storage.Streams.DataReader.fromBuffer(buffer);
var fileContent = dataReader.readString(buffer.length);
dataReader.close();
win(new FileUploadResult(basicProperties.size, code, fileContent));
});
}, function () {
error(FileTransferError.INVALID_URL_ERR);
});
*Correction:*
storageFile.getBasicPropertiesAsync().done(function (basicProperties) {
var res = new FileUploadResult();
res.bytesSent=basicProperties.size;
res.responseCode=response.status;
res.response=response.responseText;
win(res);
});
Possible a more elegant correction would be to add the missing constructor
for FileUploadResult
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (CB-5921) Cordova on iOS should use an XCWorkspace, or at least support using one.
[ https://issues.apache.org/jira/browse/CB-5921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shazron Abdullah updated CB-5921: - Issue Type: Improvement (was: Wish) Cordova on iOS should use an XCWorkspace, or at least support using one. Key: CB-5921 URL: https://issues.apache.org/jira/browse/CB-5921 Project: Apache Cordova Issue Type: Improvement Components: iOS Reporter: Graham Mueller Priority: Minor Labels: core Hi Guys, Not sure what to log this as. It's not so much a bug as an incompatibility with other frameworks. Anyway, this is specifically an issue with the build process on iOS. Do with it what you will. If you're familiar with the CocoaPods framework, you'll know that on initial install, it creates an XCWorkspace file, and instructs you to exclusively use that afterwards. This is because the CocoaPods library adds itself as a linked project that must be built, similar to Cordova/Phonegap. The difference is that Cordova adds itself as a sub project, instead of a sibling project (which is effectively the workspace goal, from my understanding, though I'm having a hard time finding a good link to explain it better). So, I would suggest that Cordova moves to this setup as well -- it should create the workspace that has both the Cordova project and your app project. Alternatively, if you don't want to go through and change that creation code, it would be great if the CLI offered someway to specify what you want it to build. I found the actual build script that's calling xcodebuild with a -project flag in it (this is where -workspace would go). There is currently no way to override this, so there is currently no way at all to support workspaces (and consequently no way to use CocoaPods). Any thoughts or reasons not to do so? Thanks, Graham -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CB-2421) On Windows 8 , FileTransfer.upload returns wrong FileUploadResult
[
https://issues.apache.org/jira/browse/CB-2421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13884904#comment-13884904
]
ASF subversion and git services commented on CB-2421:
-
Commit be44194066f20b1b927608005f76afb7d11994d6 in branch refs/heads/dev from
[~purplecabbage]
[
https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-file-transfer.git;h=be44194
]
CB-2421 explicitly write the bytesSent,responseCode,result to the
FileUploadResult pending release of cordova-plugin-file dependency, added some
sanity checks for callbacks
On Windows 8 , FileTransfer.upload returns wrong FileUploadResult
-
Key: CB-2421
URL: https://issues.apache.org/jira/browse/CB-2421
Project: Apache Cordova
Issue Type: Bug
Components: Plugin File Transfer, Windows 8
Affects Versions: 2.4.0
Reporter: Youval Bronicki
Assignee: Jesse MacFadyen
When reporting success, the existing code attempts to read the original file
as a string and report it as a response (instead of the server's response).
It also calls a non-existent constructor new
FileUploadResult(basicProperties.size, code, fileContent).
When the uploaded file is not textual (e.g. a JPEG image), the current code
fails altogether because dataReader.readString throws an exception.
Here is a possible correction:
*Old Code:*
storageFile.getBasicPropertiesAsync().done(function (basicProperties) {
Windows.Storage.FileIO.readBufferAsync(storageFile).done(function (buffer)
{
var dataReader = Windows.Storage.Streams.DataReader.fromBuffer(buffer);
var fileContent = dataReader.readString(buffer.length);
dataReader.close();
win(new FileUploadResult(basicProperties.size, code, fileContent));
});
}, function () {
error(FileTransferError.INVALID_URL_ERR);
});
*Correction:*
storageFile.getBasicPropertiesAsync().done(function (basicProperties) {
var res = new FileUploadResult();
res.bytesSent=basicProperties.size;
res.responseCode=response.status;
res.response=response.responseText;
win(res);
});
Possible a more elegant correction would be to add the missing constructor
for FileUploadResult
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (CB-4609) relative path to cordova.js windows path
[
https://issues.apache.org/jira/browse/CB-4609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Bond updated CB-4609:
--
Attachment: (was: snap.png)
relative path to cordova.js windows path
--
Key: CB-4609
URL: https://issues.apache.org/jira/browse/CB-4609
Project: Apache Cordova
Issue Type: Bug
Components: CLI, Plugman
Affects Versions: 3.0.0
Environment: Window 8, node v0.10.16
Reporter: Jonathan Bond
Assignee: Anis Kadri
Attachments: Result of 'plugin add'.jpg
I'm experimenting with a new plugin:
https://github.com/jbondc/cordova-plugin-gesture
To reproduce:
- Download https://github.com/jbondc/mtlhack-PhoneGap-gesture
1) Issue #1
{code}
cd cordova
plugin add https://github.com/jbondc/cordova-plugin-gesture
{code}
Since cordova.js isn't in the default path (www/resources/cordova.js), the
plugins gets copied to (www/plugins/) instead of (www/resources/js/plugins).
The same for 'cordova_plugins.js' (see attached screenshot)
Fix is likely in the cli/plugman to set find the appropriate root/base path
to cordova.js
2) Issue #2
Adding a plugin from a Windows path
{code}
cordova plugin add F:\Jonathan\GitHub\Cordova\cordova-plugin-gesture
{code}
In cordova_plugins.js, I see:
{code}
cordova.define('cordova/plugin_list', function(require, exports, module) {
module.exports = [
{
file: plugins\\org.apache.cordova.core.Gesture\\www\\gesture.js,
id: org.apache.cordova.core.Gesture.Gesture,
clobbers: [
cordova.gesture
]
}
]
});
{code}
That path should be normalized to:
plugins/org.apache.cordova.core.Gesture/www/gesture.js
Fix is likely in cli/plugman:
{code}path.replace(\\, /){code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (CB-5703) WP8 FileTransfer can't download file with not exsit Parent directory path as targetPath
[ https://issues.apache.org/jira/browse/CB-5703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse MacFadyen resolved CB-5703. - Resolution: Invalid Assignee: Jesse MacFadyen CB-339 This is actually part of the spec, and the expected behaviour WP8 FileTransfer can't download file with not exsit Parent directory path as targetPath --- Key: CB-5703 URL: https://issues.apache.org/jira/browse/CB-5703 Project: Apache Cordova Issue Type: Bug Components: Plugin File Transfer Environment: wp8 Reporter: puchen Assignee: Jesse MacFadyen for example: use wp8 fileTransfer download file, target path : /Download/targetFile.zip, parent directory 'Download' not exsit, save file occured an exception! it need create parent directory,before save file! download file save file with targetpath, parent directory maybe need create, if directory not exist! -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CB-5932) Please delete old releases from mirroring system
Sebb created CB-5932: Summary: Please delete old releases from mirroring system Key: CB-5932 URL: https://issues.apache.org/jira/browse/CB-5932 Project: Apache Cordova Issue Type: Bug Affects Versions: 2.9.1 Reporter: Sebb To reduce the load on the ASF mirrors, projects are required to delete old releases [1] Please can you remove all non-current releases? Thanks! [1] http://www.apache.org/dev/release.html#when-to-archive -- This message was sent by Atlassian JIRA (v6.1.5#6160)
