date:20140530

[jira] [Commented] (CB-6667) window.requestFileSystem - callbacks are not fired in a particular circumstance

2014-05-30 Thread Kelvin Dart (JIRA)


[ 
https://issues.apache.org/jira/browse/CB-6667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14013409#comment-14013409
 ] 

Kelvin Dart commented on CB-6667:
-

Hi [~iclelland],

I'll provide a pastebin shortly and instructions on how to set it up. It's 
pretty much the default project but with a minor alteration, but I will provide 
that to you anyway!

Rather frustratingly, File Dropper has deleted my files.

 window.requestFileSystem - callbacks are not fired in a particular 
 circumstance
 ---

 Key: CB-6667
 URL: https://issues.apache.org/jira/browse/CB-6667
 Project: Apache Cordova
  Issue Type: Bug
  Components: Plugin File
Affects Versions: 3.4.0
 Environment: Mac OS X 10.9.2
 Android SDK (latest) - API v19
 Eclipse 4.2.2
Reporter: Kelvin Dart
Priority: Critical
  Labels: Android4.4.x, Cordova, androidmanifest.xml, window

 Excuse the essay, but I have a very odd issue that I have singled down to 
 Cordova which happens in a very specific circumstance on Android.
 I have provided a project of the stock Cordova Android project which can be 
 found here: http://www.filedropper.com/windowfstest - with a minor 
 modification for the issue I am having.
 I have uploaded a compiled APK to install to your device here: 
 http://www.filedropper.com/windowfstest140509-1404
 Steps to replicate are:
 1) Download and install that APK onto your device (I was using the Samsung 
 Galaxy S4 with Android 4.4.2 running, no root, and stock TouchWiz ROM, I 
 *hope* this occurs on other Android devices but have not had an opportunity 
 to verify).
 2) Start the application and observe an alert appears stating 'dr', then 
 afterwards another alert appears, 'got FS' - if you check the code, you'll 
 see this is normal from my app.initialize().
 3) Once those two alerts have appeared, press the Android 'home' button, to 
 quit to the main Android home screen.
 4) Go into another app or two and just use your phone normally. What we are 
 trying to achieve here is for the Android memory management system to 
 'end'/kill the WindowFSTest app in the backend.
 5) Go into Apps  WindowFSTest (i.e. the app in question) and hopefully it 
 will have restarted - the app has to have restarted for the bug to occur, and 
 observe a few things here:
 a) Verify the app has restarted, this can be verified by the 'dr' popup 
 occuring when Cordova loads.
 b) Once you are confident the app has been restarted, observe the initial 
 'dr' popup, but *not* the 'got FS' popup - this is the bug, the 
 window.requestFileSystem does not fire the callbacks for some reason - and I 
 do not know why.
 N.b. there are a few things to note here which is why the bug is tricky to 
 replicate AND I imagine will be even more difficult to debug at a lower level 
 ;-)
 1) The Android system has to kill the app in the backend once you've pressed 
 the 'home' button - there's no way of determining when this has happened, 
 just use the phone like ordinary for half a minute or so - normally it kills 
 it after a short period.
 2) The way to restart the app is via Apps  WindowFSTest (not via the task 
 manager).
 3) ***IMPORTANT*** the above two steps seem to occur only when you run it 
 from a compiled APK, not directly from source/debug APK - so it's not as easy 
 to debug since you cannot put line breaks in the Java file(s).
 Although not perfect, one way to fix this is to use:
 android:launchMode=singleTop
 In AndroidManifest.xml - since it ensures the app is 'resumed' instead of 
 restarted.
 I can provide a video upon request illustrating the issue.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CB-6689) UIWebview freezes while page behind the link with target='_system' opens in mobile safari

2014-05-30 Thread Jake McAllister (JIRA)


[ 
https://issues.apache.org/jira/browse/CB-6689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14013456#comment-14013456
 ] 

Jake McAllister commented on CB-6689:
-

Yes you are right also at point 7 Cordova app comes back to the foreground the 
phone also freezes

 UIWebview freezes while page behind the link with target='_system' opens in 
 mobile safari
 -

 Key: CB-6689
 URL: https://issues.apache.org/jira/browse/CB-6689
 Project: Apache Cordova
  Issue Type: Bug
  Components: Plugin InAppBrowser
