date:20121115

Re: [Android] Can everyone run the tests?

2012-11-15 Thread Andrew Grieve

Awesome. The steps to run it in eclipse would be a good addition as well.
I'll sign up to add the iOS unit test instructions.


On Thu, Nov 15, 2012 at 8:11 PM, Joe Bowser  wrote:

> Web Driver is not necessary to run the tests.  I'll get the command line
> version working tomorrow.
> On Nov 15, 2012 5:05 PM, "Andrew Grieve"  wrote:
>
> > Started to update wiki instructions... but what is the correct last step?
> >
> > === To run these tests from the command line: ===
> > 1. Install "Google Web Driver" through the Android SKD Manager
> > 1. Copy the extras/google/webdriver/android_webdriver_library.jar from
> the
> > Android SDK into the framework/libs directory
> > 1. Build Cordova by running "ant" from within the framework directory
> > 1. Run the following command in the framework directory with a device
> > attached or emulator running:
> > adb shell am instrument -w
> > com.phonegap/android.test.InstrumentationTestRunner
> >
> >
> >
> > On Wed, Nov 14, 2012 at 9:24 PM, Andrew Grieve 
> > wrote:
> >
> > > Tried to follow the command-line instructions but get:
> > >
> > > agrieve@dhcp-172-23-181-44 ~/git/incubator-cordova-android/framework
> > > (asdf) $ adb shell am instrument -w
> > > com.phonegap/android.test.InstrumentationTestRunner
> > > INSTRUMENTATION_STATUS: id=ActivityManagerService
> > > INSTRUMENTATION_STATUS: Error=Unable to find instrumentation info for:
> > > ComponentInfo{com.phonegap/android.test.InstrumentationTestRunner}
> > > INSTRUMENTATION_STATUS_CODE: -1
> > > android.util.AndroidException: INSTRUMENTATION_FAILED:
> > > com.phonegap/android.test.InstrumentationTestRunner
> > >
> > > Changing to org.apache.cordova:
> > > agrieve@dhcp-172-23-181-44 ~/git/incubator-cordova-android/framework
> > > (asdf) $ adb shell am instrument -w
> > > org.apache.cordova/android.test.InstrumentationTestRunner
> > > android.util.AndroidException: INSTRUMENTATION_FAILED:
> > > org.apache.cordova/android.test.InstrumentationTestRunner
> > >
> > > On Wed, Nov 14, 2012 at 4:41 PM, Simon MacDonald <
> > > simon.macdon...@gmail.com> wrote:
> > >
> > >> Yup, it passed when I ran it and only it.
> > >>
> > >> Simon Mac Donald
> > >> http://hi.im/simonmacdonald
> > >>
> > >>
> > >> On Wed, Nov 14, 2012 at 4:35 PM, Joe Bowser 
> wrote:
> > >>
> > >> > How can testPreconditions fail, but testViaLoadUrl pass? Can you run
> > >> > the test by itself? testViaHref is known to fail, and there's an
> issue
> > >> > open about that bug.
> > >> >
> > >>
> > >
> > >
> >
>

[jira] [Commented] (CB-1185) When Application is placed in background and resumed, the UI is frozen

2012-11-15 Thread Lindsey Simon (JIRA)


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

Lindsey Simon commented on CB-1185:
---

[~gregavola] Have you found any time or some such consistent method to get it 
to go into full-on ANR? I saw the lag when I repro-d it, but not the full on 
crash.

> When Application is placed in background and resumed, the UI is frozen
> --
>
> Key: CB-1185
> URL: https://issues.apache.org/jira/browse/CB-1185
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 2.0.0
> Environment: Jelly Bean 4.1, ICS 4.0.x
>Reporter: Greg
>Assignee: Joe Bowser
> Attachments: 0001-Fix-issue-with-pause-resume-freezing-the-UI.patch, 
> 0002-Uncomment.patch, cordova-2.0.0.jar, issues.zip
>
>
> When using PhoneGap 2.0.0 on ICS or JellyBean, the application freezes up 
> after you set the app to the background or turn of the screen. After around 
> 3-7 seconds, the application unfreezes and pretty much causes a panic and 
> usually crashes. No error reports have been submitted.
> Here is how you re-produce the issue:
> 1. Download Untappd - 
> V2.0.4(https://play.google.com/store/apps/details?id=com.untappdllc.app)
> 2. After logging in stay on the Friends tab
> 3. Turn the the screen off and wait about 3-7 minutes
> 4. Turn the screen back on, and the interface should be frozen.
> Another possible path to re-producing the issue:
> 1. Download Untappd - 
> V2.0.4(https://play.google.com/store/apps/details?id=com.untappdllc.app)
> 2. After logging in stay on the Friends tab
> 3. Go back to the home screen then use other apps for about 3-7 minutes.
> 4. Go back into Untappd, and the interface should be frozen.
> When the app is frozen, native menu buttons will not nor any options in the 
> UI. 
> Would love to see if anyone can replicate this. I've tested this on Jelly 
> Bean 4.1.x on a Samsung Galaxy Nexus, but users have been having this problem 
> majority on ICS (4.0.x)
> Thanks,
> Greg

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [Android] Can everyone run the tests?

2012-11-15 Thread Joe Bowser

Web Driver is not necessary to run the tests.  I'll get the command line
version working tomorrow.
On Nov 15, 2012 5:05 PM, "Andrew Grieve"  wrote:

> Started to update wiki instructions... but what is the correct last step?
>
> === To run these tests from the command line: ===
> 1. Install "Google Web Driver" through the Android SKD Manager
> 1. Copy the extras/google/webdriver/android_webdriver_library.jar from the
> Android SDK into the framework/libs directory
> 1. Build Cordova by running "ant" from within the framework directory
> 1. Run the following command in the framework directory with a device
> attached or emulator running:
> adb shell am instrument -w
> com.phonegap/android.test.InstrumentationTestRunner
>
>
>
> On Wed, Nov 14, 2012 at 9:24 PM, Andrew Grieve 
> wrote:
>
> > Tried to follow the command-line instructions but get:
> >
> > agrieve@dhcp-172-23-181-44 ~/git/incubator-cordova-android/framework
> > (asdf) $ adb shell am instrument -w
> > com.phonegap/android.test.InstrumentationTestRunner
> > INSTRUMENTATION_STATUS: id=ActivityManagerService
> > INSTRUMENTATION_STATUS: Error=Unable to find instrumentation info for:
> > ComponentInfo{com.phonegap/android.test.InstrumentationTestRunner}
> > INSTRUMENTATION_STATUS_CODE: -1
> > android.util.AndroidException: INSTRUMENTATION_FAILED:
> > com.phonegap/android.test.InstrumentationTestRunner
> >
> > Changing to org.apache.cordova:
> > agrieve@dhcp-172-23-181-44 ~/git/incubator-cordova-android/framework
> > (asdf) $ adb shell am instrument -w
> > org.apache.cordova/android.test.InstrumentationTestRunner
> > android.util.AndroidException: INSTRUMENTATION_FAILED:
> > org.apache.cordova/android.test.InstrumentationTestRunner
> >
> > On Wed, Nov 14, 2012 at 4:41 PM, Simon MacDonald <
> > simon.macdon...@gmail.com> wrote:
> >
> >> Yup, it passed when I ran it and only it.
> >>
> >> Simon Mac Donald
> >> http://hi.im/simonmacdonald
> >>
> >>
> >> On Wed, Nov 14, 2012 at 4:35 PM, Joe Bowser  wrote:
> >>
> >> > How can testPreconditions fail, but testViaLoadUrl pass? Can you run
> >> > the test by itself? testViaHref is known to fail, and there's an issue
> >> > open about that bug.
> >> >
> >>
> >
> >
>

Re: [Android] Can everyone run the tests?

2012-11-15 Thread Andrew Grieve

Started to update wiki instructions... but what is the correct last step?

=== To run these tests from the command line: ===
1. Install "Google Web Driver" through the Android SKD Manager
1. Copy the extras/google/webdriver/android_webdriver_library.jar from the
Android SDK into the framework/libs directory
1. Build Cordova by running "ant" from within the framework directory
1. Run the following command in the framework directory with a device
attached or emulator running:
adb shell am instrument -w
com.phonegap/android.test.InstrumentationTestRunner

On Wed, Nov 14, 2012 at 9:24 PM, Andrew Grieve  wrote:

> Tried to follow the command-line instructions but get:
>
> agrieve@dhcp-172-23-181-44 ~/git/incubator-cordova-android/framework
> (asdf) $ adb shell am instrument -w
> com.phonegap/android.test.InstrumentationTestRunner
> INSTRUMENTATION_STATUS: id=ActivityManagerService
> INSTRUMENTATION_STATUS: Error=Unable to find instrumentation info for:
> ComponentInfo{com.phonegap/android.test.InstrumentationTestRunner}
> INSTRUMENTATION_STATUS_CODE: -1
> android.util.AndroidException: INSTRUMENTATION_FAILED:
> com.phonegap/android.test.InstrumentationTestRunner
>
> Changing to org.apache.cordova:
> agrieve@dhcp-172-23-181-44 ~/git/incubator-cordova-android/framework
> (asdf) $ adb shell am instrument -w
> org.apache.cordova/android.test.InstrumentationTestRunner
> android.util.AndroidException: INSTRUMENTATION_FAILED:
> org.apache.cordova/android.test.InstrumentationTestRunner
>
> On Wed, Nov 14, 2012 at 4:41 PM, Simon MacDonald <
> simon.macdon...@gmail.com> wrote:
>
>> Yup, it passed when I ran it and only it.
>>
>> Simon Mac Donald
>> http://hi.im/simonmacdonald
>>
>>
>> On Wed, Nov 14, 2012 at 4:35 PM, Joe Bowser  wrote:
>>
>> > How can testPreconditions fail, but testViaLoadUrl pass? Can you run
>> > the test by itself? testViaHref is known to fail, and there's an issue
>> > open about that bug.
>> >
>>
>
>

[jira] [Commented] (CB-1810) CordovaWebView does not work as a component without providing it a ThreadPool

2012-11-15 Thread Andrew Grieve (JIRA)


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

Andrew Grieve commented on CB-1810:
---

I don't have any concrete examples, but I think it would be reasonable to have 
multiple webviews within a tablet app. e.g. have a native UI that embeds 
cordova webviews on separate panes.

It's also reasonable to have multiple activities that each contain cordova 
webviews.

Webviews having their own plugins I think works quite well. If they want to 
share data between webviews, they can use statics, but usually they want to 
have data specific to a webview.

> CordovaWebView does not work as a component without providing it a ThreadPool
> -
>
> Key: CB-1810
> URL: https://issues.apache.org/jira/browse/CB-1810
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 2.2.0
>Reporter: Joe Bowser
>Assignee: Andrew Grieve
>Priority: Blocker
> Fix For: 2.3.0
>
>
> Apparently CordovaWebView no longer works as a stand-alone component.  We may 
> have to release a 2.2.1 because of this issue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (CB-1803) testHref test fails when running the back button test case

2012-11-15 Thread Joe Bowser (JIRA)


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

Joe Bowser resolved CB-1803.


Resolution: Cannot Reproduce

The problem went away when I added the button press tests.

> testHref test fails when running the back button test case
> --
>
> Key: CB-1803
> URL: https://issues.apache.org/jira/browse/CB-1803
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 2.2.0
>Reporter: Joe Bowser
>Assignee: Joe Bowser
> Fix For: 2.3.0
>
>
> When running the JUnit Tests, it seems that the href test fails when we 
> navigate from page to page.  This needs to be investigated.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (CB-573) Automate Backbutton jQM tab test

2012-11-15 Thread Joe Bowser (JIRA)


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

Joe Bowser reassigned CB-573:
-

Assignee: Joe Bowser  (was: Filip Maj)

> Automate Backbutton jQM tab test
> 
>
> Key: CB-573
> URL: https://issues.apache.org/jira/browse/CB-573
> Project: Apache Cordova
>  Issue Type: Test
>  Components: Android
>Reporter: Joe Bowser
>Assignee: Joe Bowser
> Fix For: 2.3.0
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CB-1810) CordovaWebView does not work as a component without providing it a ThreadPool

2012-11-15 Thread Joe Bowser (JIRA)


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

Joe Bowser commented on CB-1810:


I guess CordovaInterface would have to be a singleton.  A CordovaInterface 
could have many views.  Do we have a use case for more than one CordovaWebView 
out there?  Also, the prospect of each CordovaWebView having their own plugins 
makes things a bit crazy.

> CordovaWebView does not work as a component without providing it a ThreadPool
> -
>
> Key: CB-1810
> URL: https://issues.apache.org/jira/browse/CB-1810
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 2.2.0
>Reporter: Joe Bowser
>Assignee: Andrew Grieve
>Priority: Blocker
> Fix For: 2.3.0
>
>
> Apparently CordovaWebView no longer works as a stand-alone component.  We may 
> have to release a 2.2.1 because of this issue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CB-1810) CordovaWebView does not work as a component without providing it a ThreadPool

