[jira] [Commented] (CB-6481) Add unified hooks support for cordova app and plugins
[ https://issues.apache.org/jira/browse/CB-6481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14058512#comment-14058512 ] ASF GitHub Bot commented on CB-6481: Github user sgrebnov commented on the pull request: https://github.com/apache/cordova-lib/pull/55#issuecomment-48701880 Addressed docs review notes: deprecated .cordova/hooks directory Add unified hooks support for cordova app and plugins - Key: CB-6481 URL: https://issues.apache.org/jira/browse/CB-6481 Project: Apache Cordova Issue Type: New Feature Components: CLI, Plugman Reporter: Sergey Grebnov Assignee: Sergey Grebnov As per Proposal: hooks support for plugins dev mail thread discussion Hi, I have an idea how we can add more flexibility to plugin developers. Note, right now we have Application Developers – someone who use Cordova for developing applications and Plugin Developers – someone who creates plugins so that Application Developers can use them. For Application Developers we expose hooks so that they can customize their build/package/etc process. I want us to provide similar sort of flexibility to Plugin Developers so that they can go beyond of source/, framework/ tags and get mechanism to add custom installation, build logic required by a plugin. Example usage will include: downloading/compiling additional binaries, marking source file to be copied to output dir, changing target build platform, etc. At present time the steps described could be only achieved by hooks manually added by Application Developer, but the right way is to allow Plugin Developer to expose this as part of plugin definition. Example configuration could look like ``` script type=postinstall src=scripts/postinstall.js / script type=preinstall src=scripts/preinstall.js / script type=install src=scripts/install.js / ``` beforeinstall/preinstall – run before plugin is installed install/postinstall/afterinstall – run after plugin is installed uninstall – run after plugin is uninstalled -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-6728) Support chip architecture as an option when building Windows and Windows Phone projects
[
https://issues.apache.org/jira/browse/CB-6728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14058617#comment-14058617
]
Zizhou L commented on CB-6728:
--
Hi,
Any updates on iOS support for this:
cordova build ios -archs=armv7 arm64
Support chip architecture as an option when building Windows and Windows
Phone projects
---
Key: CB-6728
URL: https://issues.apache.org/jira/browse/CB-6728
Project: Apache Cordova
Issue Type: Improvement
Components: Android, CLI, iOS, Windows 8, WP8
Affects Versions: 3.4.0
Reporter: Vladimir Kotikov
Assignee: Jesse MacFadyen
Labels: arm, cli, windows, wp8, x64, x86
Currently apps for Windows 8 and Windows Phone 8 are targeted to AnyCPU
architecture, which is universal, but sometimes it's critical to build
application for specific processor architecture.
As an example is WebSQL plugin which contains references to C++ libs so needs
to be built for specific architecture (x84, x64, ARM) and which does not
support AnyCPU target.
So it looks important to add support for additional build flags `-x64`,
`-x86`, `-arm`, '-any' to specify target chip architecture.
{noformat}
cordova build windows8 --release --x64
cordova build wp8 --arm
{noformat}
If flag is not specified, `AnuCPU` target platform should be used by default.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CB-7122) Camera Plugin auto rotation does not work with PNG images on Android
Michael M created CB-7122: - Summary: Camera Plugin auto rotation does not work with PNG images on Android Key: CB-7122 URL: https://issues.apache.org/jira/browse/CB-7122 Project: Apache Cordova Issue Type: Bug Components: Android, CordovaLib, Plugin Camera Affects Versions: 3.5.0 Environment: Cordova 3.5.0-0.2.4 Camera plugin 0.3.0 Android Reporter: Michael M Priority: Critical When using Android and image as PNG from Camera auto rotation does not work even if it is set to true. This is a bug. It works fine on iOS. It works on Android if you use JPEG images from Camera but not with PNG images. Tested on Samsung Galaxy S3 mini. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-5114) Windows 8.1 - Use a new proxy as old geolocation methods is deprecated
[ https://issues.apache.org/jira/browse/CB-5114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14058701#comment-14058701 ] ASF GitHub Bot commented on CB-5114: GitHub user sgrebnov opened a pull request: https://github.com/apache/cordova-plugin-geolocation/pull/18 CB- 5114 Windows 8.1 - Use a new proxy as old geolocation methods is deprecated https://issues.apache.org/jira/browse/CB-5114 * Tested on Windows 8.0, Windows 8.1, Windows Phone 8.1 * There are 'windows8' and 'windows' sections which are totally equal. This is done by design so that we can deprecate 'windows8' section in the future You can merge this pull request into a Git repository by running: $ git pull https://github.com/sgrebnov/cordova-plugin-geolocation CB-5114 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-plugin-geolocation/pull/18.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 #18 commit e9eaa78a9016783a1f8576c88e3cbda943bf5e3b Author: SomaticIT cont...@somatic.fr Date: 2013-10-17T10:45:40Z CB-5114 Append Windows 8.1 into plugin.xml + Optimize Windows 8 Geolocation proxy commit c1bcd6b6fe808079bd8891c063bf037fb4934506 Author: sgrebnov v-seg...@microsoft.com Date: 2014-07-11T12:02:30Z CB-5114 Windows 8.1 - Use a new proxy as old geolocation methods is deprecated * Added separate section for Windows Univeral Apps * Made GeolocationProxy compatible with windows8.0 and 8.1 api versions Windows 8.1 - Use a new proxy as old geolocation methods is deprecated -- Key: CB-5114 URL: https://issues.apache.org/jira/browse/CB-5114 Project: Apache Cordova Issue Type: Sub-task Components: Plugin Geolocation, Windows 8 Reporter: Maxime LUCE Assignee: Sergey Grebnov In WinJS 2.0 : Geolocation.Geocoordinate.Latitude, Longitude, Altitude has been replaced by Geolocation.Geopoint.Position.Latitude, ... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-5114) Windows 8.1 - Use a new proxy as old geolocation methods is deprecated
[ https://issues.apache.org/jira/browse/CB-5114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14058703#comment-14058703 ] Sergey Grebnov commented on CB-5114: Rebased, added minor corrections, tested and sent PR https://github.com/apache/cordova-plugin-geolocation/pull/18 Thx, Maxime! Please let me know if the PR looks good to you Windows 8.1 - Use a new proxy as old geolocation methods is deprecated -- Key: CB-5114 URL: https://issues.apache.org/jira/browse/CB-5114 Project: Apache Cordova Issue Type: Sub-task Components: Plugin Geolocation, Windows 8 Reporter: Maxime LUCE Assignee: Sergey Grebnov In WinJS 2.0 : Geolocation.Geocoordinate.Latitude, Longitude, Altitude has been replaced by Geolocation.Geopoint.Position.Latitude, ... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-6481) Add unified hooks support for cordova app and plugins
[
https://issues.apache.org/jira/browse/CB-6481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14058776#comment-14058776
]
ASF GitHub Bot commented on CB-6481:
Github user kamrik commented on a diff in the pull request:
https://github.com/apache/cordova-lib/pull/55#discussion_r14820487
--- Diff: cordova-lib/src/hooks/ScriptsFinder.js ---
@@ -0,0 +1,158 @@
+/**
+ Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information
+ regarding copyright ownership. The ASF licenses this file
+ to you under the Apache License, Version 2.0 (the
+ License); you may not use this file except in compliance
+ with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing,
+ software distributed under the License is distributed on an
+ AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ KIND, either express or implied. See the License for the
+ specific language governing permissions and limitations
+ under the License.
+ */
+
+var path = require('path'),
+fs = require('fs'),
+cordovaUtil = require('../cordova/util'),
+events = require('../events'),
+Q = require('q'),
+plugin = require('../cordova/plugin'),
+PluginInfo = require('../PluginInfo'),
+ConfigParser = require('../configparser/ConfigParser'),
+CordovaError = require('../CordovaError'),
+Context = require('./Context');
+
+/**
+ * Implements logic to retrieve hook script files defined in special
folders and configuration
+ * files: config.xml, hooks/hook_type, plugins/../plugin.xml, etc
+ */
+module.exports = {
+/**
+ * Returns all script files for the hook type specified.
+ */
+getHookScripts: function(hook, opts) {
+// args check
+if (!hook) {
+throw new CordovaError('hook type is not specified');
+}
+return getApplicationHookScripts(hook, opts)
+.concat(getPluginsHookScripts(hook, opts));
+}
+};
+
+/**
+ * Returns script files defined on application level.
+ * They are stored in .cordova/hooks folders and in config.xml.
+ */
+function getApplicationHookScripts(hook, opts) {
+// args check
+if (!hook) {
+throw new CordovaError('hook type is not specified');
+}
+return getApplicationHookScriptsFromDir(path.join(opts.projectRoot,
'.cordova', 'hooks', hook))
+
.concat(getApplicationHookScriptsFromDir(path.join(opts.projectRoot, 'hooks',
hook)))
+.concat(getScriptsFromConfigXml(hook, opts));
+}
+
+/**
+ * Returns script files defined by plugin developers as part of plugin.xml.
+ */
+function getPluginsHookScripts(hook, opts) {
+// args check
+if (!hook) {
+throw new CordovaError('hook type is not specified');
--- End diff --
I think this should be Error rather than CordovaError. If we get here, it
means something went very wrong, probably it's a but, not a case of bad user
input or other problems we expect to happen occasionally.
Add unified hooks support for cordova app and plugins
-
Key: CB-6481
URL: https://issues.apache.org/jira/browse/CB-6481
Project: Apache Cordova
Issue Type: New Feature
Components: CLI, Plugman
Reporter: Sergey Grebnov
Assignee: Sergey Grebnov
As per Proposal: hooks support for plugins dev mail thread discussion
Hi, I have an idea how we can add more flexibility to plugin developers.
Note, right now we have Application Developers – someone who use Cordova for
developing applications and Plugin Developers – someone who creates plugins
so that Application Developers can use them. For Application Developers we
expose hooks so that they can customize their build/package/etc process. I
want us to provide similar sort of flexibility to Plugin Developers so that
they can go beyond of source/, framework/ tags and get mechanism to add
custom installation, build logic required by a plugin. Example usage will
include: downloading/compiling additional binaries, marking source file to be
copied to output dir, changing target build platform, etc. At present time
the steps described could be only achieved by hooks manually added by
Application Developer, but the right way is to allow Plugin Developer to
expose this as part of plugin definition.
Example configuration could look like
```
script
[jira] [Commented] (CB-6481) Add unified hooks support for cordova app and plugins
[
https://issues.apache.org/jira/browse/CB-6481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14058818#comment-14058818
]
ASF GitHub Bot commented on CB-6481:
Github user kamrik commented on a diff in the pull request:
https://github.com/apache/cordova-lib/pull/55#discussion_r14821829
--- Diff: cordova-lib/src/hooks/ScriptsFinder.js ---
@@ -0,0 +1,158 @@
+/**
+ Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information
+ regarding copyright ownership. The ASF licenses this file
+ to you under the Apache License, Version 2.0 (the
+ License); you may not use this file except in compliance
+ with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing,
+ software distributed under the License is distributed on an
+ AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ KIND, either express or implied. See the License for the
+ specific language governing permissions and limitations
+ under the License.
+ */
+
+var path = require('path'),
+fs = require('fs'),
+cordovaUtil = require('../cordova/util'),
+events = require('../events'),
+Q = require('q'),
+plugin = require('../cordova/plugin'),
+PluginInfo = require('../PluginInfo'),
+ConfigParser = require('../configparser/ConfigParser'),
+CordovaError = require('../CordovaError'),
+Context = require('./Context');
+
+/**
+ * Implements logic to retrieve hook script files defined in special
folders and configuration
+ * files: config.xml, hooks/hook_type, plugins/../plugin.xml, etc
+ */
+module.exports = {
+/**
+ * Returns all script files for the hook type specified.
+ */
+getHookScripts: function(hook, opts) {
+// args check
+if (!hook) {
+throw new CordovaError('hook type is not specified');
+}
+return getApplicationHookScripts(hook, opts)
+.concat(getPluginsHookScripts(hook, opts));
+}
+};
+
+/**
+ * Returns script files defined on application level.
+ * They are stored in .cordova/hooks folders and in config.xml.
+ */
+function getApplicationHookScripts(hook, opts) {
+// args check
+if (!hook) {
+throw new CordovaError('hook type is not specified');
+}
+return getApplicationHookScriptsFromDir(path.join(opts.projectRoot,
'.cordova', 'hooks', hook))
+
.concat(getApplicationHookScriptsFromDir(path.join(opts.projectRoot, 'hooks',
hook)))
+.concat(getScriptsFromConfigXml(hook, opts));
+}
+
+/**
+ * Returns script files defined by plugin developers as part of plugin.xml.
+ */
+function getPluginsHookScripts(hook, opts) {
+// args check
+if (!hook) {
+throw new CordovaError('hook type is not specified');
--- End diff --
Not really a guideline but: CordovaError is only printed as the message
while Error results in a full stack trace. So I would say, use CordovaError for
errors that you expect to happen due to bad user input. If it's happening
because of bad code that we wrote, it should be an Error().
Add unified hooks support for cordova app and plugins
-
Key: CB-6481
URL: https://issues.apache.org/jira/browse/CB-6481
Project: Apache Cordova
Issue Type: New Feature
Components: CLI, Plugman
Reporter: Sergey Grebnov
Assignee: Sergey Grebnov
As per Proposal: hooks support for plugins dev mail thread discussion
Hi, I have an idea how we can add more flexibility to plugin developers.
Note, right now we have Application Developers – someone who use Cordova for
developing applications and Plugin Developers – someone who creates plugins
so that Application Developers can use them. For Application Developers we
expose hooks so that they can customize their build/package/etc process. I
want us to provide similar sort of flexibility to Plugin Developers so that
they can go beyond of source/, framework/ tags and get mechanism to add
custom installation, build logic required by a plugin. Example usage will
include: downloading/compiling additional binaries, marking source file to be
copied to output dir, changing target build platform, etc. At present time
the steps described could be only achieved by hooks manually added by
Application Developer, but the right way is to allow Plugin Developer to
expose this as part of
[jira] [Commented] (CB-6481) Add unified hooks support for cordova app and plugins
[
https://issues.apache.org/jira/browse/CB-6481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14058813#comment-14058813
]
ASF GitHub Bot commented on CB-6481:
Github user sgrebnov commented on a diff in the pull request:
https://github.com/apache/cordova-lib/pull/55#discussion_r14821551
--- Diff: cordova-lib/src/hooks/ScriptsFinder.js ---
@@ -0,0 +1,158 @@
+/**
+ Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information
+ regarding copyright ownership. The ASF licenses this file
+ to you under the Apache License, Version 2.0 (the
+ License); you may not use this file except in compliance
+ with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing,
+ software distributed under the License is distributed on an
+ AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ KIND, either express or implied. See the License for the
+ specific language governing permissions and limitations
+ under the License.
+ */
+
+var path = require('path'),
+fs = require('fs'),
+cordovaUtil = require('../cordova/util'),
+events = require('../events'),
+Q = require('q'),
+plugin = require('../cordova/plugin'),
+PluginInfo = require('../PluginInfo'),
+ConfigParser = require('../configparser/ConfigParser'),
+CordovaError = require('../CordovaError'),
+Context = require('./Context');
+
+/**
+ * Implements logic to retrieve hook script files defined in special
folders and configuration
+ * files: config.xml, hooks/hook_type, plugins/../plugin.xml, etc
+ */
+module.exports = {
+/**
+ * Returns all script files for the hook type specified.
+ */
+getHookScripts: function(hook, opts) {
+// args check
+if (!hook) {
+throw new CordovaError('hook type is not specified');
+}
+return getApplicationHookScripts(hook, opts)
+.concat(getPluginsHookScripts(hook, opts));
+}
+};
+
+/**
+ * Returns script files defined on application level.
+ * They are stored in .cordova/hooks folders and in config.xml.
+ */
+function getApplicationHookScripts(hook, opts) {
+// args check
+if (!hook) {
+throw new CordovaError('hook type is not specified');
+}
+return getApplicationHookScriptsFromDir(path.join(opts.projectRoot,
'.cordova', 'hooks', hook))
+
.concat(getApplicationHookScriptsFromDir(path.join(opts.projectRoot, 'hooks',
hook)))
+.concat(getScriptsFromConfigXml(hook, opts));
+}
+
+/**
+ * Returns script files defined by plugin developers as part of plugin.xml.
+ */
+function getPluginsHookScripts(hook, opts) {
+// args check
+if (!hook) {
+throw new CordovaError('hook type is not specified');
--- End diff --
Thx @kamrik - I'll review this. Btw, is there any special guideline where
we should use Error vs CordovaError?
Add unified hooks support for cordova app and plugins
-
Key: CB-6481
URL: https://issues.apache.org/jira/browse/CB-6481
Project: Apache Cordova
Issue Type: New Feature
Components: CLI, Plugman
Reporter: Sergey Grebnov
Assignee: Sergey Grebnov
As per Proposal: hooks support for plugins dev mail thread discussion
Hi, I have an idea how we can add more flexibility to plugin developers.
Note, right now we have Application Developers – someone who use Cordova for
developing applications and Plugin Developers – someone who creates plugins
so that Application Developers can use them. For Application Developers we
expose hooks so that they can customize their build/package/etc process. I
want us to provide similar sort of flexibility to Plugin Developers so that
they can go beyond of source/, framework/ tags and get mechanism to add
custom installation, build logic required by a plugin. Example usage will
include: downloading/compiling additional binaries, marking source file to be
copied to output dir, changing target build platform, etc. At present time
the steps described could be only achieved by hooks manually added by
Application Developer, but the right way is to allow Plugin Developer to
expose this as part of plugin definition.
Example configuration could look like
```
script type=postinstall src=scripts/postinstall.js /
script type=preinstall src=scripts/preinstall.js /
script
[jira] [Commented] (CB-5109) Windows 8.1 - InAppBrowser
[ https://issues.apache.org/jira/browse/CB-5109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14058822#comment-14058822 ] Sergey Grebnov commented on CB-5109: Hey Maxime, could you please add the following changes to the code 1. As part of Windows Universal Apps we support Windows 8.0 as well so the same proxy class will be applied to that target build platform as well. So we should use feature detection or another custom logic to decide whether we should proceed with the new or old api. We are working on reporting different values via cordova.platformId: 'windows8' for Windows 8.0 and 'windows' for Windows 8.1 and Phone 8.1 but this is not implemented yet. As a result we should have single src/windows/InAppBrowserProxy.js which works for all three platforms 2. Propose to duplicate 'windows8' section as 'windows' (exactly the same content) - this should be done since we are moving from windows8 to a new windows8 platform and we would like to deprecate/remove 'windows8' section in the future. How it currently works: new windows platform uses 'windows8' section if there is no 'windows' section as part of plugin Windows 8.1 - InAppBrowser -- Key: CB-5109 URL: https://issues.apache.org/jira/browse/CB-5109 Project: Apache Cordova Issue Type: Sub-task Components: Plugin InAppBrowser, Windows 8 Reporter: Maxime LUCE Assignee: Sergey Grebnov In Windows 8.1, there is a new WebView control. It can be used to create an InAppBrowser implementation. http://msdn.microsoft.com/en-us/library/windows/apps/dn301831.aspx -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (CB-5109) Windows 8.1 - InAppBrowser
[ https://issues.apache.org/jira/browse/CB-5109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14058822#comment-14058822 ] Sergey Grebnov edited comment on CB-5109 at 7/11/14 2:09 PM: - Hey Maxime, could you please add the following changes to the code 1. As part of Windows Universal Apps we support Windows 8.0 as well so the same proxy class will be applied to that target build platform as well. So we should use feature detection or another custom logic to decide whether we should proceed with the new or old api. We are working on reporting different values via cordova.platformId: 'windows8' for Windows 8.0 and 'windows' for Windows 8.1 and Phone 8.1 but this is not implemented yet. As a result we should have single src/windows/InAppBrowserProxy.js which works for all three platforms 2. Propose to duplicate 'windows8' section as 'windows' (exactly the same content) - this should be done since we are moving from windows8 to a new windows platform and we would like to deprecate/remove 'windows8' section in the future. How it currently works: new windows platform uses 'windows8' section if there is no 'windows' section as part of plugin was (Author: sgrebnov): Hey Maxime, could you please add the following changes to the code 1. As part of Windows Universal Apps we support Windows 8.0 as well so the same proxy class will be applied to that target build platform as well. So we should use feature detection or another custom logic to decide whether we should proceed with the new or old api. We are working on reporting different values via cordova.platformId: 'windows8' for Windows 8.0 and 'windows' for Windows 8.1 and Phone 8.1 but this is not implemented yet. As a result we should have single src/windows/InAppBrowserProxy.js which works for all three platforms 2. Propose to duplicate 'windows8' section as 'windows' (exactly the same content) - this should be done since we are moving from windows8 to a new windows8 platform and we would like to deprecate/remove 'windows8' section in the future. How it currently works: new windows platform uses 'windows8' section if there is no 'windows' section as part of plugin Windows 8.1 - InAppBrowser -- Key: CB-5109 URL: https://issues.apache.org/jira/browse/CB-5109 Project: Apache Cordova Issue Type: Sub-task Components: Plugin InAppBrowser, Windows 8 Reporter: Maxime LUCE Assignee: Sergey Grebnov In Windows 8.1, there is a new WebView control. It can be used to create an InAppBrowser implementation. http://msdn.microsoft.com/en-us/library/windows/apps/dn301831.aspx -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-6481) Add unified hooks support for cordova app and plugins
[
https://issues.apache.org/jira/browse/CB-6481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14058825#comment-14058825
]
ASF GitHub Bot commented on CB-6481:
Github user sgrebnov commented on a diff in the pull request:
https://github.com/apache/cordova-lib/pull/55#discussion_r14822338
--- Diff: cordova-lib/src/hooks/ScriptsFinder.js ---
@@ -0,0 +1,158 @@
+/**
+ Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information
+ regarding copyright ownership. The ASF licenses this file
+ to you under the Apache License, Version 2.0 (the
+ License); you may not use this file except in compliance
+ with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing,
+ software distributed under the License is distributed on an
+ AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ KIND, either express or implied. See the License for the
+ specific language governing permissions and limitations
+ under the License.
+ */
+
+var path = require('path'),
+fs = require('fs'),
+cordovaUtil = require('../cordova/util'),
+events = require('../events'),
+Q = require('q'),
+plugin = require('../cordova/plugin'),
+PluginInfo = require('../PluginInfo'),
+ConfigParser = require('../configparser/ConfigParser'),
+CordovaError = require('../CordovaError'),
+Context = require('./Context');
+
+/**
+ * Implements logic to retrieve hook script files defined in special
folders and configuration
+ * files: config.xml, hooks/hook_type, plugins/../plugin.xml, etc
+ */
+module.exports = {
+/**
+ * Returns all script files for the hook type specified.
+ */
+getHookScripts: function(hook, opts) {
+// args check
+if (!hook) {
+throw new CordovaError('hook type is not specified');
+}
+return getApplicationHookScripts(hook, opts)
+.concat(getPluginsHookScripts(hook, opts));
+}
+};
+
+/**
+ * Returns script files defined on application level.
+ * They are stored in .cordova/hooks folders and in config.xml.
+ */
+function getApplicationHookScripts(hook, opts) {
+// args check
+if (!hook) {
+throw new CordovaError('hook type is not specified');
+}
+return getApplicationHookScriptsFromDir(path.join(opts.projectRoot,
'.cordova', 'hooks', hook))
+
.concat(getApplicationHookScriptsFromDir(path.join(opts.projectRoot, 'hooks',
hook)))
+.concat(getScriptsFromConfigXml(hook, opts));
+}
+
+/**
+ * Returns script files defined by plugin developers as part of plugin.xml.
+ */
+function getPluginsHookScripts(hook, opts) {
+// args check
+if (!hook) {
+throw new CordovaError('hook type is not specified');
--- End diff --
Got it, thanks!
Add unified hooks support for cordova app and plugins
-
Key: CB-6481
URL: https://issues.apache.org/jira/browse/CB-6481
Project: Apache Cordova
Issue Type: New Feature
Components: CLI, Plugman
Reporter: Sergey Grebnov
Assignee: Sergey Grebnov
As per Proposal: hooks support for plugins dev mail thread discussion
Hi, I have an idea how we can add more flexibility to plugin developers.
Note, right now we have Application Developers – someone who use Cordova for
developing applications and Plugin Developers – someone who creates plugins
so that Application Developers can use them. For Application Developers we
expose hooks so that they can customize their build/package/etc process. I
want us to provide similar sort of flexibility to Plugin Developers so that
they can go beyond of source/, framework/ tags and get mechanism to add
custom installation, build logic required by a plugin. Example usage will
include: downloading/compiling additional binaries, marking source file to be
copied to output dir, changing target build platform, etc. At present time
the steps described could be only achieved by hooks manually added by
Application Developer, but the right way is to allow Plugin Developer to
expose this as part of plugin definition.
Example configuration could look like
```
script type=postinstall src=scripts/postinstall.js /
script type=preinstall src=scripts/preinstall.js /
script type=install src=scripts/install.js /
```
beforeinstall/preinstall – run before plugin is
[jira] [Commented] (CB-5109) Windows 8.1 - InAppBrowser
[ https://issues.apache.org/jira/browse/CB-5109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14058892#comment-14058892 ] Maxime LUCE commented on CB-5109: - Hi Sergey, I'm currently working on a way to detect wether the application is running on version 1 or 2 of WinJS in order to know if I should use x-ms-webview or iframe inside the plugin. I will let you know when I found a solution, if you have one, let me know. Windows 8.1 - InAppBrowser -- Key: CB-5109 URL: https://issues.apache.org/jira/browse/CB-5109 Project: Apache Cordova Issue Type: Sub-task Components: Plugin InAppBrowser, Windows 8 Reporter: Maxime LUCE Assignee: Sergey Grebnov In Windows 8.1, there is a new WebView control. It can be used to create an InAppBrowser implementation. http://msdn.microsoft.com/en-us/library/windows/apps/dn301831.aspx -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CB-7123) Firefox OS inAppBrowser forward/back buttons fail
[ https://issues.apache.org/jira/browse/CB-7123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Zalewa reassigned CB-7123: Assignee: Piotr Zalewa Firefox OS inAppBrowser forward/back buttons fail - Key: CB-7123 URL: https://issues.apache.org/jira/browse/CB-7123 Project: Apache Cordova Issue Type: Bug Components: FirefoxOS Affects Versions: 3.5.0 Reporter: Jason Weathersby Assignee: Piotr Zalewa Priority: Minor Firefox OS inAppBrowser plugin uses the goBack/goForward methods https://developer.mozilla.org/en-US/docs/Web/API/HTMLIFrameElement.goBack These require the app to be privileged. While the proper permission is added to the manifest, the type privileged is not set. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CB-7123) Firefox OS inAppBrowser forward/back buttons fail
Jason Weathersby created CB-7123: Summary: Firefox OS inAppBrowser forward/back buttons fail Key: CB-7123 URL: https://issues.apache.org/jira/browse/CB-7123 Project: Apache Cordova Issue Type: Bug Components: FirefoxOS Affects Versions: 3.5.0 Reporter: Jason Weathersby Priority: Minor Firefox OS inAppBrowser plugin uses the goBack/goForward methods https://developer.mozilla.org/en-US/docs/Web/API/HTMLIFrameElement.goBack These require the app to be privileged. While the proper permission is added to the manifest, the type privileged is not set. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-7123) Firefox OS inAppBrowser forward/back buttons fail
[ https://issues.apache.org/jira/browse/CB-7123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14059015#comment-14059015 ] Jason Weathersby commented on CB-7123: -- You can work around the issue by modifying the manifest after the project has been built. Firefox OS inAppBrowser forward/back buttons fail - Key: CB-7123 URL: https://issues.apache.org/jira/browse/CB-7123 Project: Apache Cordova Issue Type: Bug Components: FirefoxOS Affects Versions: 3.5.0 Reporter: Jason Weathersby Assignee: Piotr Zalewa Priority: Minor Firefox OS inAppBrowser plugin uses the goBack/goForward methods https://developer.mozilla.org/en-US/docs/Web/API/HTMLIFrameElement.goBack These require the app to be privileged. While the proper permission is added to the manifest, the type privileged is not set. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-7104) Plugin results not transmitted back to devices (specially Samsung S4 and S5)
[ https://issues.apache.org/jira/browse/CB-7104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14059048#comment-14059048 ] ASF GitHub Bot commented on CB-7104: Github user nolanlawson commented on the pull request: https://github.com/apache/cordova-android/pull/105#issuecomment-48759335 @agrieve Applying that patch to the 3.5.0 release fixes the issue completely. :) Y'all are amazing! Plugin results not transmitted back to devices (specially Samsung S4 and S5) Key: CB-7104 URL: https://issues.apache.org/jira/browse/CB-7104 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 3.3.0 Reporter: Håkon Nilsen Priority: Blocker Labels: patch Our app relies heavily on Cordova plugins for communicating between JavaScript and native, and on certain devices these messages are not consistently sent back to the JavaScript API. I've tracked it down to a problem with webView.setNetworkAvailable()-usage in NativeToJsMessageQueue.java, and I have a suggestion for a fix. The problem with the current setup of (3.3.0) of NativeToJsMessageQueue seems to be that the online flag is toggled every time a plugin is fired, while webView.setNetworkAvailable(online) is only fired if the queue has messages. Since not all plugins have messages, the online flag can be toggled twice, and the online flag will be i.e. false for each time the command is run - which means Cordova won't send any messages. On Samsung S4 and S5 the hideKeyboard-event is slower or faster than other devices, which results in a doble toggle of the online flag. This leads to the following command being sent when there is a message in the queue: webView.setNetworkAvailable(false); // first message webView.setNetworkAvailable(false); // second message, which is not being sent webView.setNetworkAvailable(false); // third message, which will be sent For us it has been a terrible blocker, and I've made a change to the OnlineEventsBridgeMode in NativeToJsMessageQueue.java that addresses this. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-7123) Firefox OS inAppBrowser forward/back buttons fail
[ https://issues.apache.org/jira/browse/CB-7123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14059067#comment-14059067 ] ASF GitHub Bot commented on CB-7123: GitHub user zalun opened a pull request: https://github.com/apache/cordova-plugin-inappbrowser/pull/51 CB-7123 - app needs to be privileged You can merge this pull request into a Git repository by running: $ git pull https://github.com/zalun/cordova-plugin-inappbrowser privileged_in_ffos Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-plugin-inappbrowser/pull/51.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 #51 commit 9fe291ce7ae47982a38e4e88c9a20c10b72bfdf5 Author: Piotr Zalewa pi...@zalewa.info Date: 2014-07-11T17:40:03Z app needs to be privileged Firefox OS inAppBrowser forward/back buttons fail - Key: CB-7123 URL: https://issues.apache.org/jira/browse/CB-7123 Project: Apache Cordova Issue Type: Bug Components: FirefoxOS Affects Versions: 3.5.0 Reporter: Jason Weathersby Assignee: Piotr Zalewa Priority: Minor Firefox OS inAppBrowser plugin uses the goBack/goForward methods https://developer.mozilla.org/en-US/docs/Web/API/HTMLIFrameElement.goBack These require the app to be privileged. While the proper permission is added to the manifest, the type privileged is not set. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-7123) Firefox OS inAppBrowser forward/back buttons fail
[ https://issues.apache.org/jira/browse/CB-7123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14059078#comment-14059078 ] ASF GitHub Bot commented on CB-7123: Github user rodms10 commented on the pull request: https://github.com/apache/cordova-plugin-inappbrowser/pull/51#issuecomment-48760923 Looks good. r+ Firefox OS inAppBrowser forward/back buttons fail - Key: CB-7123 URL: https://issues.apache.org/jira/browse/CB-7123 Project: Apache Cordova Issue Type: Bug Components: FirefoxOS Affects Versions: 3.5.0 Reporter: Jason Weathersby Assignee: Piotr Zalewa Priority: Minor Firefox OS inAppBrowser plugin uses the goBack/goForward methods https://developer.mozilla.org/en-US/docs/Web/API/HTMLIFrameElement.goBack These require the app to be privileged. While the proper permission is added to the manifest, the type privileged is not set. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-7102) globalization
[
https://issues.apache.org/jira/browse/CB-7102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14059081#comment-14059081
]
ASF GitHub Bot commented on CB-7102:
Github user zalun commented on the pull request:
https://github.com/apache/cordova-plugin-globalization/pull/17#issuecomment-48761078
@rodms10 I've been checking the plugin with this code:
```
navigator.globalization.getLocaleName(
function(lang) {
console.log('getLocaleName: ' + lang);
},
function() {alert('ERROR1')});
navigator.globalization.getPreferredLanguage(
function(lang) {
console.log('getPreferredLanguage: ' + lang.value);
},
function() {alert('ERROR2')});
navigator.globalization.dateToString(new Date('2014-10-30'),
function(format) {
console.log('long, time and date: ' + format.value);
},
function() {alert('ERROR3')}, {formatLength: 'long', selector:
'time and date'});
navigator.globalization.dateToString(new Date('2014-10-30'),
function(format) {
console.log('long, time: ' + format.value);
},
function() {alert('ERROR4')}, {formatLength: 'long', selector:
'time'});
navigator.globalization.dateToString(new Date('2014-10-30'),
function(format) {
console.log('date: ' + format.value);
},
function() {alert('ERROR5')}, {selector: 'date'});
navigator.globalization.dateToString(new Date('2014-10-30'),
function(format) {
console.log('standard: ' + format.value);
},
function() {alert('ERROR6')});
navigator.globalization.stringToDate('2011-10-10T14:48:00',
function(date) {
console.log('stringToDate', date);
},
function() {alert('ERROR7')}, {'selector': 'time and date'});
navigator.globalization.getFirstDayOfWeek(
function(day) {
console.log('first day of week', day.value);
},
function() {alert('ERROR8')});
navigator.globalization.getDateNames(
function(names) {
console.log('date names', names.value);
},
function() {alert('ERROR9')}, {'item': 'months', 'type':
'genitive'});
navigator.globalization.isDayLightSavingsTime(new
Date('2014-01-01'),
function(isIt) {
console.log('is 1 Jan DST?', isIt.dst);
},
function() {alert('ERROR10')});
```
globalization
-
Key: CB-7102
URL: https://issues.apache.org/jira/browse/CB-7102
Project: Apache Cordova
Issue Type: Sub-task
Components: FirefoxOS
Reporter: Piotr Zalewa
Assignee: Piotr Zalewa
Add globalization support for Firefox OS
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CB-7124) `cordova platform add platform@version` not working for Git based installs
[
https://issues.apache.org/jira/browse/CB-7124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pascal Widdershoven updated CB-7124:
Description:
Currently the {{cordova platform add platform@version}} is only working
with the {{--usenpm}} option enabled.
I think --usenpm is disabled by default ( ?) so this feature will appear broken
to most users. I've pinpointed the problem to [this peace of
code|https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/cordova/lazy_load.js#L86]
where for the cordova_git function the @version check is missing.
I hope I can find some time to sign the ICLA and send a pull request. In
general it seems that the whole @version check could be handled more elegantly,
right now it's duplicated in several places making it easy to forget to add it
somewhere.
was:
Currently the `cordova platform add platform@version` is only working with
the `--usenpm` option enabled.
I think --usenpm is disabled by default (?) so this feature will appear broken
to most users. I've pinpointed the problem to [this peace of
code|https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/cordova/lazy_load.js#L86]
where for the cordova_git function the @version check is missing.
I hope I can find some time to sign the ICLA and send a pull request. In
general it seems that the whole @version check could be handled more elegantly,
right now it's duplicated in several places making it easy to forget to add it
somewhere.
`cordova platform add platform@version` not working for Git based installs
--
Key: CB-7124
URL: https://issues.apache.org/jira/browse/CB-7124
Project: Apache Cordova
Issue Type: Bug
Components: CLI
Affects Versions: 3.5.0
Reporter: Pascal Widdershoven
Currently the {{cordova platform add platform@version}} is only working
with the {{--usenpm}} option enabled.
I think --usenpm is disabled by default ( ?) so this feature will appear
broken to most users. I've pinpointed the problem to [this peace of
code|https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/cordova/lazy_load.js#L86]
where for the cordova_git function the @version check is missing.
I hope I can find some time to sign the ICLA and send a pull request. In
general it seems that the whole @version check could be handled more
elegantly, right now it's duplicated in several places making it easy to
forget to add it somewhere.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CB-7124) `cordova platform add platform@version` not working for Git based installs
Pascal Widdershoven created CB-7124: --- Summary: `cordova platform add platform@version` not working for Git based installs Key: CB-7124 URL: https://issues.apache.org/jira/browse/CB-7124 Project: Apache Cordova Issue Type: Bug Components: CLI Affects Versions: 3.5.0 Reporter: Pascal Widdershoven Currently the `cordova platform add platform@version` is only working with the `--usenpm` option enabled. I think --usenpm is disabled by default (?) so this feature will appear broken to most users. I've pinpointed the problem to [this peace of code|https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/cordova/lazy_load.js#L86] where for the cordova_git function the @version check is missing. I hope I can find some time to sign the ICLA and send a pull request. In general it seems that the whole @version check could be handled more elegantly, right now it's duplicated in several places making it easy to forget to add it somewhere. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CB-7124) `cordova platform add platform@version` not working for Git based installs
[
https://issues.apache.org/jira/browse/CB-7124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pascal Widdershoven updated CB-7124:
Description:
Currently the {{cordova platform add platform@version}} is only working
with the {{--usenpm}} option enabled.
I think --usenpm is disabled by default (\?) so this feature will appear broken
to most users. I've pinpointed the problem to [this peace of
code|https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/cordova/lazy_load.js#L86]
where for the cordova_git function the @version check is missing.
I hope I can find some time to sign the ICLA and send a pull request. In
general it seems that the whole @version check could be handled more elegantly,
right now it's duplicated in several places making it easy to forget to add it
somewhere.
was:
Currently the {{cordova platform add platform@version}} is only working
with the {{--usenpm}} option enabled.
I think --usenpm is disabled by default ( ?) so this feature will appear broken
to most users. I've pinpointed the problem to [this peace of
code|https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/cordova/lazy_load.js#L86]
where for the cordova_git function the @version check is missing.
I hope I can find some time to sign the ICLA and send a pull request. In
general it seems that the whole @version check could be handled more elegantly,
right now it's duplicated in several places making it easy to forget to add it
somewhere.
`cordova platform add platform@version` not working for Git based installs
--
Key: CB-7124
URL: https://issues.apache.org/jira/browse/CB-7124
Project: Apache Cordova
Issue Type: Bug
Components: CLI
Affects Versions: 3.5.0
Reporter: Pascal Widdershoven
Currently the {{cordova platform add platform@version}} is only working
with the {{--usenpm}} option enabled.
I think --usenpm is disabled by default (\?) so this feature will appear
broken to most users. I've pinpointed the problem to [this peace of
code|https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/cordova/lazy_load.js#L86]
where for the cordova_git function the @version check is missing.
I hope I can find some time to sign the ICLA and send a pull request. In
general it seems that the whole @version check could be handled more
elegantly, right now it's duplicated in several places making it easy to
forget to add it somewhere.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CB-7124) `cordova platform add platform@version` not working for Git based installs
[
https://issues.apache.org/jira/browse/CB-7124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pascal Widdershoven updated CB-7124:
Description:
Currently the {{cordova platform add platform@version}} is only working
with the {{--usenpm}} option enabled.
I think --usenpm is disabled by default (\?) so this feature will appear broken
to most users. I've pinpointed the problem to [this peace of
code|https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/cordova/lazy_load.js#L86]
where for the cordova_git function the @version check is missing, resulting in
a Platform not recognized error when the platform includes a version code.
I hope I can find some time to sign the ICLA and send a pull request. In
general it seems that the whole @version check could be handled more elegantly,
right now it's duplicated in several places making it easy to forget to add it
somewhere.
was:
Currently the {{cordova platform add platform@version}} is only working
with the {{--usenpm}} option enabled.
I think --usenpm is disabled by default (\?) so this feature will appear broken
to most users. I've pinpointed the problem to [this peace of
code|https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/cordova/lazy_load.js#L86]
where for the cordova_git function the @version check is missing.
I hope I can find some time to sign the ICLA and send a pull request. In
general it seems that the whole @version check could be handled more elegantly,
right now it's duplicated in several places making it easy to forget to add it
somewhere.
`cordova platform add platform@version` not working for Git based installs
--
Key: CB-7124
URL: https://issues.apache.org/jira/browse/CB-7124
Project: Apache Cordova
Issue Type: Bug
Components: CLI
Affects Versions: 3.5.0
Reporter: Pascal Widdershoven
Currently the {{cordova platform add platform@version}} is only working
with the {{--usenpm}} option enabled.
I think --usenpm is disabled by default (\?) so this feature will appear
broken to most users. I've pinpointed the problem to [this peace of
code|https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/cordova/lazy_load.js#L86]
where for the cordova_git function the @version check is missing, resulting
in a Platform not recognized error when the platform includes a version
code.
I hope I can find some time to sign the ICLA and send a pull request. In
general it seems that the whole @version check could be handled more
elegantly, right now it's duplicated in several places making it easy to
forget to add it somewhere.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-7109) exec() call to plugin blocked the main thread
[
https://issues.apache.org/jira/browse/CB-7109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14059230#comment-14059230
]
Rajesh Kumar commented on CB-7109:
--
oh.. all the plugins currently use the json array args. So, I would rather wait
for an update to cordova. You have any other suggestions?
exec() call to plugin blocked the main thread
-
Key: CB-7109
URL: https://issues.apache.org/jira/browse/CB-7109
Project: Apache Cordova
Issue Type: Bug
Components: Android, Plugin File
Affects Versions: 3.5.0
Reporter: Rajesh Kumar
Priority: Minor
In the file plugin of v3.5.0, I constantly see a warning in logcat in eclipse
when I try to write to a file. The warning is:
THREAD WARNING: exec() call to File.write blocked the main thread for 117ms.
Plugin should use CordovaInterface.getThreadPool().
Similar issue is when I try to exit app. I guess this issue is present for
all the plugins. I checked the part of File plugin code:
final String fname=args.getString(0);
final String data=args.getString(1);
final int offset=args.getInt(2);
final Boolean isBinary=args.getBoolean(3);
threadhelper( new FileOp( ){
public void run() throws FileNotFoundException, IOException,
NoModificationAllowedException {
long fileSize = write(fname, data, offset, isBinary);
callbackContext.sendPluginResult(new
PluginResult(PluginResult.Status.OK, fileSize));
}
}, callbackContext);
And, threadhelper uses:
cordova.getThreadPool().execute(new Runnable() {
public void run() {}
});
This means, the plugin is using a thread to do some async task, but logcat
throws the block warning. We need to fix this.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-7123) Firefox OS inAppBrowser forward/back buttons fail
[ https://issues.apache.org/jira/browse/CB-7123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14059236#comment-14059236 ] ASF GitHub Bot commented on CB-7123: Github user asfgit closed the pull request at: https://github.com/apache/cordova-plugin-inappbrowser/pull/51 Firefox OS inAppBrowser forward/back buttons fail - Key: CB-7123 URL: https://issues.apache.org/jira/browse/CB-7123 Project: Apache Cordova Issue Type: Bug Components: FirefoxOS Affects Versions: 3.5.0 Reporter: Jason Weathersby Assignee: Piotr Zalewa Priority: Minor Firefox OS inAppBrowser plugin uses the goBack/goForward methods https://developer.mozilla.org/en-US/docs/Web/API/HTMLIFrameElement.goBack These require the app to be privileged. While the proper permission is added to the manifest, the type privileged is not set. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-7109) exec() call to plugin blocked the main thread
[
https://issues.apache.org/jira/browse/CB-7109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14059256#comment-14059256
]
Andrew Grieve commented on CB-7109:
---
Have a look at the base class:
https://github.com/apache/cordova-android/blob/master/framework/src/org/apache/cordova/CordovaPlugin.java#L82
The rawArgs call is what's called by the PluginManager. All I'm saying is to
try overriding that different overload of the execute() function, delegate to a
background thread, and *then* create the CordovaArgs object.
exec() call to plugin blocked the main thread
-
Key: CB-7109
URL: https://issues.apache.org/jira/browse/CB-7109
Project: Apache Cordova
Issue Type: Bug
Components: Android, Plugin File
Affects Versions: 3.5.0
Reporter: Rajesh Kumar
Priority: Minor
In the file plugin of v3.5.0, I constantly see a warning in logcat in eclipse
when I try to write to a file. The warning is:
THREAD WARNING: exec() call to File.write blocked the main thread for 117ms.
Plugin should use CordovaInterface.getThreadPool().
Similar issue is when I try to exit app. I guess this issue is present for
all the plugins. I checked the part of File plugin code:
final String fname=args.getString(0);
final String data=args.getString(1);
final int offset=args.getInt(2);
final Boolean isBinary=args.getBoolean(3);
threadhelper( new FileOp( ){
public void run() throws FileNotFoundException, IOException,
NoModificationAllowedException {
long fileSize = write(fname, data, offset, isBinary);
callbackContext.sendPluginResult(new
PluginResult(PluginResult.Status.OK, fileSize));
}
}, callbackContext);
And, threadhelper uses:
cordova.getThreadPool().execute(new Runnable() {
public void run() {}
});
This means, the plugin is using a thread to do some async task, but logcat
throws the block warning. We need to fix this.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-6512) Support adding platforms by local path and/or git url
[ https://issues.apache.org/jira/browse/CB-6512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14059270#comment-14059270 ] ASF subversion and git services commented on CB-6512: - Commit 3695d6fef8998929189a36681bbe1f99c13f7887 in cordova-lib's branch refs/heads/master from [~kamrik] [ https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;h=3695d6f ] CB-6512: platform add path was using wrong www/cordova.js cordova prepare nukes the www dir under platform on each prepare, so it was using www/cordova.js from the cached platfrom files to restore it. For this to work, prepare was starting with a lazy_load(platform) to make sure it has the platform files cached. For the case of platform add path this was downloading a stock version of platform files instead of using the ones in path. Some time ago see CB-5063 cordova started keeping a copy of cordova.js under /platfroms/platfrom/platfrom_www/ but the cached files were still needed for older projects that didn't yet have platform_www. This commit removes the lazy_load before prepare and counts on platform_www to exist. It also adds platform_www during `platform add`. Support adding platforms by local path and/or git url - Key: CB-6512 URL: https://issues.apache.org/jira/browse/CB-6512 Project: Apache Cordova Issue Type: Improvement Components: CLI Reporter: Michal Mocny Assignee: Mark Koudritsky Priority: Minor You can add local development versions of plugins with cordova plugin add ~/path/to/plugin, but you cannot do that for platforms. We should fix that. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-5063) Prepare should not depend on the ~/.cordova/libs directory
[ https://issues.apache.org/jira/browse/CB-5063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14059271#comment-14059271 ] ASF subversion and git services commented on CB-5063: - Commit 3695d6fef8998929189a36681bbe1f99c13f7887 in cordova-lib's branch refs/heads/master from [~kamrik] [ https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;h=3695d6f ] CB-6512: platform add path was using wrong www/cordova.js cordova prepare nukes the www dir under platform on each prepare, so it was using www/cordova.js from the cached platfrom files to restore it. For this to work, prepare was starting with a lazy_load(platform) to make sure it has the platform files cached. For the case of platform add path this was downloading a stock version of platform files instead of using the ones in path. Some time ago see CB-5063 cordova started keeping a copy of cordova.js under /platfroms/platfrom/platfrom_www/ but the cached files were still needed for older projects that didn't yet have platform_www. This commit removes the lazy_load before prepare and counts on platform_www to exist. It also adds platform_www during `platform add`. Prepare should not depend on the ~/.cordova/libs directory Key: CB-5063 URL: https://issues.apache.org/jira/browse/CB-5063 Project: Apache Cordova Issue Type: Bug Components: CLI Reporter: Andrew Grieve Assignee: Mark Koudritsky Priority: Minor Look in src/metadata/*_parser.js They all have logic in `update_www()` to copy the cordova.js file from util.libDirectory. When users change machines, this turns into an error since the ~/.lib directory is not populated. On iOS, the fix is trivial - a copy of cordova.js already exists at platforms/ios/CordovaLib/cordova.js For other platforms, we could trivially fix the problem just by not blowing away the www/cordova.js file during prepare, but I think it would be better to not rely on that since likely people should not be committing the generated www/ into source control. Instead, let's ensure that all platforms keep a copy of their cordova.js file within their platform/ directory and use copy that into www/ during prepare. We could maybe even get rid of the custom logic entirely by putting the cordova.js file within `merges/` upon `platform add`. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-5109) Windows 8.1 - InAppBrowser
[ https://issues.apache.org/jira/browse/CB-5109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14059268#comment-14059268 ] Maxime LUCE commented on CB-5109: - Hi Sergey, I found a solution to detect WinJS 2.0 by using WinJS.Utilities.Scheduler namespace. I created a pull request with the up to date code. Everything has been centralized in a global Windows proxy. Windows 8.1 - InAppBrowser -- Key: CB-5109 URL: https://issues.apache.org/jira/browse/CB-5109 Project: Apache Cordova Issue Type: Sub-task Components: Plugin InAppBrowser, Windows 8 Reporter: Maxime LUCE Assignee: Sergey Grebnov In Windows 8.1, there is a new WebView control. It can be used to create an InAppBrowser implementation. http://msdn.microsoft.com/en-us/library/windows/apps/dn301831.aspx -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-7078) serve.spec.js is slow, should be rewritten to be like plugin.spec.js
[ https://issues.apache.org/jira/browse/CB-7078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14059352#comment-14059352 ] ASF subversion and git services commented on CB-7078: - Commit c4df8251557dbcb9468d398cc4eb6aaeb4fd2c75 in cordova-lib's branch refs/heads/master from [~kamrik] [ https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;h=c4df825 ] CB-7078: Disable serve.spec.js Flaky, needs fixing, disabling for now. serve.spec.js is slow, should be rewritten to be like plugin.spec.js - Key: CB-7078 URL: https://issues.apache.org/jira/browse/CB-7078 Project: Apache Cordova Issue Type: Bug Reporter: Mark Koudritsky The spec for `cordova serve` is slow and overly complicated. It re-creates the project for each sub-test and and uses the vanilla platform files which causes it to hit the network if platform files are not cached in ~/.cordova/lib. The attempt to test all platforms usable on the current box the test is running on is admirable, but it results in non-repeatability between machines which is more of a problem than benefit. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CB-7123) Firefox OS inAppBrowser forward/back buttons fail
[ https://issues.apache.org/jira/browse/CB-7123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Zalewa resolved CB-7123. -- Resolution: Fixed Firefox OS inAppBrowser forward/back buttons fail - Key: CB-7123 URL: https://issues.apache.org/jira/browse/CB-7123 Project: Apache Cordova Issue Type: Bug Components: FirefoxOS Affects Versions: 3.5.0 Reporter: Jason Weathersby Assignee: Piotr Zalewa Priority: Minor Firefox OS inAppBrowser plugin uses the goBack/goForward methods https://developer.mozilla.org/en-US/docs/Web/API/HTMLIFrameElement.goBack These require the app to be privileged. While the proper permission is added to the manifest, the type privileged is not set. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CB-7125) CLI help text for the cordova plugin add command should show option to specify a specific version
Holly Schinsky created CB-7125: -- Summary: CLI help text for the cordova plugin add command should show option to specify a specific version Key: CB-7125 URL: https://issues.apache.org/jira/browse/CB-7125 Project: Apache Cordova Issue Type: Improvement Components: CLI Reporter: Holly Schinsky Priority: Trivial The CLI help text currently doesn't show the option to specify a certain version of plugin via the at sign, for instance: $ cordova plugin add org.apache.cordova.camera@0.2.8 It would be nice to indicate this in the help text, it currently only shows: plugin add SPEC1 [SPEC2 ...] .. [--searchpath directory] . -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-7120) File incompatible with XHR2 FormData
[
https://issues.apache.org/jira/browse/CB-7120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14059452#comment-14059452
]
Morgan Allen commented on CB-7120:
--
FWIW Passing a Blob to FormData.append works as expected.
File incompatible with XHR2 FormData
Key: CB-7120
URL: https://issues.apache.org/jira/browse/CB-7120
Project: Apache Cordova
Issue Type: Bug
Components: Plugin File
Affects Versions: 3.5.0
Environment: Android 4.4.2
Reporter: Morgan Allen
Scenario.
Using the Camera API to load a File (from FileEntry)
Upload File using angular-file-upload
Which uses FormData to upload via XHR
I haven't had time to boil this down to a test case yet but here is what I
have.
{code:title=File Input Request Payload}
--WebKitFormBoundary8InTUnt3DiGk5CgN
Content-Disposition: form-data; name=file; filename=AngularJS-large.png
Content-Type: image/png
--WebKitFormBoundary8InTUnt3DiGk5CgN--
{code}
{code:title=Phonegap File Request Payload}
--WebKitFormBoundaryfFYuBlWwlPwVCVzp
Content-Disposition: form-data; name=file
[object Object]
--WebKitFormBoundaryfFYuBlWwlPwVCVzp--
Response Headersview source
{code}
And inspecting each object shows the Phonegap File is not derived from a Blob
as the browser implementation is.
{code:title=FormData.append API}
void append(DOMString name, File value, optional DOMString filename);
void append(DOMString name, Blob value, optional DOMString filename);
void append(DOMString name, DOMString value);
{code}
Maybe this is causing a serialization issue?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