Affects Versions: 3.4.0
 Environment: iOS 7.1, iPhone
Reporter: Jake McAllister

 When opening an external link in cordova app using the inAppBrowser plugin 
 with  target='_system' the cordova app freezes until the page in safari has 
 loaded. This posses a problem where if the user accidentally presses it and 
 wants to go back to the app before the page has loaded in safari the app 
 remain frozen.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CB-6667) window.requestFileSystem - callbacks are not fired in a particular circumstance

2014-05-30 Thread Kelvin Dart (JIRA)

[
https://issues.apache.org/jira/browse/CB-6667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14013462#comment-14013462
]

Kelvin Dart commented on CB-6667:
-

Pastebin available: http://pastebin.com/CWxVg7Pg.

Not a big change at all. However, as mentioned above, you'll need to create a
self-signed APK in order for the default launch mode to occur (it does not seem
to occur otherwise) - then once you have installed the self-signed APK, install
it on the device and follow the steps above.

Hope that helps!

window.requestFileSystem - callbacks are not fired in a particular
circumstance
---

Key: CB-6667
URL: https://issues.apache.org/jira/browse/CB-6667
Project: Apache Cordova
Issue Type: Bug
Components: Plugin File
Affects Versions: 3.4.0
Environment: Mac OS X 10.9.2
Android SDK (latest) - API v19
Eclipse 4.2.2
Reporter: Kelvin Dart
Priority: Critical
Labels: Android4.4.x, Cordova, androidmanifest.xml, window

Excuse the essay, but I have a very odd issue that I have singled down to
Cordova which happens in a very specific circumstance on Android.
I have provided a project of the stock Cordova Android project which can be
found here: http://www.filedropper.com/windowfstest - with a minor
modification for the issue I am having.
I have uploaded a compiled APK to install to your device here:
http://www.filedropper.com/windowfstest140509-1404
Steps to replicate are:
1) Download and install that APK onto your device (I was using the Samsung
Galaxy S4 with Android 4.4.2 running, no root, and stock TouchWiz ROM, I
*hope* this occurs on other Android devices but have not had an opportunity
to verify).
2) Start the application and observe an alert appears stating 'dr', then
afterwards another alert appears, 'got FS' - if you check the code, you'll
see this is normal from my app.initialize().
3) Once those two alerts have appeared, press the Android 'home' button, to
quit to the main Android home screen.
4) Go into another app or two and just use your phone normally. What we are
trying to achieve here is for the Android memory management system to
'end'/kill the WindowFSTest app in the backend.
5) Go into Apps WindowFSTest (i.e. the app in question) and hopefully it
will have restarted - the app has to have restarted for the bug to occur, and
observe a few things here:
a) Verify the app has restarted, this can be verified by the 'dr' popup
occuring when Cordova loads.
b) Once you are confident the app has been restarted, observe the initial
'dr' popup, but *not* the 'got FS' popup - this is the bug, the
window.requestFileSystem does not fire the callbacks for some reason - and I
do not know why.
N.b. there are a few things to note here which is why the bug is tricky to
replicate AND I imagine will be even more difficult to debug at a lower level
;-)
1) The Android system has to kill the app in the backend once you've pressed
the 'home' button - there's no way of determining when this has happened,
just use the phone like ordinary for half a minute or so - normally it kills
it after a short period.
2) The way to restart the app is via Apps WindowFSTest (not via the task
manager).
3) ***IMPORTANT*** the above two steps seem to occur only when you run it
from a compiled APK, not directly from source/debug APK - so it's not as easy
to debug since you cannot put line breaks in the Java file(s).
Although not perfect, one way to fix this is to use:
android:launchMode=singleTop
In AndroidManifest.xml - since it ensures the app is 'resumed' instead of
restarted.
I can provide a video upon request illustrating the issue.

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Issue Comment Deleted] (CB-6667) window.requestFileSystem - callbacks are not fired in a particular circumstance

2014-05-30 Thread Kelvin Dart (JIRA)


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

Kelvin Dart updated CB-6667:


Comment: was deleted

(was: Hi [~iclelland],

I'll provide a pastebin shortly and instructions on how to set it up. It's 
pretty much the default project but with a minor alteration, but I will provide 
that to you anyway!

Rather frustratingly, File Dropper has deleted my files.)

 window.requestFileSystem - callbacks are not fired in a particular 
 circumstance
 ---

 Key: CB-6667
 URL: https://issues.apache.org/jira/browse/CB-6667
 Project: Apache Cordova
  Issue Type: Bug
  Components: Plugin File