2012-11-15 Thread Andrew Grieve (JIRA)


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

Andrew Grieve commented on CB-1810:
---

My thinking for putting it in CordovaInterface was that it would make it a 
sibling of getActivity(). 

In the context of plugins, you have:

 * This method is called from the WebView thread. To do a non-trivial 
amount of work, use:
 * cordova.getThreadPool().execute(runnable);
 *
 * To run on the UI thread, use:
 * cordova.getActivity().runOnUiThread(runnable);


I suppose we could change this to webView.getThreadPool().

The thread pool is meant to be an app-wide singleton. I was thinking that 
CordovaInterface would probably a singleton, but CordovaWebview isn't since you 
can have multiple views, either at the same time or one after another.

> CordovaWebView does not work as a component without providing it a ThreadPool
> -
>
> Key: CB-1810
> URL: https://issues.apache.org/jira/browse/CB-1810
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 2.2.0
>Reporter: Joe Bowser
>Assignee: Andrew Grieve
>Priority: Blocker
> Fix For: 2.3.0
>
>
> Apparently CordovaWebView no longer works as a stand-alone component.  We may 
> have to release a 2.2.1 because of this issue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CB-1864) Back Button breaks too often, needs better tests

2012-11-15 Thread Joe Bowser (JIRA)


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

Joe Bowser commented on CB-1864:


https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-android.git;a=commit;h=6c19a440f5d7faa3955e039749a3a907af012acc

> Back Button breaks too often, needs better tests
> 
>
> Key: CB-1864
> URL: https://issues.apache.org/jira/browse/CB-1864
> Project: Apache Cordova
>  Issue Type: Test
>  Components: Android
>Affects Versions: 2.3.0
>Reporter: Joe Bowser
>Assignee: Joe Bowser
>Priority: Critical
> Fix For: 2.3.0
>
>
> Switched branches, broke back button.  Did eclipse clean, back button works 
> fine again.  We need tests for this!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (CB-1864) Back Button breaks too often, needs better tests

2012-11-15 Thread Joe Bowser (JIRA)


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

Joe Bowser resolved CB-1864.


Resolution: Fixed

HURRAY! Figured out how to trigger the back button programmatically! :D

> Back Button breaks too often, needs better tests
> 
>
> Key: CB-1864
> URL: https://issues.apache.org/jira/browse/CB-1864
> Project: Apache Cordova
>  Issue Type: Test
>  Components: Android
>Affects Versions: 2.3.0
>Reporter: Joe Bowser
>Assignee: Joe Bowser
>Priority: Critical
> Fix For: 2.3.0
>
>
> Switched branches, broke back button.  Did eclipse clean, back button works 
> fine again.  We need tests for this!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: cordova-js fails on windows 7

2012-11-15 Thread Jesse

Yes, that is all the test BS, which is hooped on windows, and IMHO not
worth the work.
I just use:
jake build
or
jake btest



On Thu, Nov 15, 2012 at 3:49 PM, Anis KADRI  wrote:
> Better but I am still getting this http://pastebin.com/qKcuy91E
>
>
> On Thu, Nov 15, 2012 at 9:56 AM, Jesse MacFadyen 
> wrote:
>
>> Not using it, but the build was broken for windows devs.
>>
>> Cheers,
>>   Jesse
>>
>> Sent from my iPhone5
>>
>> On 2012-11-15, at 6:19 AM, Gord Tanner  wrote:
>>
>> > Yeah, I moved the debug versions of Cordova.js into a debug folder.
>> >
>> > What are you using the debug version for?
>> >
>> > Sent from my iPhone
>> >
>> > On 2012-11-15, at 1:37 AM, Jesse  wrote:
>> >
>> >> Actually, it was here:
>> >> https://github.com/apache/incubator-cordova-js/blob/master/Jakefile#L73
>> >>
>> >> I have pushed the fix.
>> >> Cheers,
>> >> Jesse
>> >>
>> >> On Wed, Nov 14, 2012 at 10:14 PM, Jesse 
>> wrote:
>> >>> Yet another windows vs unix path building issue.
>> >>>
>> >>>
>> https://github.com/apache/incubator-cordova-js/blob/ce50b72632cc861014a58db563becea48c426772/build/packager.js#L40
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> On Wed, Nov 14, 2012 at 6:07 PM, Anis KADRI 
>> wrote:
>>  ...with:
>> 
>>  building commit ce50b72632cc861014a58db563becea48c426772
>>  jake aborted.
>>  Error: ENOENT, no such file or directory
>>  'c:\Users\anis\cordova\incubator-cordov
>>  a-js\pkg\debug\cordova.windows8-debug.js'
>>    at Object.openSync (fs.js:238:18)
>>  (See full trace by running task with --trace)
>> 
>>  What happened ? Looks like the packager is broken. Any ideas ?
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> @purplecabbage
>> >>> risingj.com
>> >>
>> >>
>> >>
>> >> --
>> >> @purplecabbage
>> >> risingj.com
>>



-- 
@purplecabbage
risingj.com

Re: InAppBrowser api questions

2012-11-15 Thread Shazron

I updated the spec: http://wiki.apache.org/cordova/InAppBrowser
However, I added the _blank option as well just to be explicit.


On Thu, Nov 15, 2012 at 1:58 AM, Shazron  wrote:

>
> I spent some time playing with how to do this.
>> 1 - Use referer header - Too many situations result in no header, so this
>> is out!
>> 2 - Use Cookies - if there were a way to have UIWebViews use separate
>> cookie jars, this might be feasible. Don't think that's possible.
>> 3 - Use User-Agent - this is already suggested in CB-1695. I also found
>> this:
>>
>> http://stackoverflow.com/questions/12180224/unique-tab-id-appended-to-user-agent-string-in-chrome-for-ios
>> ,
>> which suggests that this is what Chrome for iOS uses to implement
>> incognito
>> mode. If they can make it work, then we should be able to as well!
>>
>> So, this is looking like it's non-trivial but not impossible! As long as
>> it's possible, let's implement it :)
>>
>>
> Looks like it may be possible in CB-1695 as you mentioned -- so we can
> finish InAppBrowser with this one failing case until it is implemented. I
> can look into this further once I finish the InAppBrowser integration.
>
>
>> I don't think the semantics of _parent and _blank really map well to what
>>  we're doing. My vote is to create a new special value: _system, and only
>> this target kicks you out to the system browser.
>>
>> Also: on the wiki we have:
>> [F]  window.open('http://random-url.com', '_blank'); // native browser
>>
>> It seems weird to me that the effect of _blank changes based on whether
>> the
>> URL is in the whitelist. I'd think this case would also open in the
>> InAppBrowser.
>>
>>
>> Summary of what I think:
>> _self or no target --> open in cordova webview if it's in the Whitelist,
>> InAppBrowser otherwise
>> _system --> open in system browser
>> anything else --> open in InAppBrowser
>>
>> Also, I like Simon's idea of using the options in window.open to specify
>> whether to show URL bar etc. :)
>>
>
> I agree, we need a new value "_system" as you suggested, as well as the
> other parts of the summary of your changes -- makes more sense, and if used
> in another context -- it will just work as expected. I can make the wiki
> changes unless others have more comments.
>
> We can definitely add the window options as well, for sure!
>
>

[jira] [Commented] (CB-1404) EXC_BAD_ACCESS when using XHR_WITH_PAYLOAD bridge mode

2012-11-15 Thread Andrew Grieve (JIRA)


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

Andrew Grieve commented on CB-1404:
---

I added some logging to the exec bridge to try and figure out what's going on. 
The app is a bit hard for me to follow what's going on, and I'm having a hard 
time figuring out if it's a cordova problem, or just a problem with your app.

Here are the logs with all bridge calls logged:

2012-11-15 18:48:58.830 AudioRecall[33258:c07] Multi-tasking -> Device: YES, 
App: YES
2012-11-15 18:48:59.075 AudioRecall[33258:c07] [LOG] exec() 
NetworkStatus.getConnectionInfo ID=NetworkStatus727560950 args=[]
2012-11-15 18:48:59.076 AudioRecall[33258:c07] [LOG] exec() 
Device.getDeviceInfo ID=Device727560951 args=[]
2012-11-15 18:48:59.078 AudioRecall[33258:c07] [LOG] exec() CALLBACK: 
id=NetworkStatus727560950 status=1 args=["wifi"]
2012-11-15 18:48:59.078 AudioRecall[33258:c07] [LOG] exec() CALLBACK: 
id=Device727560951 status=1 args=[{"name":"iPhone 
Simulator","uuid":"73B3D5D9-74A2-46D5-A1A4-01EFB5241C7F","platform":"iPhone 
Simulator","version":"6.0","cordova":"2.2.0"}]
2012-11-15 18:48:59.083 AudioRecall[33258:c07] [LOG] 
deviceready##
2012-11-15 18:48:59.083 AudioRecall[33258:c07] [LOG] exec() 
File.requestFileSystem ID=File727560952 args=[0,0]
2012-11-15 18:48:59.085 AudioRecall[33258:c07] [LOG] exec() CALLBACK: 
id=File727560952 status=1 
args=[{"name":"temporary","root":{"name":"tmp","isFile":false,"isDirectory":true,"fullPath":"/Users/agrieve/Library/Application
 Support/iPhone 
Simulator/6.0/Applications/FF5092AB-FBFD-4B11-B50D-C5EFDC73185F/tmp"}}]
2012-11-15 18:48:59.086 AudioRecall[33258:c07] [LOG] exec() File.readEntries 
ID=File727560953 args=["/Users/agrieve/Library/Application Support/iPhone 
Simulator/6.0/Applications/FF5092AB-FBFD-4B11-B50D-C5EFDC73185F/tmp"]
2012-11-15 18:48:59.087 AudioRecall[33258:c07] [LOG] exec() CALLBACK: 
id=File727560953 status=1 
args=[[{"name":"audio0.wav","isFile":true,"isDirectory":false,"fullPath":"/Users/agrieve/Library/Application
 Support/iPhone 
Simulator/6.0/Applications/FF5092AB-FBFD-4B11-B50D-C5EFDC73185F/tmp/audio0.wav"},{"name":"audio1.wav","isFile":true,"isDirectory":false,"fullPath":"/Users/agrieve/Library/Application
 Support/iPhone 
Simulator/6.0/Applications/FF5092AB-FBFD-4B11-B50D-C5EFDC73185F/tmp/audio1.wav"}]]
2012-11-15 18:48:59.088 AudioRecall[33258:c07] [LOG] exec() File.getFile 
ID=File727560954 args=["/Users/agrieve/Library/Application Support/iPhone 
Simulator/6.0/Applications/FF5092AB-FBFD-4B11-B50D-C5EFDC73185F/tmp","audio0.wav",{}]
2012-11-15 18:48:59.089 AudioRecall[33258:c07] [LOG] exec() File.getFile 
ID=File727560955 args=["/Users/agrieve/Library/Application Support/iPhone 
Simulator/6.0/Applications/FF5092AB-FBFD-4B11-B50D-C5EFDC73185F/tmp","audio1.wav",{}]
2012-11-15 18:48:59.089 AudioRecall[33258:c07] [LOG] exec() CALLBACK: 
id=File727560954 status=1 
args=[{"name":"audio0.wav","isFile":true,"isDirectory":false,"fullPath":"/Users/agrieve/Library/Application
 Support/iPhone 
Simulator/6.0/Applications/FF5092AB-FBFD-4B11-B50D-C5EFDC73185F/tmp/audio0.wav"}]
2012-11-15 18:48:59.090 AudioRecall[33258:c07] [LOG] exec() CALLBACK: 
id=File727560955 status=1 
args=[{"name":"audio1.wav","isFile":true,"isDirectory":false,"fullPath":"/Users/agrieve/Library/Application
 Support/iPhone 
Simulator/6.0/Applications/FF5092AB-FBFD-4B11-B50D-C5EFDC73185F/tmp/audio1.wav"}]
2012-11-15 18:48:59.091 AudioRecall[33258:c07] [LOG] exec() 
File.requestFileSystem ID=File727560956 args=[1,0]
2012-11-15 18:48:59.093 AudioRecall[33258:c07] [LOG] exec() CALLBACK: 
id=File727560956 status=1 
args=[{"name":"persistent","root":{"name":"Documents","isFile":false,"isDirectory":true,"fullPath":"/Users/agrieve/Library/Application
 Support/iPhone 
Simulator/6.0/Applications/FF5092AB-FBFD-4B11-B50D-C5EFDC73185F/Documents"}}]
2012-11-15 18:48:59.093 AudioRecall[33258:c07] [LOG] exec() File.getDirectory 
ID=File727560957 args=["/Users/agrieve/Library/Application Support/iPhone 
Simulator/6.0/Applications/FF5092AB-FBFD-4B11-B50D-C5EFDC73185F/Documents","SAVED",{"create":false}]
2012-11-15 18:48:59.094 AudioRecall[33258:c07] [LOG] exec() CALLBACK: 
id=File727560957 status=1 
args=[{"name":"SAVED","isFile":false,"isDirectory":true,"fullPath":"/Users/agrieve/Library/Application
 Support/iPhone 
Simulator/6.0/Applications/FF5092AB-FBFD-4B11-B50D-C5EFDC73185F/Documents/SAVED"}]
2012-11-15 18:48:59.096 AudioRecall[33258:c07] [LOG] changing mode from 
UNDEFINED to SLEEP
2012-11-15 18:49:00.996 AudioRecall[33258:c07] [LOG] changing mode from SLEEP 
to LISTEN
2012-11-15 18:49:00.996 AudioRecall[33258:c07] [LOG] buffer0, was UNUSED, will 
mark STARTED
2012-11-15 18:49:00.998 AudioRecall[33258:c07] [LOG] buffer0 changing from 
UNUSED to STARTED, reason='sLOB'
2012-11-15 18:49:00.999 Au

Re: cordova-js fails on windows 7

2012-11-15 Thread Anis KADRI

Better but I am still getting this http://pastebin.com/qKcuy91E


On Thu, Nov 15, 2012 at 9:56 AM, Jesse MacFadyen wrote:

> Not using it, but the build was broken for windows devs.
>
> Cheers,
>   Jesse
>
> Sent from my iPhone5
>
> On 2012-11-15, at 6:19 AM, Gord Tanner  wrote:
>
> > Yeah, I moved the debug versions of Cordova.js into a debug folder.
> >
> > What are you using the debug version for?
> >
> > Sent from my iPhone
> >
> > On 2012-11-15, at 1:37 AM, Jesse  wrote:
> >
> >> Actually, it was here:
> >> https://github.com/apache/incubator-cordova-js/blob/master/Jakefile#L73
> >>
> >> I have pushed the fix.
> >> Cheers,
> >> Jesse
> >>
> >> On Wed, Nov 14, 2012 at 10:14 PM, Jesse 
> wrote:
> >>> Yet another windows vs unix path building issue.
> >>>
> >>>
> https://github.com/apache/incubator-cordova-js/blob/ce50b72632cc861014a58db563becea48c426772/build/packager.js#L40
> >>>
> >>>
> >>>
> >>>
> >>> On Wed, Nov 14, 2012 at 6:07 PM, Anis KADRI 
> wrote:
>  ...with:
> 
>  building commit ce50b72632cc861014a58db563becea48c426772
>  jake aborted.
>  Error: ENOENT, no such file or directory
>  'c:\Users\anis\cordova\incubator-cordov
>  a-js\pkg\debug\cordova.windows8-debug.js'
>    at Object.openSync (fs.js:238:18)
>  (See full trace by running task with --trace)
> 
>  What happened ? Looks like the packager is broken. Any ideas ?
> >>>
> >>>
> >>>
> >>> --
> >>> @purplecabbage
> >>> risingj.com
> >>
> >>
> >>
> >> --
> >> @purplecabbage
> >> risingj.com
>

[jira] [Assigned] (CB-1810) CordovaWebView does not work as a component without providing it a ThreadPool

2012-11-15 Thread Joe Bowser (JIRA)


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

Joe Bowser reassigned CB-1810:
--

Assignee: Andrew Grieve  (was: Joe Bowser)

I want to put this in the WebView object.  Do you know any reason why this 
shouldn't go there?

> CordovaWebView does not work as a component without providing it a ThreadPool
> -
>
> Key: CB-1810
> URL: https://issues.apache.org/jira/browse/CB-1810
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 2.2.0
>Reporter: Joe Bowser
>Assignee: Andrew Grieve
>Priority: Blocker
> Fix For: 2.3.0
>
>
> Apparently CordovaWebView no longer works as a stand-alone component.  We may 
> have to release a 2.2.1 because of this issue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Changes to the JS?

2012-11-15 Thread Andrew Grieve

Whoops, didn't notice that! Done!


On Thu, Nov 15, 2012 at 4:25 PM, Simon MacDonald
wrote:

> Yup, all File tests are passing for me too. In FileTransfer only one of
> the abort tests fails to run. BTW this thread is only me and you. You might
> want to post to the list letting them know everything is back to normal.
>
> Simon Mac Donald
> http://hi.im/simonmacdonald
>
>
> On Thu, Nov 15, 2012 at 4:20 PM, Andrew Grieve wrote:
>
>> Okay, just pushed and have run spec tests before / after changes. They
>> File ones failed before and are fixed now.
>>
>> I'm seeing file transfer tests failing as well as contact ones. The
>> contact ones have always been flakey for me, but I'm not sure what's up
>> with FT. Maybe because I upgraded to 4.2? I'll have to look into it.
>>
>>
>> On Thu, Nov 15, 2012 at 3:34 PM, Andrew Grieve wrote:
>>
>>> I didn't. I'm just about finished the rename from
>>> objects->defaults/clobbers and then will run the tests.
>>>
>>>
>>> On Thu, Nov 15, 2012 at 3:32 PM, Simon MacDonald <
>>> simon.macdon...@gmail.com> wrote:
>>>
 Did you run it against mob-spec? It doesn't seem to change anything for
 me. Could be me though.

 Simon Mac Donald
 http://hi.im/simonmacdonald


 On Thu, Nov 15, 2012 at 3:24 PM, Andrew Grieve wrote:

> Fix pushed.
>
>
> On Thu, Nov 15, 2012 at 3:23 PM, Simon MacDonald <
> simon.macdon...@gmail.com> wrote:
>
>> np
>>
>> Simon Mac Donald
>> http://hi.im/simonmacdonald
>>
>>
>> On Thu, Nov 15, 2012 at 3:22 PM, Andrew Grieve 
>> wrote:
>>
>>> I'll fix the typo, and rename the keys. Thanks for finding this
>>> Simon.
>>>
>>>
>>> On Thu, Nov 15, 2012 at 3:20 PM, Andrew Grieve >> > wrote:
>>>
 Oh snap. yeah, I see. Andrew broke it. Who can spot the typo?:

 if (platform.object) {

 builder.build(platform.objects).intoAndClobber(context);
 }


 On Thu, Nov 15, 2012 at 3:14 PM, Simon MacDonald <
 simon.macdon...@gmail.com> wrote:

> Actually, I don't think the items in module.exports.objects in
> platform.js *do* clobber. At least what I'm seeing right now with the 
> edge
> JS code File, FileReader and FileError are not clobbered.
>
> When I run the mobile spec file tests these test cases fail but if
> I revert back to 2.2.0 JS then all tests pass.
>
> Simon Mac Donald
> http://hi.im/simonmacdonald
>
>
> On Thu, Nov 15, 2012 at 2:49 PM, Andrew Grieve <
> agri...@chromium.org> wrote:
>
>> Oh! This reminds me...
>>
>> When I was doing the navigator.connection work, I had a tough
>> time figuring
>> out how to get the builder to do the correct thing. It's a bit
>> confusing
>> because module.exports.objects in common.js don't clobber, but
>> module.exports.objects in platform.js *do* clobber.
>>
>> I wanted to propose a change:
>> for both common and platform:
>> "merges" --> intoAndMerge
>> "clobbers" --> intoAndClobber
>> "defaults" --> intoButDoNotClobber
>>
>> get rid of "objects"
>>
>>
>>
>>
>> On Thu, Nov 15, 2012 at 2:44 PM, Simon MacDonald
>> wrote:
>>
>> > Nope, it was a change to the JS. The objects are no longer
>> being clobbered
>> > correctly. I know who to bug now.
>> >
>> > Thanks all.
>> >
>> > Simon Mac Donald
>> > http://hi.im/simonmacdonald
>> >
>> >
>> > On Thu, Nov 15, 2012 at 1:25 PM, Michal Mocny <
>> mmo...@chromium.org> wrote:
>> >
>> > > Just a wild guess:
>> > >
>> > > Way back when ios 6.0 beta came out, same thing happened due
>> to
>> > > webview adding a semi complete implementation, and we weren't
>> forcing
>> > > a clobber.
>> > > Perhaps you updated to android 4.2 and perhaps its webview
>> also added
>> > > something and also needs a forced clobber..
>> > >
>> > > -Michal
>> > >
>> > > On Thu, Nov 15, 2012 at 12:28 PM, Simon MacDonald
>> > >  wrote:
>> > > > Hey,
>> > > >
>> > > > I'm noticing something weird today running mobile spec on
>> Android. I'm
>> > > get
>> > > > File test failures and I think it is related to the Android
>> WebView
>> > > > implementations File, FileReader and FileError objects not
>> being
>> > > clobbered
>> > > > like they should be.
>> > > >
>> > > > Were their any changes around that area of the code?
>> > > >
>> > > > Simo

[jira] [Commented] (CB-1404) EXC_BAD_ACCESS when using XHR_WITH_PAYLOAD bridge mode

2012-11-15 Thread john hight (JIRA)


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

john hight commented on CB-1404:


I believe you've replicated the bug since the first alert you get is not
the stopRecord alert.  The stopRecord alert you subsequently see is
"probably" the return from the second of two stopRecords that get issued
(one for each file), but it could be misleading to even guess at that since
anything after the first "problem" (the last of stopRecord alert first)
could be hard to predict.





> EXC_BAD_ACCESS when using XHR_WITH_PAYLOAD bridge mode 
> ---
>
> Key: CB-1404
> URL: https://issues.apache.org/jira/browse/CB-1404
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: iOS
>Affects Versions: 2.1.0
> Environment: iPad 2, iOS 5.1.1
>Reporter: Tom Clarkson
>Assignee: Andrew Grieve
> Fix For: 2.2.0
>
>
> When calling a plugin the app crashes on WebThread with EXC_BAD_ACCESS in 
> WebCore::DocumentThreadableLoader::cancel.
> This appears to be some sort of timing issue, as it does not happen on every 
> call - I am seeing it in an autosave function which makes lots of calls to 
> PGSQLitePlugin. 
> The error did not appear before upgrading to 2.1, and setting the bridge mode 
> to IFRAME_NAV restores the previous behaviour (no crashes, but odd scrolling 
> functionality).
> Setting the bridge mode to XHR_NO_PAYLOAD also seems to fix it - not sure if 
> removing the payload actually does anything different or just makes it fast 
> enough that the timing condition does not come up in normal app usage.
>   

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CB-1811) Previously hidden select dropdowns crashing the webview when focused upon

2012-11-15 Thread Adam Baldwin (JIRA)


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

Adam Baldwin commented on CB-1811:
--

Yeah, tried a factory reset and update already, to no avail. This app has a
lot of moving parts though, so I'll try to create a simplified sample when
I have the chance.





> Previously hidden select dropdowns crashing the webview when focused upon
> -
>
> Key: CB-1811
> URL: https://issues.apache.org/jira/browse/CB-1811
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 2.1.0, 2.2.0
> Environment: Samsung Galaxy S3 (Android 4.0.4)
>Reporter: Adam 
>Assignee: Joe Bowser
>Priority: Minor
>  Labels: bug, crash
>
> I have a div panel that is hidden when a page is first shown. Inside the div 
> are a few html dropdowns (select tags). When I make the div visible (via 
> javascript) and focus into one of the dropdowns, I get the following logcat 
> error:
> 11-04 03:58:49.136: A/libc(18437): Fatal signal 11 (SIGSEGV) at 0x 
> (code=1)
> Then, the app just crashes and the webview disappears. I confirmed that this 
> happens when the parent div is initially invisible (display:none). If the div 
> is visible at first, all works fine, even if the div is hidden subsequently.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (CB-1811) Previously hidden select dropdowns crashing the webview when focused upon

2012-11-15 Thread Joe Bowser (JIRA)


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

Joe Bowser resolved CB-1811.


Resolution: Cannot Reproduce

We recently received a Samsung Galaxy S3 (Android 4.0.4), and we can't 
reproduce this on that device either.  Recommend that you update your phone, or 
do a factory reset.

> Previously hidden select dropdowns crashing the webview when focused upon
> -
>
> Key: CB-1811
> URL: https://issues.apache.org/jira/browse/CB-1811
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 2.1.0, 2.2.0
> Environment: Samsung Galaxy S3 (Android 4.0.4)
>Reporter: Adam 
>Assignee: Joe Bowser
>Priority: Minor
>  Labels: bug, crash
>
> I have a div panel that is hidden when a page is first shown. Inside the div 
> are a few html dropdowns (select tags). When I make the div visible (via 
> javascript) and focus into one of the dropdowns, I get the following logcat 
> error:
> 11-04 03:58:49.136: A/libc(18437): Fatal signal 11 (SIGSEGV) at 0x 
> (code=1)
> Then, the app just crashes and the webview disappears. I confirmed that this 
> happens when the parent div is initially invisible (display:none). If the div 
> is visible at first, all works fine, even if the div is hidden subsequently.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CB-1864) Back Button breaks too often, needs better tests

2012-11-15 Thread Joe Bowser (JIRA)


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

Joe Bowser updated CB-1864:
---

Issue Type: Test  (was: Bug)

> Back Button breaks too often, needs better tests
> 
>
> Key: CB-1864
> URL: https://issues.apache.org/jira/browse/CB-1864
> Project: Apache Cordova
>  Issue Type: Test
>  Components: Android
>Affects Versions: 2.3.0
>Reporter: Joe Bowser
>Assignee: Joe Bowser
>Priority: Critical
> Fix For: 2.3.0
>
>
> Switched branches, broke back button.  Did eclipse clean, back button works 
> fine again.  We need tests for this!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CB-1864) Back Button breaks too often, needs better tests

2012-11-15 Thread Joe Bowser (JIRA)


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

Joe Bowser updated CB-1864:
---

Description: Switched branches, broke back button.  Did eclipse clean, back 
button works fine again.  We need tests for this!  (was: Apparently upgrading 
the project to Android 4.2 broke the back button again.  Going to work on tests 
to actually replicate pressing the back button instead of just relying on 
history, since history methods still seem to work.

Seriously, this is sad!)
   Priority: Critical  (was: Blocker)
Summary: Back Button breaks too often, needs better tests  (was: Back 
Button is broken again)

> Back Button breaks too often, needs better tests
> 
>
> Key: CB-1864
> URL: https://issues.apache.org/jira/browse/CB-1864
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 2.3.0
>Reporter: Joe Bowser
>Assignee: Joe Bowser
>Priority: Critical
> Fix For: 2.3.0
>
>
> Switched branches, broke back button.  Did eclipse clean, back button works 
> fine again.  We need tests for this!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CB-1864) Back Button is broken again

2012-11-15 Thread Joe Bowser (JIRA)

Joe Bowser created CB-1864:
--

 Summary: Back Button is broken again
 Key: CB-1864
 URL: https://issues.apache.org/jira/browse/CB-1864
 Project: Apache Cordova
  Issue Type: Bug
  Components: Android
Affects Versions: 2.3.0
Reporter: Joe Bowser
Assignee: Joe Bowser
Priority: Blocker
 Fix For: 2.3.0


Apparently upgrading the project to Android 4.2 broke the back button again.  
Going to work on tests to actually replicate pressing the back button instead 
of just relying on history, since history methods still seem to work.

Seriously, this is sad!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Type checking in Cordova JS plugins

2012-11-15 Thread Jesse MacFadyen

My answers/opinion

1. Up to the plugin developer
2. Up to the plugin developer
3. Up to the plugin developer

However, that does not mean that we can't make the existing APIs
handle params a little more consistently.

Also, we could expose typeChecking helper methods, although they are
pretty easy to come by.
Array.isArray() could be polyfil'd or could be cordova.isArray() ...

Cheers,
  Jesse

Sent from my iPhone5

On 2012-11-15, at 12:16 PM, Andrew Grieve  wrote:

> There's very little consistency when it comes to checking params in plugin
> code.
>
> globalization.js:
> checks every args. logs errors and returns without calling errback, does
> not allow missing errCB.
>
> resolveLocalFileSystemURI.js:
> Allows missing successCB and errCB. Sanity checks URL has a colon in it.
>
> notification.js:
> doesn't check types at all
>
> contacts.js:
> Throws TypeError if missing successCB, allows missing errCB
>
> compass.js:
> Logs and returns if callbacks are of wrong type. success required, error
> optional.
>
>
> So, the things to agree upon are:
>
> 1. Should we check types or not?
> 2. Success / error callbacks : optional or not?
> 3. When type errors happen, log & return, call errBack, or throw TypeError?
>
>
>
> For some extra inspiration, I played around with what it would look like to
> at least factor out type checking code. Have a look at the
> moduleand
> it's
> tests.
> Also, 
> here'swhat
> it looks like being used in globalization.js.
>
>
> Now, here's my thoughts for the three questions
> 1. Should we check types or not?
>  - I think it is useful since incorrect args end up in exec() calls and
> are therefore harder to debug when they are wrong.
>  - Perhaps instead of checking types, we add a helper for coercing types?
> This may only apply to strings / numbers though...
>  - I also kind of like the idea of being able to turn off type checking
> for release mode. Having a common function to do the type checking would
> allow us to turn checking on/off for performance.
>
> 2. Success / error callbacks : optional or not?
>  - I'm not positive we need to make these all consistent
>  - If anything, I'd say we'd want them to be optional.
>
> 3. When type errors happen, log & return, call errBack, or throw TypeError?
>  - TypeError is my preference here. This matches what browser APIs do when
> it doesn't like params.

Type checking in Cordova JS plugins

2012-11-15 Thread Andrew Grieve

There's very little consistency when it comes to checking params in plugin
code.

globalization.js:
checks every args. logs errors and returns without calling errback, does
not allow missing errCB.

resolveLocalFileSystemURI.js:
Allows missing successCB and errCB. Sanity checks URL has a colon in it.

notification.js:
doesn't check types at all

contacts.js:
Throws TypeError if missing successCB, allows missing errCB

compass.js:
Logs and returns if callbacks are of wrong type. success required, error
optional.


So, the things to agree upon are:

1. Should we check types or not?
2. Success / error callbacks : optional or not?
3. When type errors happen, log & return, call errBack, or throw TypeError?



For some extra inspiration, I played around with what it would look like to
at least factor out type checking code. Have a look at the
moduleand
it's
tests.
Also, 
here'swhat
it looks like being used in globalization.js.


Now, here's my thoughts for the three questions
1. Should we check types or not?
  - I think it is useful since incorrect args end up in exec() calls and
are therefore harder to debug when they are wrong.
  - Perhaps instead of checking types, we add a helper for coercing types?
This may only apply to strings / numbers though...
  - I also kind of like the idea of being able to turn off type checking
for release mode. Having a common function to do the type checking would
allow us to turn checking on/off for performance.

2. Success / error callbacks : optional or not?
  - I'm not positive we need to make these all consistent
  - If anything, I'd say we'd want them to be optional.

3. When type errors happen, log & return, call errBack, or throw TypeError?
  - TypeError is my preference here. This matches what browser APIs do when
it doesn't like params.

Re: Changes to the JS?

2012-11-15 Thread Gord Tanner

+1


On Thu, Nov 15, 2012 at 2:49 PM, Andrew Grieve  wrote:

> Oh! This reminds me...
>
> When I was doing the navigator.connection work, I had a tough time figuring
> out how to get the builder to do the correct thing. It's a bit confusing
> because module.exports.objects in common.js don't clobber, but
> module.exports.objects in platform.js *do* clobber.
>
> I wanted to propose a change:
> for both common and platform:
> "merges" --> intoAndMerge
> "clobbers" --> intoAndClobber
> "defaults" --> intoButDoNotClobber
>
> get rid of "objects"
>
>
>
>
> On Thu, Nov 15, 2012 at 2:44 PM, Simon MacDonald
> wrote:
>
> > Nope, it was a change to the JS. The objects are no longer being
> clobbered
> > correctly. I know who to bug now.
> >
> > Thanks all.
> >
> > Simon Mac Donald
> > http://hi.im/simonmacdonald
> >
> >
> > On Thu, Nov 15, 2012 at 1:25 PM, Michal Mocny 
> wrote:
> >
> > > Just a wild guess:
> > >
> > > Way back when ios 6.0 beta came out, same thing happened due to
> > > webview adding a semi complete implementation, and we weren't forcing
> > > a clobber.
> > > Perhaps you updated to android 4.2 and perhaps its webview also added
> > > something and also needs a forced clobber..
> > >
> > > -Michal
> > >
> > > On Thu, Nov 15, 2012 at 12:28 PM, Simon MacDonald
> > >  wrote:
> > > > Hey,
> > > >
> > > > I'm noticing something weird today running mobile spec on Android.
> I'm
> > > get
> > > > File test failures and I think it is related to the Android WebView
> > > > implementations File, FileReader and FileError objects not being
> > > clobbered
> > > > like they should be.
> > > >
> > > > Were their any changes around that area of the code?
> > > >
> > > > Simon Mac Donald
> > > > http://hi.im/simonmacdonald
> > >
> >
>

Re: Changes to the JS?

2012-11-15 Thread Simon MacDonald

We need to talk :)

Simon Mac Donald
http://hi.im/simonmacdonald


On Thu, Nov 15, 2012 at 2:49 PM, Andrew Grieve  wrote:

> Oh! This reminds me...
>
> When I was doing the navigator.connection work, I had a tough time figuring
> out how to get the builder to do the correct thing. It's a bit confusing
> because module.exports.objects in common.js don't clobber, but
> module.exports.objects in platform.js *do* clobber.
>
> I wanted to propose a change:
> for both common and platform:
> "merges" --> intoAndMerge
> "clobbers" --> intoAndClobber
> "defaults" --> intoButDoNotClobber
>
> get rid of "objects"
>
>
>
>
> On Thu, Nov 15, 2012 at 2:44 PM, Simon MacDonald
> wrote:
>
> > Nope, it was a change to the JS. The objects are no longer being
> clobbered
> > correctly. I know who to bug now.
> >
> > Thanks all.
> >
> > Simon Mac Donald
> > http://hi.im/simonmacdonald
> >
> >
> > On Thu, Nov 15, 2012 at 1:25 PM, Michal Mocny 
> wrote:
> >
> > > Just a wild guess:
> > >
> > > Way back when ios 6.0 beta came out, same thing happened due to
> > > webview adding a semi complete implementation, and we weren't forcing
> > > a clobber.
> > > Perhaps you updated to android 4.2 and perhaps its webview also added
> > > something and also needs a forced clobber..
> > >
> > > -Michal
> > >
> > > On Thu, Nov 15, 2012 at 12:28 PM, Simon MacDonald
> > >  wrote:
> > > > Hey,
> > > >
> > > > I'm noticing something weird today running mobile spec on Android.
> I'm
> > > get
> > > > File test failures and I think it is related to the Android WebView
> > > > implementations File, FileReader and FileError objects not being
> > > clobbered
> > > > like they should be.
> > > >
> > > > Were their any changes around that area of the code?
> > > >
> > > > Simon Mac Donald
> > > > http://hi.im/simonmacdonald
> > >
> >
>

Re: Changes to the JS?

2012-11-15 Thread Andrew Grieve

Oh! This reminds me...

When I was doing the navigator.connection work, I had a tough time figuring
out how to get the builder to do the correct thing. It's a bit confusing
because module.exports.objects in common.js don't clobber, but
module.exports.objects in platform.js *do* clobber.

I wanted to propose a change:
for both common and platform:
"merges" --> intoAndMerge
"clobbers" --> intoAndClobber
"defaults" --> intoButDoNotClobber

get rid of "objects"




On Thu, Nov 15, 2012 at 2:44 PM, Simon MacDonald
wrote:

> Nope, it was a change to the JS. The objects are no longer being clobbered
> correctly. I know who to bug now.
>
> Thanks all.
>
> Simon Mac Donald
> http://hi.im/simonmacdonald
>
>
> On Thu, Nov 15, 2012 at 1:25 PM, Michal Mocny  wrote:
>
> > Just a wild guess:
> >
> > Way back when ios 6.0 beta came out, same thing happened due to
> > webview adding a semi complete implementation, and we weren't forcing
> > a clobber.
> > Perhaps you updated to android 4.2 and perhaps its webview also added
> > something and also needs a forced clobber..
> >
> > -Michal
> >
> > On Thu, Nov 15, 2012 at 12:28 PM, Simon MacDonald
> >  wrote:
> > > Hey,
> > >
> > > I'm noticing something weird today running mobile spec on Android. I'm
> > get
> > > File test failures and I think it is related to the Android WebView
> > > implementations File, FileReader and FileError objects not being
> > clobbered
> > > like they should be.
> > >
> > > Were their any changes around that area of the code?
> > >
> > > Simon Mac Donald
> > > http://hi.im/simonmacdonald
> >
>

Re: Changes to the JS?

2012-11-15 Thread Simon MacDonald

Nope, it was a change to the JS. The objects are no longer being clobbered
correctly. I know who to bug now.

Thanks all.

Simon Mac Donald
http://hi.im/simonmacdonald


On Thu, Nov 15, 2012 at 1:25 PM, Michal Mocny  wrote:

> Just a wild guess:
>
> Way back when ios 6.0 beta came out, same thing happened due to
> webview adding a semi complete implementation, and we weren't forcing
> a clobber.
> Perhaps you updated to android 4.2 and perhaps its webview also added
> something and also needs a forced clobber..
>
> -Michal
>
> On Thu, Nov 15, 2012 at 12:28 PM, Simon MacDonald
>  wrote:
> > Hey,
> >
> > I'm noticing something weird today running mobile spec on Android. I'm
> get
> > File test failures and I think it is related to the Android WebView
> > implementations File, FileReader and FileError objects not being
> clobbered
> > like they should be.
> >
> > Were their any changes around that area of the code?
> >
> > Simon Mac Donald
> > http://hi.im/simonmacdonald
>

[jira] [Commented] (CB-1404) EXC_BAD_ACCESS when using XHR_WITH_PAYLOAD bridge mode

2012-11-15 Thread Andrew Grieve (JIRA)


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

Andrew Grieve commented on CB-1404:
---

Okay, I tried it again on the iOS 6 simulator. Wait for 10 seconds watching the 
logs, at 10 seconds a bunch more spew out. I then click Capture.

I see a "buffer1 while listen and default..." alert, and once I dismiss it, I 
see the returned from stopRecord alert.

> EXC_BAD_ACCESS when using XHR_WITH_PAYLOAD bridge mode 
> ---
>
> Key: CB-1404
> URL: https://issues.apache.org/jira/browse/CB-1404
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: iOS
>Affects Versions: 2.1.0
> Environment: iPad 2, iOS 5.1.1
>Reporter: Tom Clarkson
>Assignee: Andrew Grieve
> Fix For: 2.2.0
>
>
> When calling a plugin the app crashes on WebThread with EXC_BAD_ACCESS in 
> WebCore::DocumentThreadableLoader::cancel.
> This appears to be some sort of timing issue, as it does not happen on every 
> call - I am seeing it in an autosave function which makes lots of calls to 
> PGSQLitePlugin. 
> The error did not appear before upgrading to 2.1, and setting the bridge mode 
> to IFRAME_NAV restores the previous behaviour (no crashes, but odd scrolling 
> functionality).
> Setting the bridge mode to XHR_NO_PAYLOAD also seems to fix it - not sure if 
> removing the payload actually does anything different or just makes it fast 
> enough that the timing condition does not come up in normal app usage.
>   

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CB-1863) FileTransfer.abort needs a quick example

2012-11-15 Thread Shazron Abdullah (JIRA)

Shazron Abdullah created CB-1863:


 Summary: FileTransfer.abort needs a quick example
 Key: CB-1863
 URL: https://issues.apache.org/jira/browse/CB-1863
 Project: Apache Cordova
  Issue Type: Task
  Components: Docs
Reporter: Shazron Abdullah
Assignee: Michael Brooks
 Fix For: 2.3.0


The abort function takes two params: a success and error callback.
https://github.com/apache/incubator-cordova-js/blob/master/lib/common/plugin/FileTransfer.js#L145

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CB-1848) device APIs should be looked at again

2012-11-15 Thread Gord (JIRA)


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

Gord updated CB-1848:
-


JavaScript commit:
https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-js.git;a=commitdiff;h=57dcbcc162ae2a56526b0a2a131212801d82b617

Platform commit (for PlayBook)
https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-blackberry-webworks.git;a=commitdiff;h=bad44d869c5aea556313e328b42ff2c8729d39ed

> device APIs should be looked at again
> -
>
> Key: CB-1848
> URL: https://issues.apache.org/jira/browse/CB-1848
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: BlackBerry
>Affects Versions: 2.2.0
> Environment: Playbook
>Reporter: Filip Maj
>Assignee: Gord
> Fix For: 2.3.0
>
>
> {{device.platform}} returns {{playbook}} on a Playbook. Presumably this means 
> that on a BB 10 device it returns something else? (haven't tested on bb10 
> yet). What about on BB OS 6 or 7?
> {{device.name}} returns a string of numbers. Not sure what that represents.
> {{device.version}} on a Playbook returns {{BlackBerry Playbook OS}}. I ran 
> this on two different Playbooks with different versions (2.0.1. and 
> 2.1.0.) and both returned the same value. It should instead return the 
> Playbook OS version as a string. Again, not sure what BB OS 6 and 7, and BB 
> 10s, return in this case.
> On the plus side {{device.uuid}} returns the device PIN! This is correct.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CB-1796) camera.getPicture: the photo file is corrupted.

2012-11-15 Thread Joe Bowser (JIRA)


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

Joe Bowser commented on CB-1796:


[~julienbier] Are you trying with 2.2.0 or just 2.0.

> camera.getPicture: the photo file is corrupted.
> ---
>
> Key: CB-1796
> URL: https://issues.apache.org/jira/browse/CB-1796
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 2.0.0
> Environment: Tested on Nexus 7 and Samsung Galaxy
>Reporter: Julien Bier
>Assignee: Simon MacDonald
> Attachments: MyCamera.zip
>
>
> The picture saved in the Camera folder is corrupted: the file size is equal 
> to 0kb.
> The file can not be read from Windows.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CB-1856) Offline Event fires twice on Jellybean

2012-11-15 Thread Joe Bowser (JIRA)


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

Joe Bowser commented on CB-1856:


Yeah, this will end up being higher priority the more people start using 
4.1/4.2, so the priority is a bit deceiving.

> Offline Event fires twice on Jellybean
> --
>
> Key: CB-1856
> URL: https://issues.apache.org/jira/browse/CB-1856
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 2.3.0
> Environment: Neuxs 7 running Android 4.2
>Reporter: Joe Bowser
>Assignee: Joe Bowser
>Priority: Minor
> Fix For: 2.3.0
>
>
> While testing CB-1846, I discovered that the Offline and Online events are 
> being called twice on my Galaxy Nexus and my Nexus 7.  The Samsung Galaxy S2 
> and the Nexus S that I tested are working as expected.  We ideally should 
> only fire this event once when we switch WiFi on and off.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CB-1862) Problem with creation of multiple WebSQL databases

2012-11-15 Thread Joe Bowser (JIRA)


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

Joe Bowser commented on CB-1862:


Can you provide some sample code to recreate this issue?

Thanks

> Problem with creation of multiple WebSQL databases
> --
>
> Key: CB-1862
> URL: https://issues.apache.org/jira/browse/CB-1862
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 2.2.0
> Environment: I use Cordova 2.2.0 for Android with a project for 
> Android 2.3.x
>Reporter: Julien Roche
>Assignee: Joe Bowser
>Priority: Minor
>
> I try to create multiples databases, because I would like to separate datas 
> (and for optimization too). It seems that I can create these, but if I inject 
> a lot of datas, we have some memory leaks, and the application crashs.
> With one database, not problem occurs.
> Thank you very much.
> Best regards
> PS: here a part of the log ->
> 11-15 08:48:21.642: E/dalvikvm(329): Failed adding to JNI local ref table 
> (has 512 entries)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (CB-1513) Cordova app gets killed by garbage collector when out of memory due to camera

2012-11-15 Thread Joe Bowser (JIRA)


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

Joe Bowser resolved CB-1513.


Resolution: Won't Fix
  Assignee: Joe Bowser  (was: Simon MacDonald)

OK, once again I get to be the heavy.

We have been working on bringing in the Camera plugin, however we recently 
decided to not have this be a core plugin in Cordova and instead have it as a 
3rd party plugin.  I'll be creating a repository for it soon and putting it on 
this ticket, but we have no plans to explicitly fix this problem in the near 
future in Cordova itself.

http://mail-archives.apache.org/mod_mbox/cordova-dev/201211.mbox/%3CCAOBL_k66_V_P23V3wBE-G=quxd7mq_jdgr-svaysbbid8mu...@mail.gmail.com%3E

If you feel ambitious, you can try the code in this fork and build it yourself:
https://github.com/infil00p/cordova-android/tree/camera

Sorry about this.

> Cordova app gets killed by garbage collector when out of memory due to camera
> -
>
> Key: CB-1513
> URL: https://issues.apache.org/jira/browse/CB-1513
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 2.0.0
> Environment: All android versions with some memory extensive apps 
> running
>Reporter: Ruben Vanhoeyveld
>Assignee: Joe Bowser
>Priority: Critical
>  Labels: Cordova, EmbeddedCameraApp, app, camera, crash, custom, 
> restart
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> I'm using PhoneGap's navigator.camera.getPicture function to retrieve a photo 
> from the device's camera on Android.
> When I click the button, it does start the camera, but when I click OK on the 
> camera app after taking a photo, it restarts the application.
> I tried to:
> * use different source types.
> * use different destination types.
> * reduce quality.
> Any ideas?
> I know this:
> {quote}This problem isn't actually about Phonegap. It's a common issue on 
> native android apps too.
> It occurs because when the camera is triggered, the android activity goes 
> background (onStop state), waiting for the camera to take the picture. Then 
> the GC comes and kills the activity to free memory before the conclusion of 
> camera action, and when the camera is done your activity has already died. 
> That is why the app is restarted.{quote}
> From: 
> [Stackoverflow|http://stackoverflow.com/questions/8368091/phonegap-camera-restarts-the-application]
> I have also tried this:
> {quote}We submited a Google Code project named Foreground Camera Plugin that 
> fixes the problem of Android Camera restarting Phonegap applications. There 
> is some orientation on how to use it too. Please see: 
> http://code.google.com/p/foreground-camera-plugin/{quote}
> From: 
> [Stackoverflow|http://stackoverflow.com/questions/8368091/phonegap-camera-restarts-the-application]
> But that didn't work for me... The same goes for *EmbeddedCameraApp*. They 
> are all built on older versions of Cordova. I use Cordova *version 2.0.0*
> Conclusion: It seems to me that the only solution is to use a custom made 
> camera that's implemented in the app as a new activity. Like that, the app 
> doesn't go to the background and isn't killed by the garbage collector.
> Can this be made?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Changes to the JS?

2012-11-15 Thread Michal Mocny

Just a wild guess:

Way back when ios 6.0 beta came out, same thing happened due to
webview adding a semi complete implementation, and we weren't forcing
a clobber.
Perhaps you updated to android 4.2 and perhaps its webview also added
something and also needs a forced clobber..

-Michal

On Thu, Nov 15, 2012 at 12:28 PM, Simon MacDonald
 wrote:
> Hey,
>
> I'm noticing something weird today running mobile spec on Android. I'm get
> File test failures and I think it is related to the Android WebView
> implementations File, FileReader and FileError objects not being clobbered
> like they should be.
>
> Were their any changes around that area of the code?
>
> Simon Mac Donald
> http://hi.im/simonmacdonald

[jira] [Commented] (CB-1404) EXC_BAD_ACCESS when using XHR_WITH_PAYLOAD bridge mode

2012-11-15 Thread john hight (JIRA)


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

john hight commented on CB-1404:


I've tried putting a try/catch around the call to stopRecord, and it
doesn't hit.  I've also tried putting a try/catch around a few spots in
iOSexec, and they don't either  ALTHOUGH ... at one point I thought I
saw a "DOM exception", perhaps '11', appear as a value in the Safari
debugger as a property ("status" perhaps) of some variable in the sidebar.
 Couldn't reproduce that behavior though, and it may have been something
that popped by putting one-too-many try/catch's or console.logs in iOSexec.

The secret to reproducing the error is to:

   - click on Listen
   - wait for a little more than 10 seconds and then click on Capture.
only have 10 seconds does the 2nd (of two) buffer/files start getting
   recorded. You will see log messages for the 2nd buffer, buffer1,
like "*012-11-15
   09:55:46.257 AudioRecall[28435:c07] [LOG] buffer1 listening  1.007 sec,
   * ", when the 2nd buffer starts being recorded

If it still hits the alert "Returned from stopRecord" then we've failed in
getting you to reproduce the problem.  If however, you do not get that
specific alert, and instead get a different one, like "buffer1 while listen
and default" then you've reproduced the problem.






> EXC_BAD_ACCESS when using XHR_WITH_PAYLOAD bridge mode 
> ---
>
> Key: CB-1404
> URL: https://issues.apache.org/jira/browse/CB-1404
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: iOS
>Affects Versions: 2.1.0
> Environment: iPad 2, iOS 5.1.1
>Reporter: Tom Clarkson
>Assignee: Andrew Grieve
> Fix For: 2.2.0
>
>
> When calling a plugin the app crashes on WebThread with EXC_BAD_ACCESS in 
> WebCore::DocumentThreadableLoader::cancel.
> This appears to be some sort of timing issue, as it does not happen on every 
> call - I am seeing it in an autosave function which makes lots of calls to 
> PGSQLitePlugin. 
> The error did not appear before upgrading to 2.1, and setting the bridge mode 
> to IFRAME_NAV restores the previous behaviour (no crashes, but odd scrolling 
> functionality).
> Setting the bridge mode to XHR_NO_PAYLOAD also seems to fix it - not sure if 
> removing the payload actually does anything different or just makes it fast 
> enough that the timing condition does not come up in normal app usage.
>   

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (CB-1846) Offline event doesn't work

2012-11-15 Thread Andrew Grieve (JIRA)


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

Andrew Grieve closed CB-1846.
-

Resolution: Invalid

Looked at your app. The problem is that you're never attaching your offline 
listener because onLoad is never called from anywhere. I changed:

 

to:

 

and it works fine on the first page load. You have a multi-page app here by the 
looks of it though, so watch out for the bug Simon mentioned where offline 
events don't work on other page loads. You may want to pull in the fix for that 
to your app.

> Offline event doesn't work
> --
>
> Key: CB-1846
> URL: https://issues.apache.org/jira/browse/CB-1846
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 2.2.0
> Environment: Samsung Galaxy S2 and Google Nexus 7
>Reporter: Remzi Cavdar
>Assignee: Joe Bowser
> Fix For: 2.2.0
>
> Attachments: Menofood BETA.zip
>
>
> The offline event doesn't work and I had said this before release, but you 
> guys wanted to release PhoneGap 2.2.0 
> This is my code:
> document.addEventListener("deviceready", onDeviceReady, false);
> function onDeviceReady() {
>   document.addEventListener("offline", function() {
>   alert("Er is geen internet verbinding!\nSchakel Wifi of 3G in");
>   }, false);
> }
> /* English: alert("No internet connection!\nPlease turn on Wifi or 3G");  */

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: cordova-js fails on windows 7

2012-11-15 Thread Jesse MacFadyen

Not using it, but the build was broken for windows devs.

Cheers,
  Jesse

Sent from my iPhone5

On 2012-11-15, at 6:19 AM, Gord Tanner  wrote:

> Yeah, I moved the debug versions of Cordova.js into a debug folder.
>
> What are you using the debug version for?
>
> Sent from my iPhone
>
> On 2012-11-15, at 1:37 AM, Jesse  wrote:
>
>> Actually, it was here:
>> https://github.com/apache/incubator-cordova-js/blob/master/Jakefile#L73
>>
>> I have pushed the fix.
>> Cheers,
>> Jesse
>>
>> On Wed, Nov 14, 2012 at 10:14 PM, Jesse  wrote:
>>> Yet another windows vs unix path building issue.
>>>
>>> https://github.com/apache/incubator-cordova-js/blob/ce50b72632cc861014a58db563becea48c426772/build/packager.js#L40
>>>
>>>
>>>
>>>
>>> On Wed, Nov 14, 2012 at 6:07 PM, Anis KADRI  wrote:
 ...with:

 building commit ce50b72632cc861014a58db563becea48c426772
 jake aborted.
 Error: ENOENT, no such file or directory
 'c:\Users\anis\cordova\incubator-cordov
 a-js\pkg\debug\cordova.windows8-debug.js'
   at Object.openSync (fs.js:238:18)
 (See full trace by running task with --trace)

 What happened ? Looks like the packager is broken. Any ideas ?
>>>
>>>
>>>
>>> --
>>> @purplecabbage
>>> risingj.com
>>
>>
>>
>> --
>> @purplecabbage
>> risingj.com

[jira] [Resolved] (CB-1860) NPE in onReceivedError with non local errorUrl

2012-11-15 Thread Simon MacDonald (JIRA)


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

Simon MacDonald resolved CB-1860.
-

Resolution: Fixed

Yeah, baseUrl is no longer used in DroidGap. It is in CordovaWebView so I 
removed it from this class.

> NPE in onReceivedError with non local errorUrl
> --
>
> Key: CB-1860
> URL: https://issues.apache.org/jira/browse/CB-1860
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 2.2.0
>Reporter: Moshe Elisha
>Assignee: Simon MacDonald
>
> My errorUrl is not local (does not start with "file://").
> If when loading the first URL is (via loadUrl in the onCreate) it fails (for 
> example, URL not found) - there is a NullPointerException in 
> DroidGap.onReceivedError.
> Debugging shows that the me.baseUrl is null so "errorUrl.indexOf(me.baseUrl)" 
> throws the NPE.
> The me.appView.baseUrl is not null and contains the base URL of the URL I 
> tried to load (failingUrl).
> Where does DroidGap.baseUrl is initialized anyway?
> Thanks.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (CB-1860) NPE in onReceivedError with non local errorUrl

2012-11-15 Thread Simon MacDonald (JIRA)


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

Simon MacDonald reassigned CB-1860:
---

Assignee: Simon MacDonald  (was: Joe Bowser)

> NPE in onReceivedError with non local errorUrl
> --
>
> Key: CB-1860
> URL: https://issues.apache.org/jira/browse/CB-1860
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 2.2.0
>Reporter: Moshe Elisha
>Assignee: Simon MacDonald
>
> My errorUrl is not local (does not start with "file://").
> If when loading the first URL is (via loadUrl in the onCreate) it fails (for 
> example, URL not found) - there is a NullPointerException in 
> DroidGap.onReceivedError.
> Debugging shows that the me.baseUrl is null so "errorUrl.indexOf(me.baseUrl)" 
> throws the NPE.
> The me.appView.baseUrl is not null and contains the base URL of the URL I 
> tried to load (failingUrl).
> Where does DroidGap.baseUrl is initialized anyway?
> Thanks.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: cordova-js fails on windows 7

2012-11-15 Thread Gord Tanner

Yeah, I moved the debug versions of Cordova.js into a debug folder.

What are you using the debug version for?

Sent from my iPhone

On 2012-11-15, at 1:37 AM, Jesse  wrote:

> Actually, it was here:
> https://github.com/apache/incubator-cordova-js/blob/master/Jakefile#L73
> 
> I have pushed the fix.
> Cheers,
>  Jesse
> 
> On Wed, Nov 14, 2012 at 10:14 PM, Jesse  wrote:
>> Yet another windows vs unix path building issue.
>> 
>> https://github.com/apache/incubator-cordova-js/blob/ce50b72632cc861014a58db563becea48c426772/build/packager.js#L40
>> 
>> 
>> 
>> 
>> On Wed, Nov 14, 2012 at 6:07 PM, Anis KADRI  wrote:
>>> ...with:
>>> 
>>> building commit ce50b72632cc861014a58db563becea48c426772
>>> jake aborted.
>>> Error: ENOENT, no such file or directory
>>> 'c:\Users\anis\cordova\incubator-cordov
>>> a-js\pkg\debug\cordova.windows8-debug.js'
>>>at Object.openSync (fs.js:238:18)
>>> (See full trace by running task with --trace)
>>> 
>>> What happened ? Looks like the packager is broken. Any ideas ?
>> 
>> 
>> 
>> --
>> @purplecabbage
>> risingj.com
> 
> 
> 
> -- 
> @purplecabbage
> risingj.com

[jira] [Commented] (CB-1847) weinre: client c-2: weinre: invocation exception on WeinreClientEventsImpl.connectionCreated(): TypeError: Cannot call method 'indexOf' of undefined

2012-11-15 Thread Patrick Mueller (JIRA)


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

Patrick Mueller commented on CB-1847:
-

More information please.

Can you run weinre with --verbose and --debug ?  Those might provide more 
information.

Also, can you reproduce with a tiny example?

I have no idea what your "admin dashboard" is; do you mean the remote panel of 
the weinre web application?  Or is this some code of your own?

> weinre: client c-2: weinre: invocation exception on 
> WeinreClientEventsImpl.connectionCreated(): TypeError: Cannot call method 
> 'indexOf' of undefined
> 
>
> Key: CB-1847
> URL: https://issues.apache.org/jira/browse/CB-1847
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: weinre
>Affects Versions: 2.0.0, 2.1.0, 2.2.0
> Environment: tried both on linux/osx.
> Phone to test webview: Samsung Galaxy Nexus with Android 4.1.2
>Reporter: Emanuele Ricci
>Assignee: Patrick Mueller
>
> This is the error we get when we try to click on the link of the client on 
> our admin dashboard: 2012-11-14T14:37:38.568Z weinre: client c-2: weinre: 
> invocation exception on WeinreClientEventsImpl.connectionCreated(): 
> TypeError: Cannot call method 'indexOf' of undefined
> We tried this: http://debug.phonegap.com/client/#mxmtest and it's working 
> fine (but slow because on the internet).
> Can you fix this? 
> We used weinre from npm install

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: RIM/BlackBerry folk: please help

2012-11-15 Thread Nukul Bhasin

I agree with Gord's evaluation of the problem,
The error you are getting is often because of buildId not getting
incrementing

Setting up debug tokens can really suck, but its the reality of where we
are today. If you use QNX momentics (NDK tooling) it will hide all the
ugliness for you.
Command Line tools are lagging in bringing the same experience but Signing
improvements are on the roadmap, no landing date yet though but its being
re-thought completely.


On Wed, Nov 14, 2012 at 6:26 PM, Filip Maj  wrote:

> Whatever. I gave up and used debug tokens. IT was fucking difficult to get
> working but am now at a barely-workable level.
>
> On 11/14/12 3:18 PM, "Gord Tanner"  wrote:
>
> >Signing worked for me with my super epic script:
> >
> >var sys = require('sys')
> >var exec = require('child_process').exec;
> >
> >exec("ant qnx load-device", function (error, stdout, stderr) {
> >sys.print('stdout: ' + stdout);
> >sys.print('stderr: ' + stderr);
> >if (error !== null) {
> >console.log('exec error: ' + error);
> >}
> >});
> >
> >I think your main issue is the version number and buildId hackery for
> >signing.
> >
> >
> >On Wed, Nov 14, 2012 at 5:38 PM, Filip Maj  wrote:
> >
> >> That's not what happens though.
> >>
> >> When I create a fresh project, the name and version are always the same.
> >>
> >> When I run the signing via node, it fails.
> >>
> >> Then I'll CD into this exact same project folder and run the signing
> >> manually. It works.
> >>
> >> I'll also create a new project manually with that same version and app
> >> name. If I sign it via command line it works. If I do it via my node
> >> script it fails.
> >>
> >> On 11/14/12 2:32 PM, "Tim Kim"  wrote:
> >>
> >> >The reason why you keep getting signing failures even with a fresh
> >>project
> >> >is that you already did it once. ie, in your config.xml, the widget
> >> >version
> >> >is set to "1.0.0.0" and the name attribute is "cordovaExample". So the
> >> >first time should work, but every new fresh project there after will
> >>have
> >> >the same values.
> >> >
> >> >I would recommend updating the version number every time you deploy and
> >> >not
> >> >worry about that debug-token business -  I've never used it.
> >> >
> >> >--
> >> >Timothy Kim
> >>
> >>
>
>


-- 
*Nukul Bhasin*
*Computer Engineer, B.Eng*
*10 Queens Quay W, suite#1710*
*Toronto, ON, Canada*
*Ph: 416 508 3157*

Re: InAppBrowser api questions

2012-11-15 Thread Shazron

> I spent some time playing with how to do this.
> 1 - Use referer header - Too many situations result in no header, so this
> is out!
> 2 - Use Cookies - if there were a way to have UIWebViews use separate
> cookie jars, this might be feasible. Don't think that's possible.
> 3 - Use User-Agent - this is already suggested in CB-1695. I also found
> this:
>
> http://stackoverflow.com/questions/12180224/unique-tab-id-appended-to-user-agent-string-in-chrome-for-ios
> ,
> which suggests that this is what Chrome for iOS uses to implement incognito
> mode. If they can make it work, then we should be able to as well!
>
> So, this is looking like it's non-trivial but not impossible! As long as
> it's possible, let's implement it :)
>
>
Looks like it may be possible in CB-1695 as you mentioned -- so we can
finish InAppBrowser with this one failing case until it is implemented. I
can look into this further once I finish the InAppBrowser integration.


> I don't think the semantics of _parent and _blank really map well to what
>  we're doing. My vote is to create a new special value: _system, and only
> this target kicks you out to the system browser.
>
> Also: on the wiki we have:
> [F]  window.open('http://random-url.com', '_blank'); // native browser
>
> It seems weird to me that the effect of _blank changes based on whether the
> URL is in the whitelist. I'd think this case would also open in the
> InAppBrowser.
>
>
> Summary of what I think:
> _self or no target --> open in cordova webview if it's in the Whitelist,
> InAppBrowser otherwise
> _system --> open in system browser
> anything else --> open in InAppBrowser
>
> Also, I like Simon's idea of using the options in window.open to specify
> whether to show URL bar etc. :)
>

I agree, we need a new value "_system" as you suggested, as well as the
other parts of the summary of your changes -- makes more sense, and if used
in another context -- it will just work as expected. I can make the wiki
changes unless others have more comments.

We can definitely add the window options as well, for sure!

[jira] [Created] (CB-1862) Problem with creation of multiple WebSQL databases

2012-11-15 Thread Julien Roche (JIRA)

Julien Roche created CB-1862:


 Summary: Problem with creation of multiple WebSQL databases
 Key: CB-1862
 URL: https://issues.apache.org/jira/browse/CB-1862
 Project: Apache Cordova
  Issue Type: Bug
  Components: Android
Affects Versions: 2.2.0
 Environment: I use Cordova 2.2.0 for Android with a project for 
Android 2.3.x
Reporter: Julien Roche
Assignee: Joe Bowser
Priority: Minor


I try to create multiples databases, because I would like to separate datas 
(and for optimization too). It seems that I can create these, but if I inject a 
lot of datas, we have some memory leaks, and the application crashs.

With one database, not problem occurs.


Thank you very much.

Best regards

PS: here a part of the log ->
11-15 08:48:21.642: E/dalvikvm(329): Failed adding to JNI local ref table (has 
512 entries)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CB-1861) Add default wildcard to Cordova.plist/ExternalHosts

2012-11-15 Thread Shazron Abdullah (JIRA)

Shazron Abdullah created CB-1861:


 Summary: Add default wildcard to Cordova.plist/ExternalHosts
 Key: CB-1861
 URL: https://issues.apache.org/jira/browse/CB-1861
 Project: Apache Cordova
  Issue Type: Task
  Components: iOS
Reporter: Shazron Abdullah
Assignee: Shazron Abdullah
 Fix For: 2.3.0


This should be the default for the iOS template from now on to be consistent 
with Android and BB. Add a warning to the user (console) that their whitelist 
is wide open.

ML discussion: http://markmail.org/thread/7pyuu2fdghaabaa3

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CB-1860) NPE in onReceivedError with non local errorUrl

2012-11-15 Thread Moshe Elisha (JIRA)

Moshe Elisha created CB-1860:


 Summary: NPE in onReceivedError with non local errorUrl
 Key: CB-1860
 URL: https://issues.apache.org/jira/browse/CB-1860
 Project: Apache Cordova
  Issue Type: Bug
  Components: Android
Affects Versions: 2.2.0
Reporter: Moshe Elisha
Assignee: Joe Bowser


My errorUrl is not local (does not start with "file://").
If when loading the first URL is (via loadUrl in the onCreate) it fails (for 
example, URL not found) - there is a NullPointerException in 
DroidGap.onReceivedError.

Debugging shows that the me.baseUrl is null so "errorUrl.indexOf(me.baseUrl)" 
throws the NPE.

The me.appView.baseUrl is not null and contains the base URL of the URL I tried 
to load (failingUrl).

Where does DroidGap.baseUrl is initialized anyway?

Thanks.



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CB-1846) Offline event doesn't work

2012-11-15 Thread Remzi Cavdar (JIRA)


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

Remzi Cavdar updated CB-1846:
-

Attachment: Menofood BETA.zip

We are making an application, which uses this offline event of Codova.

This is Copyrighted work if my boss finds out. if someone other is using this 
idea or he gets to know, then I'm fucked, so please don't share it to the world.

> Offline event doesn't work
> --
>
> Key: CB-1846
> URL: https://issues.apache.org/jira/browse/CB-1846
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 2.2.0
> Environment: Samsung Galaxy S2 and Google Nexus 7
>Reporter: Remzi Cavdar
>Assignee: Joe Bowser
> Fix For: 2.2.0
>
> Attachments: Menofood BETA.zip
>
>
> The offline event doesn't work and I had said this before release, but you 
> guys wanted to release PhoneGap 2.2.0 
> This is my code:
> document.addEventListener("deviceready", onDeviceReady, false);
> function onDeviceReady() {
>   document.addEventListener("offline", function() {
>   alert("Er is geen internet verbinding!\nSchakel Wifi of 3G in");
>   }, false);
> }
> /* English: alert("No internet connection!\nPlease turn on Wifi or 3G");  */

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CB-1846) Offline event doesn't work

2012-11-15 Thread Remzi Cavdar (JIRA)


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

Remzi Cavdar commented on CB-1846:
--

So can anyone look at the code?
I have attached a .zip file with my code.

> Offline event doesn't work
> --
>
> Key: CB-1846
> URL: https://issues.apache.org/jira/browse/CB-1846
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 2.2.0
> Environment: Samsung Galaxy S2 and Google Nexus 7
>Reporter: Remzi Cavdar
>Assignee: Joe Bowser
> Fix For: 2.2.0
>
> Attachments: Menofood BETA.zip
>
>
> The offline event doesn't work and I had said this before release, but you 
> guys wanted to release PhoneGap 2.2.0 
> This is my code:
> document.addEventListener("deviceready", onDeviceReady, false);
> function onDeviceReady() {
>   document.addEventListener("offline", function() {
>   alert("Er is geen internet verbinding!\nSchakel Wifi of 3G in");
>   }, false);
> }
> /* English: alert("No internet connection!\nPlease turn on Wifi or 3G");  */

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Reopened] (CB-1846) Offline event doesn't work

2012-11-15 Thread Remzi Cavdar (JIRA)


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

Remzi Cavdar reopened CB-1846:
--


But why the code doesn't work for me?

And I use Google Nexus 7 with Android 4.1.2

And Samsung Galaxy S2 with Android 4.0.3

So there is an problem?

> Offline event doesn't work
> --
>
> Key: CB-1846
> URL: https://issues.apache.org/jira/browse/CB-1846
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 2.2.0
> Environment: Samsung Galaxy S2 and Google Nexus 7
>Reporter: Remzi Cavdar
>Assignee: Joe Bowser
> Fix For: 2.2.0
>
>
> The offline event doesn't work and I had said this before release, but you 
> guys wanted to release PhoneGap 2.2.0 
> This is my code:
> document.addEventListener("deviceready", onDeviceReady, false);
> function onDeviceReady() {
>   document.addEventListener("offline", function() {
>   alert("Er is geen internet verbinding!\nSchakel Wifi of 3G in");
>   }, false);
> }
> /* English: alert("No internet connection!\nPlease turn on Wifi or 3G");  */

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

52 matches

Mail list logo