Thanks, everyone!
I probably should have introduced myself last month, when I started. I
guess I just got too busy right away with the code :)
Ian
On Thu, Apr 18, 2013 at 10:43 AM, James Jong wrote:
> Welcome Ian!
> -James Jong
>
> On Apr 18, 2013, at 10:20 AM, Andrew Grieve wrote:
>
> > Wan
I'm not a lawyer, and this is not legal advice ;) but OkHTTP is
apache-licensed, as is Cordova, and I believe that the terms of the Apache
license allow us to embed it for distribution.
There's probably someone in Apache who is far more qualified than I to say
what we can and should do, though.
t;
> > Basing it on this: https://www.apache.org/legal/src-headers.html and
> > the AOSP Notice File:
> > https://android.googlesource.com/platform/frameworks/av/+/jb-dev/NOTICE
> >
> > On Mon, Apr 29, 2013 at 10:54 AM, Ian Clelland
> > wrote:
> > > I&#x
Lets not try to force all developers to change their settings; that sounds
like a world of pain.
It should work as a jar -- I can't see any compelling reason to have the
source available in eclipse, except for debugging. If there are bugs in
that code, I would definitely prefer to be fixing them u
Prompted by CB-3327, I've been looking again at the implementation of the
Logger plugin and how it interacts with the native JS console object.
>From what I can see, the current situation is this:
* We have a Logger plugin, which will *either* log using native code, or
using the console object, d
6, 2013 at 11:51 AM, Anis KADRI wrote:
>
> > On Mon, May 6, 2013 at 7:42 AM, Ian Clelland
> > wrote:
> >
> > > * If console.useLogger and logger.useConsole are *both* true, then
> errors
> > > are thrown all around.
> > >
> >
> > This is especially not good.
> >
> > +1 on cleaning things up.
> >
>
A minor cleanup task, but something that I'd like to get fixed before
anyone decides to point any serious XML tools at our plugin XML files.
I'd like to change the namespace of the plugin commands from "
http://phonegap.com/ns/plugins/1.0"; to "
http://cordova.apache.org/ns/plugins/1.0";
To be cl
And I've merged the change into 2.8.x; it looks good.
On Thu, May 23, 2013 at 2:23 PM, Andrew Grieve wrote:
> This probably broke with the recent change to drop the VERSION from the
> cordova.js file name. I see you've filed a bug for it already, so that's
> great!
>
>
> On Thu, May 23, 2013 at
I've been running through cordova-mobile-spec 2.8.0rc1 on my ipad, and
things are looking good! I had to update a couple of tests, but it's all
green right now.
Ian
On Thu, May 23, 2013 at 5:09 PM, Jesse wrote:
>
> > Given a CORDOVA_JS_BUILD_LABEL of 2.8.0rc1-0-g22bc4d8
> > How can I find that commit, so I can be sure I am building the js for
> > windows from the same commit?
>
In case anyone else has the same question, now or in the future --
"2.8.0rc1-0-g
Definitely, Joe --
It looks like Shravan was a little over-eager to apply the DataResource API
to replace FileHelper, and this is definitely a bug.
I'm going to revert the changes that he made to AudioHandler.java, and we
can try the media tests again.
On Fri, May 24, 2013 at 1:59 PM, Joe Bow
On Fri, May 24, 2013 at 2:38 PM, Joe Bowser wrote:
> Hey
>
> I've thrown together a quick 4 line fix to fix it for now, but we need
> to make sure that we actually test things when we change them. This
> change totally broke the Media API on Android, and could have been
> easily avoided. We shou
SInce 2 and 3 both require re-cloning the repository, I'd much rather go
with 2, and rename the branches appropriately.
On Wed, May 29, 2013 at 11:11 AM, Brian LeRoux wrote:
> ya the rename easiest
>
> On Wed, May 29, 2013 at 8:00 AM, Braden Shepherdson
> wrote:
> > I'll keep this thread up to
There's a three-week-outstanding pull request in cordova-android (
https://github.com/apache/cordova-android/pull/52) relating to changing the
default logging prefix
This sounds like a good idea -- we've managed to get rid of the old
'DroidGap' naming almost everywhere else, but it's still appeari
I actually like the idea of extending this into a general developer survey
-- something that we could run every year, and get a better feel for the
entire community.
What versions of Cordova/PhoneGap are you using?
What devices are you targetting?
What is your quest?
How many apps are you shipping
That makes sense. That is probably the only reason to ever merge such a
branch back into master -- essentially the 3.0.0 branch that we have now is
treated as a 'feature' branch, to be merged into master when it is ready
(and after the long-lived 2.9.x branch splits off).
Then, later, we can actua
That's not an issue of "we need better contributions from new people",
that's "We, the committers, need to be more diligent in reviewing and
testing before committing".
We shouldn't be discouraging contributions from anyone, but we don't have
to accept every pull request as-is, either. We can push
I haven't had a problem with node 0.10.x on Linux, but I can confirm that
0.6.x is too old. Unfortunately, it's what's shipping with a lot of distros.
My workflow on Linux has been to download and compile node.js from current
sources, and use that. Is that what you were doing, or did you try a
pac
The only thing that I'm working on this morning that could be a candidate
for 2.9 is an extension to FileWriter.write(Blob) that will accept a
Cordova File object in place of a native Blob object.
(FileWriter.write(Blob) is CB-2406, and new for 2.9)
If we consider this a bug to be fixed, then I c
I can get a test in first, to confirm the bug :) then it's just a matter of
fixing the bug.
On Monday, June 17, 2013, Joe Bowser wrote:
> Can we get a test for it to confirm the fix?
>
> On Mon, Jun 17, 2013 at 10:04 AM, Ian Clelland
> wrote:
> > The only thing that I&#x
On Wed, Jun 19, 2013 at 7:41 PM, Andrew Grieve wrote:
> "null" could be interpreted as a relative URL I think. The current handling
> of relative URLs by plugins is sadly plugin-specific.
>
Isn't that one of the things that DataResource is supposed to standardize?
The string "null" is certainl
> > On Thu, Jun 20, 2013 at 12:34 AM, Andrew Grieve > >wrote:
> >
> > > Agree that we should make Media() an error, but we don't want to change
> > the
> > > semantics of relative URLs for APIs without proper deprecation.
> > >
> >
For tests like this, I'd like to see something in Jasmine that is akin to
the "Expected Failure" result in JUinit / python unittest.
It means that we still run all of the tests, but a failure on a device that
doesn't support the feature doesn't cause the whole test suite to turn red.
On the other
That was an accidental commit, if it's ended up in cordova-ios.
The file was previously in version control; I went back through the git
repo history to find and restore it for cordova-mobile-spec, since iOS
devices require it for the notification tests.
I didn't expect that there would be a licen
Can the SecurityError be caught in an try{} block? If so, then we could
implement a general solution of "try to clobber the entire object; if that
doesn't work, try to clobber each of its properties instead."
In the second case, a debug log line for each property that cannot be
copied would give u
Okay, I just re-read the original "cannot even iterate over its properties"
catch. So we'd need a list of named properties to copy in the second case :(
(What are they attempting to do by blocking iteration on that object,
anyway?)
On Mon, Jun 24, 2013 at 2:50 PM, Ian Clelland
I thought I had updated all of these, but if you have seen some more that
are at www.phonegap.com, please change them over.
CB-3419 was the ticket that was tracking this, if you want to tag any new
related commits.
Ian
On Mon, Jun 24, 2013 at 5:37 PM, Brian LeRoux wrote:
> The latter yes. The
issed.
Ian
On Tue, Jun 25, 2013 at 1:47 PM, Brian LeRoux wrote:
> sorry ian, where on phonegap.com??
>
> On Tue, Jun 25, 2013 at 9:59 AM, Ian Clelland
> wrote:
> > I thought I had updated all of these, but if you have seen some more that
> > are at www.phonegap.com, plea
There is not a well-defined order, but there is a partial ordering of
events. The two hard-coded dependencies are these:
deviceready <- (onCordovaReady, DOMContentLoaded) + plugin-defined
dependencies
onCordovaReady <- (onNativeReady, onPluginsReady)
However, because plugins can add themselves to
We've had that ticket open for some time now, and Braden has tried on a
couple of occasions to get some movement on it, but there's been no action
so far.
On Thu, Jul 4, 2013 at 12:34 PM, Filip Maj wrote:
> If you want to give it a shot, go for it!
>
> Didn't we have an INFRA issue filed for th
This is the first time I've tried to use the CLI tools with the new 3.0
project structure, and I've discovered that I can't uninstall a plugin that
only has dependencies (no source files, either JS or native)
Specifically, I've built a mobilespec app, installing
the mobile-spec-dependencies plugin
Thanks, Fil,
Created CB-4077 to track this. I'll start working on separating those
functions.
Ian
On Thu, Jul 4, 2013 at 7:08 PM, Filip Maj wrote:
> File an issue over at issues.cordova.io, tag plugman, and we can go from
> there
>
> On 7/4/13 12:59 PM, "Ian Clelland&quo
awkward), but do away with this ridiculous situation.
> > >
> > > Did I summarize that right?
> > >
> > >
> > > On Thu, Jul 4, 2013 at 1:01 PM, Brian LeRoux wrote:
> > >
> > >> So, what is the difference between master and master2? Right n
I'm not sure what you mean by "Undocumented" in this case -- it's not a
private API that would get you booted from the App Store; it's a documented
method on UIView, although it's been deprecated recently.[1]
Agreed that supporting the screen-orientation spec is probably the way to
go in the futur
There seem to be two competing methods for whitelisting domains with
subdomains, and support for each varies by platform.
- is supported on ios
- is supported on android as of CB-3854
- is backwards-compatible with previous versions of cordova
- is supported by cordova-cli
- is
>
> Should go without saying but lets not commit stuff without first
> ensuring the tests pass, eh.
>
>
> On Fri, Jul 5, 2013 at 10:05 AM, Filip Maj wrote:
> > Added comments to the issue thread. The tests no longer pass + we'll need
> > new tests to cover your c
towards this would be to allow the whitelist to
> > specify patterns that match against the full URL, and not just the
> domain.
> >
> > e.g.
> >
> >
> >
> >
> >
> > On Fri, Jul 5, 2013 at 2:05 PM, Ian Clelland >wrote:
> >
> >>
On Mon, Jul 8, 2013 at 9:49 PM, Andrew Grieve wrote:
> Yes! Most of us here have hit that exact problem, but I guess it hadn't
> made it to the ML yet.
>
> It's because Android's version script reports the version by parsing it out
> of the comment in the cordova.js file.
>
That's exactly it --
I've just re-enabled the vibration API on iOS and Android, in the
cordova-plugin-vibration repo.
As of now, I have all 270 auto tests passing on iPad and iPhone, and
everything except the accelerometer/compass tests passing in the simulator.
lish a new version of it to npm, update
> the dependency in cordova-cli, and make sure it is in working order with
> the new plugman before we proceed with a cli update.
>
> Sound good?
>
> On 7/5/13 12:01 PM, "Ian Clelland" wrote:
>
> >Oh, don't be sad, Bri
Per the "problems with the wiki instructions" thread, "Generate version
script
from create script" is now CB-4140.
On Tue, Jul 9, 2013 at 9:15 PM, Andrew Grieve wrote:
> I think this is doable. Here's the list of Cordova issues Google members
> are focusing on this week (in addition to :
>
>
>
On Tue, Jul 9, 2013 at 11:06 PM, Joe Bowser wrote:
> We're already going to have a heavy backlash from users who find that
> their old Cordova plugins that are using the old Plugin API that we
> had to shim in for 2.x are no longer going to work, this will
> literally be more salt on those wounds
On Wed, Jul 10, 2013 at 9:17 AM, Ian Clelland wrote:
> On Tue, Jul 9, 2013 at 11:06 PM, Joe Bowser wrote:
>
>> If someone wants to be the face of these change in the community, I'm
>>
> OK with it. I just know that from last year, being the guy who broke
>> all
works correctly.
I'll rebase my CLI against the newly-refreshed-master-branch and force push
it to github for you.
Ian
On Tue, Jul 9, 2013 at 10:49 PM, Ian Clelland wrote:
> Sounds good, Fil -- I'll take a look at the updates, and run it through
> its paces here. I'll let you
These files appear to be on the move from cordova-android, where they were
in the org.apache.cordova.file package, although I don't see a
corresponding commit in that repo to remove them.
I *think* that they are intended to stay in org.apache.cordova.file, and
the plugin.xml file is simply incorre
to the cli that integrates
> with the new plugman. Can you guys check that this branch works properly
> for any of your flows?
>
> I'll assume everything works out if I don't hear back from you guys and
> move forward with it later today.
>
> On 7/10/13 7:34 AM, "Ian
son (still full of plugins), and the
org.cordova.mobile-spec-dependencies plugin not removed.
On Thu, Jul 11, 2013 at 1:19 PM, Filip Maj wrote:
> Thank you Ian!
>
> On 7/11/13 10:17 AM, "Ian Clelland" wrote:
>
> >Taking a look now (Sorry I missed this thread yester
ed when it detects
> dependencies.
>
> I think it should be good to go now, I've published plugman 0.9.2 to npm
> with this fix. Can you give it one more shot on your end, just to be safe?
> I ran through your steps below with 0.9.2 and it worked for me.
>
> On 7/11/13 10
27;ve patched this, pushed as plugman@0.9.3, and updated the CB-4077 branch
> of cordova-cli to use the new plugman.
>
> Assuming it works out for you (I tested with the file plugin), I will
> merge back into master and publish a new cli version.
>
> On 7/11/13 12:51 PM, "Ian Clellan
On Fri, Jul 12, 2013 at 5:07 PM, Filip Maj wrote:
> Anyone get this to work? I'm not seeing any test executions
>
>
No, it doesn't look like they're running right now.
They were running (though failing) for me earlier today, but I was on
commit 0c80083.
Bisecting between that and HEAD shows tha
It's probably something simple, but I've created CB-4194 to track it in
case its more involved.
On Fri, Jul 12, 2013 at 10:26 PM, Ian Clelland wrote:
>
> On Fri, Jul 12, 2013 at 5:07 PM, Filip Maj wrote:
>
> Anyone get this to work? I'm not seeing any test execut
So, after spending two days typing out cordova-cli command lines by hand
(nice long ones like "cordova plugin rm
org.apache.cordova.core.file-transfer", mostly), I finally broke down and
added proper completion for my shell.
I've created a JIRA issue to hold the code, as a "New Feature" ticket. I'
previously)
Diffs
-
framework/src/org/apache/cordova/Config.java 6e0c147
framework/src/org/apache/cordova/Whitelist.java 736e5a7
Diff: https://reviews.apache.org/r/12548/diff/
Testing
---
This passes all of the recently-added whitelist tests in cordova-mobile-spec.
Thanks,
Ian
Thanks, guys!
Let me know what's broken :)
Ian
On Mon, Jul 15, 2013 at 8:52 AM, Lucas Holmquist wrote:
> coolio, i will be trying this
> On Jul 15, 2013, at 1:06 AM, Kerri Shotts wrote:
>
> >
> > Nice! I'll definitely be trying it out on my system!
> >
> >
> >
> >
> >
> > ___
Sorry for bringing this up really late --
We discovered that issue as well; the code was previously implemented for
iOS, so we concluded that the test was correct, and the Android
implementation was just lacking support.
It was logged as CB-4084, and David fixed it last week for 3.0.0.
Ian
On
it.
> > >>
> > >> I'll give the completion and shot and see how it works. I'll also buy
> > >>you a
> > >> beer if you're coming to Portland this week!
> > >>
> > >> Michael
> > >>
> > >>
That's right -- the issue was android-specific.
Ian
On Tue, Jul 16, 2013 at 2:32 PM, Shazron wrote:
> No need to re-get and re-tag JS right for the other platforms?
>
>
> On Tue, Jul 16, 2013 at 10:46 AM, Andrew Grieve >wrote:
>
> > Okay, seems it was a bad rebase when Ian made the base64 cha
ge up the patched cordova-js
and move it to cordova-android/framework/assets/www.
Ian
> On Tue, Jul 16, 2013 at 11:36 AM, Ian Clelland
> wrote:
> > That's right -- the issue was android-specific.
> >
> > Ian
> >
> >
> > On Tue, Jul 16, 2013 at 2:32 P
I've moved the latest cordova-js into cordova android, and pushed to
master. All of the mobilespec auto tests are passing for me. (With
mobile-spec-dependencies and all of its dependent plugins installed through
plugman)
Ian
On Tue, Jul 16, 2013 at 2:45 PM, Ian Clelland wrote:
> On
ue, Jul 16, 2013 at 3:14 PM, Joe Bowser wrote:
> I'm going to re-tag the JS. Since the only commit is this fix, none of
> the other platforms should need re-testing, but grabbing a random JS
> isn't the right way to do things, IMO.
>
> On Tue, Jul 16, 2013 at 11:58 AM, Ia
On Tue, Jul 16, 2013 at 3:53 PM, Filip Maj wrote:
> I guess it will. Fkn semver man
>
> I see a few workarounds:
>
> - massage any versions returned with 'rc' strings in it so they are semver
> compatible
>
Or append "-rc1" rather than "rc1" when we tag RC releases. Semver is cool
with that; it
implementation
Thanks,
Ian Clelland
I haven't received any comments on the new Android whitelist
implementation; it is working for me, passing all of the tests that I have
thrown at it.
There is an equivalent iOS version available at
https://reviews.apache.org/r/12668/
This also resolves CB-4132, wherein filetransfer.spec.5 is fail
/
Testing
---
This passes all of the recently-added whitelist tests in cordova-mobile-spec.
Thanks,
Ian Clelland
Diff: https://reviews.apache.org/r/12548/diff/
Testing
---
This passes all of the recently-added whitelist tests in cordova-mobile-spec.
Thanks,
Ian Clelland
-
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/12668/#review23280
-------
On July 17, 2013, 1:20 p.m., Ian Clelland wrote:
>
> ---
>
> > I don't think performance is an issue here, so probably a good idea to
> > just delete the cache.
Good catch. Deleted. It was there simply because the original implementation
was caching results.
- Ian
---------
://reviews.apache.org/r/12668/diff/
Testing
---
All mobilespec whitelist-related tests pass with this implementation
Thanks,
Ian Clelland
wrote:
> Which failing test?
>
> On Wed, Jul 17, 2013 at 6:26 AM, Ian Clelland
> wrote:
> > I haven't received any comments on the new Android whitelist
> > implementation; it is working for me, passing all of the tests that I
> have
> > thrown at it.
> >
&g
---
This passes all of the recently-added whitelist tests in cordova-mobile-spec.
Thanks,
Ian Clelland
MIssed this earlier, but here goes:
> If you are working with a `cordova` generated project then you can install
> using it. (Plugman is included in the Cordova install.)
I don't think this makes sense as a stand-alone paragraph -- I had to read
it four times to figure out what the word "it" ref
I think what I'd like to see is this:
cordova run : prepare, compile, deploy
cordova deploy : deploy only (existing compiled app)
Then we can make the published preferred workflow just "edit your code in
www; cordova run to test", while still exposing the low-level
interface for developers who k
I've been pretty happy with the state of my Bash command-line completion
script for CLI -- I'd like to add it to the CLI repo, and include some docs
there about installing it on Unix-y systems.
Any objections? Better places for it? Horrible crash reports?
Ian
on in Cordova CLI
>
> Yes I think this would be great. (Maybe add the docs to the cli guide tho?)
>
>
>
> On Wed, Jul 31, 2013 at 8:26 AM, Ian Clelland
> wrote:
> > I've been pretty happy with the state of my Bash command-line completion
> > script for CL
+1. That's a good approach to separating them, and should encourage
third-party authors to submit pieces -- knowing that Apache will drive
traffic to their site.
On Tue, Aug 6, 2013 at 1:35 PM, David Kemp wrote:
> +1 for Michals approach
>
>
> On Tue, Aug 6, 2013 at 1:27 PM, Michal Mocny wro
On Tue, Aug 6, 2013 at 2:01 PM, Filip Maj wrote:
> Will this mean we will be discussing blog post curation stuff on
> dev@cordova.apache.org ?
I hope that we can avoid a lot of that -- I'd hate for every potential
external contribution to come down to a discussion and vote on the mailing
list.
I think that's a good idea. If there are no platforms actually using this
signal to indicate anything useful, then nobody should be listening for it
to fire.
Deleting it now means that nobody ends up in a situation where they're
implicitly depending on a feature that we don't support, don't test,
>
> > Attendees: If you plan to attend, could you add your name to this list
> > (inline so that the list grows) and say whether you plan to be
> co-located:
> > agrieve, co-location=Google Waterloo
> > mmocny, co-location=Google Waterloo
> > maxw, co-location=Google Waterloo
> > aharding, co-loca
Does anyone know if the READ_PHONE_STATE permission is still required by
the Network Information plugin?
It isn't represented in the plugin.xml file, but it *is* listed in the
docs[1] as a required permission.
I can't see anywhere in the code where it would be required -- I think that
ACCESS_NETW
I'll remove it from the docs; mobile spec seems to run fine without the
permission, and it isn't being added by plugman anyway.
On Thu, Aug 8, 2013 at 6:29 PM, Filip Maj wrote:
> Probably doc error?
>
> On 8/8/13 11:44 AM, "Ian Clelland" wrote:
>
> >Do
On Wed, Aug 14, 2013 at 4:09 PM, Jesse wrote:
> I like the transparency of simply having a VERSION file at the root of any
> cordova project. Can't we just remove the extra steps with the git hash
> checking?
>
It used to be the case that Android would use the git hash of cordova-js as
it's ver
On Sun, Aug 18, 2013 at 12:54 PM, Jonathan Bond-Caron <
jbo...@gdesolutions.com> wrote:
> I participated at a #hackmtl event in Montreal and thought it would be a
> good opportunity to try building a 'Cordova Gesture' plugin:
> https://github.com/jbondc/cordova-plugin-gesture
That looks really i
On Fri, Aug 16, 2013 at 5:41 PM, Andrew Grieve wrote:
> After the discussion on the group hangout + some sleeping, I think we're
> ready for a proposal... So here it is!
> - It does *not* propose any changes to our Deprecation policy. That's for
> another thread (which I'll get to on Monday if no
On Mon, Aug 19, 2013 at 4:29 AM, Jesse wrote:
> Okay, took me awhile to get this out, I should know better than to promise
> to start a new threads on Friday afternoon. XD
>
> Split from 'Releases in a 3.0 World'
>
> RE: Pasted =>
>
> > cordova-plugins:
> > - Commit only to the `dev` branch
> >
e
master/dev split, or to do something different.
Ian
>
> On Mon, Aug 19, 2013 at 9:23 AM, Ian Clelland >wrote:
>
> > On Mon, Aug 19, 2013 at 4:29 AM, Jesse wrote:
> >
> > > Okay, took me awhile to get this out, I should know better than to
> > promis
For Mobile Chrome Apps, we have a need to subclass the CordovaChromeClient
class used by our applications. There's not currently a way to do that in
the CLI world
Also, in [this thread][1], there has been some discussion of plumbing
additional WebView callback methods to plugins. I think that it'
On Mon, Aug 19, 2013 at 4:43 PM, Joe Bowser wrote:
> On Mon, Aug 19, 2013 at 11:40 AM, Ian Clelland
> wrote:
> > For Mobile Chrome Apps, we have a need to subclass the
> CordovaChromeClient
> > class used by our applications. There's not currently a way to do t
On Thu, Aug 22, 2013 at 11:17 AM, Braden Shepherdson wrote:
> On Thu, Aug 22, 2013 at 9:06 AM, Jan Becicka
> wrote:
>
> >
> > * Cordova CLI does not support iOS Devices. (cordova run ios). Are there
> > any plans to support it in near future?
> >
>
> Platform parity is a goal for sure. I don't
itional overrides are necessary.
> >
> > Sent from my Windows Phone From: jbo...@openmv.com
> > Sent: 20/08/2013 23:12
> > To: dev@cordova.apache.org
> > Subject: RE: Extending CordovaWebView
> > On Mon Aug 19 05:21 PM, Ian Clelland wrote:
> > > On Mon,
On Thu, Aug 22, 2013 at 11:11 AM, Braden Shepherdson wrote:
> Are you sure you ran a "cordova prepare" in both cases? There should be a
> tag for Camera on both platforms, as far as I know.
>
>
That was my thinking as well. I checked earlier, and there definitely is a
feature tag for iOS. (It's t
On Thu, Aug 22, 2013 at 1:49 PM, Joe Bowser wrote:
> On Thu, Aug 22, 2013 at 10:43 AM, Ian Clelland
> wrote:
> > After thinking about this for a couple of days, and discussing with
> Andrew
> > and Michal here, it seem that there are definitely (at least) two
> d
On Thu, Aug 22, 2013 at 8:43 PM, Ally Ogilvie wrote:
> > First is that there is no way to use a custom WebView / WebViewClient /
> > ChromeClient class within the CLI system, without writing custom native
> > code after your project has been created.
>
> Not sure about the CLI system, don't reall
I checked out mobile spec yesterday on a couple of iOS 7 devices (beta 3
and beta 6), running a 6.1-target build as well as a fresh build with the
latest 7 sdk. I didn't see any regressions; all of the auto tests pass, and
the manual tests behave sanely. Some of the UI "felt" less responsive than
I
in plugins for maximum
> awesomeness.
>
> Sent from my Windows Phone From: Ian Clelland
> Sent: 23/08/2013 23:41
> To: dev@cordova.apache.org
> Subject: Re: Extending CordovaWebView
> On Thu, Aug 22, 2013 at 8:43 PM, Ally Ogilvie wrote:
>
> > > First is that there is
This looks like a direct port of cordova-android commit #07439ff9 to
InAppBrowser.
The actual setting controls whether file:///* urls are allowed to execute
JavaScript from any context; it is usually false for browsers (at least
Chrome) for security reasons. We turn it on for the main Cordova WebV
Does this mean that the discussion in [this thread][
http://apache.markmail.org/thread/h2vgb6zwuxa74usf] is out of date? A
couple of weeks ago, it seemed that lib-file was bb10-specific; it's
clearly not anymore. Should we test its support on other platforms as well
now?
On Mon, Aug 26, 2013 at 2
On Tue, Aug 27, 2013 at 1:11 PM, Axel Nennker wrote:
> I think that that thread is related but more fundamental.
> The doc doesn't say that lib-file is bb10 only. It gives bb10 as an
> example. So lib-file should not crash plugman on Android with an unhelpful
> error message. In fact I needed lib
It looks like https://github.com/apache/cordova-cli is not properly
following the apache repo -- the last commit on github is three weeks old,
and there has certainly been some development on CLI since then.
Is this something to open an INFRA ticket for?
Ian
>From the discussion on CB-4684, it looks like the latest CLI (3.0.7) is
broken on non-windows environments.
The line endings have changed from \n to \r\n, and Bash is confused.
The quick fix seems to be to republish from Unix, and declare "Don't
publish from a Windows machine".
I feel like ther
Yes, by 4684, I mean 4686 :)
Thanks
On Wed, Aug 28, 2013 at 11:44 AM, Shazron wrote:
> CB-4686 actually
> https://issues.apache.org/jira/browse/CB-4686
>
>
> On Wed, Aug 28, 2013 at 10:19 PM, Ian Clelland >wrote:
>
> > From the discussion on CB-4684, it looks lik
1 - 100 of 656 matches
Mail list logo