Affects Versions: 3.4.0
 Environment: Mac OS X 10.9.2
 Android SDK (latest) - API v19
 Eclipse 4.2.2
Reporter: Kelvin Dart
Priority: Critical
  Labels: Android4.4.x, Cordova, androidmanifest.xml, window

 Excuse the essay, but I have a very odd issue that I have singled down to 
 Cordova which happens in a very specific circumstance on Android.
 I have provided a project of the stock Cordova Android project which can be 
 found here: http://www.filedropper.com/windowfstest - with a minor 
 modification for the issue I am having.
 I have uploaded a compiled APK to install to your device here: 
 http://www.filedropper.com/windowfstest140509-1404
 Steps to replicate are:
 1) Download and install that APK onto your device (I was using the Samsung 
 Galaxy S4 with Android 4.4.2 running, no root, and stock TouchWiz ROM, I 
 *hope* this occurs on other Android devices but have not had an opportunity 
 to verify).
 2) Start the application and observe an alert appears stating 'dr', then 
 afterwards another alert appears, 'got FS' - if you check the code, you'll 
 see this is normal from my app.initialize().
 3) Once those two alerts have appeared, press the Android 'home' button, to 
 quit to the main Android home screen.
 4) Go into another app or two and just use your phone normally. What we are 
 trying to achieve here is for the Android memory management system to 
 'end'/kill the WindowFSTest app in the backend.
 5) Go into Apps  WindowFSTest (i.e. the app in question) and hopefully it 
 will have restarted - the app has to have restarted for the bug to occur, and 
 observe a few things here:
 a) Verify the app has restarted, this can be verified by the 'dr' popup 
 occuring when Cordova loads.
 b) Once you are confident the app has been restarted, observe the initial 
 'dr' popup, but *not* the 'got FS' popup - this is the bug, the 
 window.requestFileSystem does not fire the callbacks for some reason - and I 
 do not know why.
 N.b. there are a few things to note here which is why the bug is tricky to 
 replicate AND I imagine will be even more difficult to debug at a lower level 
 ;-)
 1) The Android system has to kill the app in the backend once you've pressed 
 the 'home' button - there's no way of determining when this has happened, 
 just use the phone like ordinary for half a minute or so - normally it kills 
 it after a short period.
 2) The way to restart the app is via Apps  WindowFSTest (not via the task 
 manager).
 3) ***IMPORTANT*** the above two steps seem to occur only when you run it 
 from a compiled APK, not directly from source/debug APK - so it's not as easy 
 to debug since you cannot put line breaks in the Java file(s).
 Although not perfect, one way to fix this is to use:
 android:launchMode=singleTop
 In AndroidManifest.xml - since it ensures the app is 'resumed' instead of 
 restarted.
 I can provide a video upon request illustrating the issue.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CB-6819) Android set 'nativeToJsModes' to LOAD_URL, soft keyboard closed immediately when use 'input' element in html page

2014-05-30 Thread puchen (JIRA)

puchen created CB-6819:
--

 Summary: Android set 'nativeToJsModes' to LOAD_URL, soft keyboard 
closed immediately when use 'input' element in html page 
 Key: CB-6819
 URL: https://issues.apache.org/jira/browse/CB-6819
 Project: Apache Cordova
  Issue Type: Bug
  Components: Android
Affects Versions: 3.5.0
 Environment: Android 4.3
Reporter: puchen


Android set 'nativeToJsModes' to LOAD_URL in cordova.js, and set 
'DEFAULT_BRIDGE_MODE' to 1 in NativeToJsMessageQueue.java.

When I loaded this:
!DOCTYPE html
html
  head
  /head
  body
input id=address1 type=text/
  /body
/html

Soft keyboard closed immediately that couldn't input anything, when click the 
input field. And it's so weird the soft keyboard could be use correctly, when I 
configured preference name=fullscreen value=true / in res/xml/config.xml.

Please fix it , thanks



--
This message was sent by Atlassian JIRA
(v6.2#6252)

1 2 >

1 - 100 of 130 matches

Mail list logo