Re: Android InAppBrowser with local file blocks XHR on Android 4.1
How about enabling the setting when the IAB is opened with a file:/// URL?
I think the security concern would come when it's opened with a malicious
http:/// URL that then navigated to a file:/// URL.
On Wed, Aug 28, 2013 at 12:24 PM, Pridham, Marcus marcus.prid...@sap.comwrote:
Fair enough. How about adding the following option on Android?
allowuniversalaccessfromfile - set to 'yes' to allow JavaScript running in
the context of a file scheme to be allowed to access content from any
origin.
Eg.
window.open('iab.html', '_blank',
'location=no,toolbar=no,allowuniversalaccessfromfile =yes');
On 8/27/13 10:57 AM, Ian Clelland iclell...@chromium.org wrote:
This looks like a direct port of cordova-android commit #07439ff9 to
InAppBrowser.
The actual setting controls whether file:///* urls are allowed to execute
JavaScript from any context; it is usually false for browsers (at least
Chrome) for security reasons. We turn it on for the main Cordova WebView,
since (presumably) the developer has full control over what URLs can be
loaded into that space. InAppBrowser is meant to be more like a regular
browser view, (i.e. no Cordova APIs), so we haven't chosen to open that
up.
There is probably a good case to be made for allowing this -- certainly
not
as the default setting, but as an option that the app can set in specific
cases when it knows that the IAB is only going to be used for local
content, and won't be executing arbitrary scripts.
Ian
On Mon, Aug 26, 2013 at 10:56 PM, Shazron shaz...@gmail.com wrote:
I'll let the Android devs comment on this more - seems like an easy
patch
but the question is more of a policy thing, whether we want it in there
at
all. If anything, it would be an InAppBrowser option.
On Tue, Aug 27, 2013 at 7:02 AM, Sethi, Raman ra.se...@sap.com wrote:
Hi All,
We ran into this issue with the InAppBrowser with local URLs, happens
on
JellyBean only.
https://issues.apache.org/jira/browse/CB-4083
The fix is suggested in the comments if @Shazron or others can take a
look.
So far we have been patching it on our side and would like customers
to
use the default Cordova plugin.
Thanks
Raman
Re: config.xml refactoring
Michal, Yes. That would be a fairly common scenario for non-CLI users. I download a new Cordova version and migrate my app. In the development cycle, I may also want to have different versions of the same app. That could be because of different Cordova versions or even platform versions (iOS 6 vs iOS 7). Even using CLI, I am thinking I may still run multiple versions. Right now, mainly to keep a consistent version across the platforms plug-ins. Maybe that will go away when we get the versioning strategy figured out. -James Jong On Aug 28, 2013, at 5:09 PM, Michal Mocny mmo...@chromium.org wrote: James, I think that sounds like what we've been thinking -- but, why do you expect to need to copy something when doing an upgrade? Is it because you think upgrade means re-creating a new workspace (which is kinda true right now)? We are hoping to support in-place upgrades, with no copies needed. -Michal On Wed, Aug 28, 2013 at 4:34 PM, James Jong wjamesj...@gmail.com wrote: I think you have covered the common workflows. Some developers will have their own workflow but it should resemble the bin script method in the end. What I'd like to see is the ability to have my app's user config.xml (1 per platform would be fine) and have defaults for what is not specified there. The user specified config.xml takes precedence. So when I upgrade, I just need to copy over the config.xml. -James Jong On Aug 28, 2013, at 2:56 PM, Michal Mocny mmo...@chromium.org wrote: supporting platforms/ as generated content (aka build artifact) is certainly an ultimate goal, but only for the CLI workflow, and even then we would love to suport fallback to sane actions when users don't see it that way and do modify platforms/. Second, a single config.xml shared for all platforms, modified directly by the user maybe might be possible (may involve platform tags or just whitelisted tag per platform), but I'm not sure thats really what we want: * Plugins modify it anyway, so its not really the final version * When we upgrade platforms we may want to add/remove/change default values, so its better to separate platform defaults from user explicit choices -Michal On Wed, Aug 28, 2013 at 2:30 PM, Gorkem Ercan gorkem.er...@gmail.com wrote: We (JBoss Tools) have been playing with ideas on how to work with config.xml. One thing we do right now is to have only one config.xml file, we try to treat config.xml as a universal way of defining cordova applications. We do not have platform versions of config,xml (l think cli massages them per platform right now) but rather copy the config.xml to platform directory (I guess on CLI this would be at the prepare stage) . I think what the developer works with and what gets deployed in the application should be same. It prevents any surprises to developer when he/she is trying to debug a problem. I guess use case/requirement here is not to have config.xml differences between platforms. As a note we treat platforms/... directory as generated content (and regenerate them when needed). -- Gorkem On Wed, Aug 28, 2013 at 1:49 PM, Braden Shepherdson bra...@chromium.org wrote: So we have several bugs[1][2][3] about fixing the handling of config.xml and of upgrading CLI projects. Upgrading platforms is hard because the user might have been modifying files in the platforms/foo directory, and we don't want to go overwriting them. Most of the time the file that's been changed is the platform's config.xml. So we (the Google team) are working on a proposal for rearranging how we handle config.xml files in order to make upgrades easier, and solving some of these other problems (splash screens) easier. Also to make the CLI tooling simpler, because currently the platform config.xml file is both the input and output of several processes (mainly adding and removing plugins, as well as cordova prepare). What we want to know, in writing this proposal is: what use-cases for the config.xml files are there? There seem to be two: 1. Not using CLI, just bin/create and maybe Plugman. 2. Using CLI, and needing to upgrade smoothly from the 3.0 world to 3.1 with these changes to the files. Is there anything else we should be thinking about? If not, we'll have the proposal sent around tomorrow. Braden [1] https://issues.apache.org/jira/browse/CB-4624 [2] https://issues.apache.org/jira/browse/CB-3216 [3] https://issues.apache.org/jira/browse/CB-3571
Re: Android InAppBrowser with local file blocks XHR on Android 4.1
Since I can open a file:// resource that contains http:// pages, the
restriction should not be based on what the IAB was opened with, but what
it is currently open with.
example:
open file://index.html (contains a link to http://badplace.org)
click the link (now at http://badplace.org)
reference some arbitrary file:// resource
On Thu, Aug 29, 2013 at 10:14 AM, Andrew Grieve agri...@chromium.orgwrote:
How about enabling the setting when the IAB is opened with a file:/// URL?
I think the security concern would come when it's opened with a malicious
http:/// URL that then navigated to a file:/// URL.
On Wed, Aug 28, 2013 at 12:24 PM, Pridham, Marcus marcus.prid...@sap.com
wrote:
Fair enough. How about adding the following option on Android?
allowuniversalaccessfromfile - set to 'yes' to allow JavaScript running
in
the context of a file scheme to be allowed to access content from any
origin.
Eg.
window.open('iab.html', '_blank',
'location=no,toolbar=no,allowuniversalaccessfromfile =yes');
On 8/27/13 10:57 AM, Ian Clelland iclell...@chromium.org wrote:
This looks like a direct port of cordova-android commit #07439ff9 to
InAppBrowser.
The actual setting controls whether file:///* urls are allowed to
execute
JavaScript from any context; it is usually false for browsers (at least
Chrome) for security reasons. We turn it on for the main Cordova
WebView,
since (presumably) the developer has full control over what URLs can be
loaded into that space. InAppBrowser is meant to be more like a regular
browser view, (i.e. no Cordova APIs), so we haven't chosen to open that
up.
There is probably a good case to be made for allowing this -- certainly
not
as the default setting, but as an option that the app can set in
specific
cases when it knows that the IAB is only going to be used for local
content, and won't be executing arbitrary scripts.
Ian
On Mon, Aug 26, 2013 at 10:56 PM, Shazron shaz...@gmail.com wrote:
I'll let the Android devs comment on this more - seems like an easy
patch
but the question is more of a policy thing, whether we want it in
there
at
all. If anything, it would be an InAppBrowser option.
On Tue, Aug 27, 2013 at 7:02 AM, Sethi, Raman ra.se...@sap.com
wrote:
Hi All,
We ran into this issue with the InAppBrowser with local URLs,
happens
on
JellyBean only.
https://issues.apache.org/jira/browse/CB-4083
The fix is suggested in the comments if @Shazron or others can take
a
look.
So far we have been patching it on our side and would like customers
to
use the default Cordova plugin.
Thanks
Raman
Re: PROPOSAL: node.js all the script things
We managed to figure out how to get our .js files executable with node on windows/mac/linux without .bat files: https://github.com/MobileChromeApps/mobile-chrome-apps/blob/master/mca.js It's ugly, but works :). For the EMFILE problem, the real solution is to not use shelljs. I did add a work-around to coho to up the ulimit and re-launch, but I think we should really just not use shelljs as a better solution. For node_modules - I think we should just check them in. This is what's recommended by the npm faq, and eliminates the problem of when do I need to run npm install (on upgrade, what if it fails, etc.) On Mon, Aug 26, 2013 at 7:40 PM, Jeffrey Heifetz jheif...@blackberry.comwrote: We've been doing all our scripts in node and have yet to find a better route than .bat scripts that call in. So I'm interested if anyone knows of one. Sent from my BlackBerry 10 smartphone on the Rogers network. From: Benn Mapes Sent: Monday, August 26, 2013 5:53 PM To: dev@cordova.apache.org Reply To: dev@cordova.apache.org Subject: Re: PROPOSAL: node.js all the script things Ok, I'm pushing up these changes to the android master branch. The only problem I see arising is the fact that you need a 'node' prefix before any of the commands on windows. This will break the CLI for android on windows (maybe plugman too), unless we update the tooling to require the node modules instead. I added .bat files (which I really didn't want to) to account for this discrepancy as a temporary solution, but I think we should figure out a better way to do this in the future. Please log any bugs you find with the scripts and assign them to me. I know if one with the ulimit in the terminal being set too low, still gotta figure this one out, it usually errors when waiting for the emulator unless you set your ulimit higher. ~Benn On Mon, Aug 19, 2013 at 2:32 PM, Benn Mapes benn.ma...@gmail.com wrote: Ok, I've started with the node tooling for android and put it up on github. https://github.com/bennmapes/cordova-android/tree/node-toolin If someone can take a look at it and maybe add some suggestions that would be awesome. I added a project.properties file to the root/bin folder so you can `cd` into that folder and run npm install to get the node modules (I only used shell js, and the node_modules folder gets copied to each created project). I ran into a ulimit problem when waiting for the android emulator, I know Andrew solved this for the coho script but I wasn't able to get it working on this one so maybe you could shed some light? Because you can't have executable (at least not that I know of) node scripts in windows you need to call it with a node prefix. Such as `node bin\create asdf` I can also push this branch up to apache if people want it up there, I didn't want to clutter the repo. Cheers, ~Benn On Mon, Aug 12, 2013 at 1:02 PM, Filip Maj f...@adobe.com wrote: An unofficial tally of opinion so far: Android only: Jesse, Anis, Andrew, Lorin All: Fil, Frank Henning, Matt Lantz Benn's vote counts as do android now/soon, with all eventually. So putting effort into this venture for Android seems to be supported for now. If anyone is interested in kicking that off, it's filed as CB-3542 [1]. [1] https://issues.apache.org/jira/browse/CB-3542 On 8/12/13 12:26 PM, Jesse purplecabb...@gmail.com wrote: The question is not _are_ there benefit, but what value do that they bring, versus the effort to do it? In my opinion rewriting it presents a greater risk than (for example) having a Log utility function duplicated across files, as it will _never_ change. To me this is a case of knowing what and when to optimize. We've already talked about this too much, so I will go with whatever the consensus is. @purplecabbage risingj.com On Mon, Aug 12, 2013 at 11:58 AM, Filip Maj f...@adobe.com wrote: One thing about the windows sets of scripts (Jscript-based) is that it is a primitive scripting language. From what I can tell (please correct me if I'm wrong) there's no concept of modules, so code re-use is a problem, which leads us to roll with copy-paste jobs such as the Log function [1] [2] [3] and the exec function [4] [5]. I agree forging ahead and rewriting a bunch of stuff just for the sake of consistency is make-work, but there _are_ benefits that would come out of these efforts. [1] https://github.com/apache/cordova-wp8/blob/master/wp8/template/cordova/li b/ deploy.js#L72 [2] https://github.com/apache/cordova-wp8/blob/master/wp8/template/cordova/li b/ clean.js#L39 [3] https://github.com/apache/cordova-wp8/blob/master/wp8/template/cordova/li b/ build.js#L44 [4] https://github.com/apache/cordova-wp8/blob/master/wp8/template/cordova/li b/ deploy.js#L94 [5]
Re: PROPOSAL: node.js all the script things
I will note that I haven't actually looked at your scripts. If you want an actual code review though, you should create a review request on reviews.apache.org. On Thu, Aug 29, 2013 at 10:47 AM, Andrew Grieve agri...@chromium.orgwrote: We managed to figure out how to get our .js files executable with node on windows/mac/linux without .bat files: https://github.com/MobileChromeApps/mobile-chrome-apps/blob/master/mca.js It's ugly, but works :). For the EMFILE problem, the real solution is to not use shelljs. I did add a work-around to coho to up the ulimit and re-launch, but I think we should really just not use shelljs as a better solution. For node_modules - I think we should just check them in. This is what's recommended by the npm faq, and eliminates the problem of when do I need to run npm install (on upgrade, what if it fails, etc.) On Mon, Aug 26, 2013 at 7:40 PM, Jeffrey Heifetz jheif...@blackberry.comwrote: We've been doing all our scripts in node and have yet to find a better route than .bat scripts that call in. So I'm interested if anyone knows of one. Sent from my BlackBerry 10 smartphone on the Rogers network. From: Benn Mapes Sent: Monday, August 26, 2013 5:53 PM To: dev@cordova.apache.org Reply To: dev@cordova.apache.org Subject: Re: PROPOSAL: node.js all the script things Ok, I'm pushing up these changes to the android master branch. The only problem I see arising is the fact that you need a 'node' prefix before any of the commands on windows. This will break the CLI for android on windows (maybe plugman too), unless we update the tooling to require the node modules instead. I added .bat files (which I really didn't want to) to account for this discrepancy as a temporary solution, but I think we should figure out a better way to do this in the future. Please log any bugs you find with the scripts and assign them to me. I know if one with the ulimit in the terminal being set too low, still gotta figure this one out, it usually errors when waiting for the emulator unless you set your ulimit higher. ~Benn On Mon, Aug 19, 2013 at 2:32 PM, Benn Mapes benn.ma...@gmail.com wrote: Ok, I've started with the node tooling for android and put it up on github. https://github.com/bennmapes/cordova-android/tree/node-toolin If someone can take a look at it and maybe add some suggestions that would be awesome. I added a project.properties file to the root/bin folder so you can `cd` into that folder and run npm install to get the node modules (I only used shell js, and the node_modules folder gets copied to each created project). I ran into a ulimit problem when waiting for the android emulator, I know Andrew solved this for the coho script but I wasn't able to get it working on this one so maybe you could shed some light? Because you can't have executable (at least not that I know of) node scripts in windows you need to call it with a node prefix. Such as `node bin\create asdf` I can also push this branch up to apache if people want it up there, I didn't want to clutter the repo. Cheers, ~Benn On Mon, Aug 12, 2013 at 1:02 PM, Filip Maj f...@adobe.com wrote: An unofficial tally of opinion so far: Android only: Jesse, Anis, Andrew, Lorin All: Fil, Frank Henning, Matt Lantz Benn's vote counts as do android now/soon, with all eventually. So putting effort into this venture for Android seems to be supported for now. If anyone is interested in kicking that off, it's filed as CB-3542 [1]. [1] https://issues.apache.org/jira/browse/CB-3542 On 8/12/13 12:26 PM, Jesse purplecabb...@gmail.com wrote: The question is not _are_ there benefit, but what value do that they bring, versus the effort to do it? In my opinion rewriting it presents a greater risk than (for example) having a Log utility function duplicated across files, as it will _never_ change. To me this is a case of knowing what and when to optimize. We've already talked about this too much, so I will go with whatever the consensus is. @purplecabbage risingj.com On Mon, Aug 12, 2013 at 11:58 AM, Filip Maj f...@adobe.com wrote: One thing about the windows sets of scripts (Jscript-based) is that it is a primitive scripting language. From what I can tell (please correct me if I'm wrong) there's no concept of modules, so code re-use is a problem, which leads us to roll with copy-paste jobs such as the Log function [1] [2] [3] and the exec function [4] [5]. I agree forging ahead and rewriting a bunch of stuff just for the sake of consistency is make-work, but there _are_ benefits that would come out of these efforts. [1] https://github.com/apache/cordova-wp8/blob/master/wp8/template/cordova/li b/ deploy.js#L72 [2] https://github.com/apache/cordova-wp8/blob/master/wp8/template/cordova/li b/
Re: [Android] Cordova Camera not working, errors on resolveLocalFileSystemURI(), any ideas?
Hey Joe, any update on this? what is broken? On Fri, Aug 23, 2013 at 12:48 PM, Joe Bowser bows...@gmail.com wrote: Hey I found a pretty serious bug on master with the Camera and I'm wondering if there's been additional changes to the core APIs that would cause this to not work, namely any fixes in the CordovaResourceAPI? It seems that for some reason the Camera isn't finding the photo right away because of these changes. I'm going to keep investigating, since it seems weird that the camera would break, but this looks pretty broken right now. Joe
Re: [Android] Cordova Camera not working, errors on resolveLocalFileSystemURI(), any ideas?
Joe made this bug https://issues.apache.org/jira/browse/CB-4656 with details. On Thu, Aug 29, 2013 at 11:02 AM, Andrew Grieve agri...@chromium.orgwrote: Hey Joe, any update on this? what is broken? On Fri, Aug 23, 2013 at 12:48 PM, Joe Bowser bows...@gmail.com wrote: Hey I found a pretty serious bug on master with the Camera and I'm wondering if there's been additional changes to the core APIs that would cause this to not work, namely any fixes in the CordovaResourceAPI? It seems that for some reason the Camera isn't finding the photo right away because of these changes. I'm going to keep investigating, since it seems weird that the camera would break, but this looks pretty broken right now. Joe
Re: Android InAppBrowser with local file blocks XHR on Android 4.1
On Thu, Aug 29, 2013 at 10:31 AM, David Kemp drk...@google.com wrote:
Since I can open a file:// resource that contains http:// pages, the
restriction should not be based on what the IAB was opened with, but what
it is currently open with.
example:
open file://index.html (contains a link to http://badplace.org)
click the link (now at http://badplace.org)
reference some arbitrary file:// resource
That should still fail; I belive that the Android WebView setting only
comes into effect when the source of the request is a file:/// URL.
Automatically setting it based on the original URL is an interesting idea.
I think, though, that there are probably use cases for opening an IAB on a
file:/// URL where you *shouldn't* by default allow access to everything.
Maybe the application is caching resources for offline use, which aren't
necessarily trusted.
I'm in favour of adding an option to window.open.
allowuniversalaccessfromfile=yes
is a bit wordy, though, and looks *very* android-specific.
Ian
On Thu, Aug 29, 2013 at 10:14 AM, Andrew Grieve agri...@chromium.org
wrote:
How about enabling the setting when the IAB is opened with a file:///
URL?
I think the security concern would come when it's opened with a malicious
http:/// URL that then navigated to a file:/// URL.
On Wed, Aug 28, 2013 at 12:24 PM, Pridham, Marcus
marcus.prid...@sap.com
wrote:
Fair enough. How about adding the following option on Android?
allowuniversalaccessfromfile - set to 'yes' to allow JavaScript running
in
the context of a file scheme to be allowed to access content from any
origin.
Eg.
window.open('iab.html', '_blank',
'location=no,toolbar=no,allowuniversalaccessfromfile =yes');
On 8/27/13 10:57 AM, Ian Clelland iclell...@chromium.org wrote:
This looks like a direct port of cordova-android commit #07439ff9 to
InAppBrowser.
The actual setting controls whether file:///* urls are allowed to
execute
JavaScript from any context; it is usually false for browsers (at
least
Chrome) for security reasons. We turn it on for the main Cordova
WebView,
since (presumably) the developer has full control over what URLs can
be
loaded into that space. InAppBrowser is meant to be more like a
regular
browser view, (i.e. no Cordova APIs), so we haven't chosen to open
that
up.
There is probably a good case to be made for allowing this --
certainly
not
as the default setting, but as an option that the app can set in
specific
cases when it knows that the IAB is only going to be used for local
content, and won't be executing arbitrary scripts.
Ian
On Mon, Aug 26, 2013 at 10:56 PM, Shazron shaz...@gmail.com wrote:
I'll let the Android devs comment on this more - seems like an easy
patch
but the question is more of a policy thing, whether we want it in
there
at
all. If anything, it would be an InAppBrowser option.
On Tue, Aug 27, 2013 at 7:02 AM, Sethi, Raman ra.se...@sap.com
wrote:
Hi All,
We ran into this issue with the InAppBrowser with local URLs,
happens
on
JellyBean only.
https://issues.apache.org/jira/browse/CB-4083
The fix is suggested in the comments if @Shazron or others can
take
a
look.
So far we have been patching it on our side and would like
customers
to
use the default Cordova plugin.
Thanks
Raman
Re: Merge plugin dev branchs into master
Steve, did you do this? I didn't notice a JIRA issue or blog post. On Fri, Aug 16, 2013 at 10:59 AM, Andrew Grieve agri...@chromium.orgwrote: Thought of another step! Generate a changelog, and turn it into a blog post so that people will know about the update :) On Thu, Aug 15, 2013 at 4:59 PM, Steven Gill stevengil...@gmail.comwrote: Thanks for the feedback Andrew! Sounds good to me. I am going to go through these steps today. On Thu, Aug 15, 2013 at 12:07 PM, Andrew Grieve agri...@chromium.org wrote: Great! I agree it's time someone take a stab at this! On Thu, Aug 15, 2013 at 3:00 PM, Steven Gill stevengil...@gmail.com wrote: I want to try and flush out the process for merging the dev branches for the core plugins into master and get it onto the wiki. Currently the dev branches have some readme changes, namespace changes and package changes for android. I don't believe any of these changes should be breaking changes. Process 1. Create issue on jira for running mobile spec tests on all platforms using dev branch of plugins 2. Test on all platforms 3. Merge in change into master 4. Publish to plugins.cordova.io? Do we really need to test the plugins on all the platforms for changes that won't affect them at all? I think no. And we should only test plugins that have changes to them (in this case all of them). Should add in bumping of the version number. I think one thing to add to the process is to create mobilespec with the existing versions of plugins, then `cordova plugin rm` them all, then `cordova plugin add` the new ones using a URL that points to the dev branch. aka, test out the upgrade process.
Android a11y, Whitelists and Offline Story
Hey The last week, I've been doing some preliminary work on Android accessibility, and after fiddling with Cordova, I've come to some pretty bad realizations: 1. Android Accessibility in a WebView is achieved the same way we do PhoneGap, except that their JS is injected from a static server. This means that if the app is offline, it's not accessible to the blind 2. Most of Android isn't actually accessible, namely the Play Store, which is how most people discover apps. Play Store, Play Store, Play Store, Play Store doesn't seem super useful. 3. There's no real point trying to make accessibility work on Gingerbread, since the accessibility libraries don't really work on that platform, and aren't as robust. 4. Accessibility is HARD, especially when you're not blind. 5. The splashscreen says Alert. WTF? So, one major issue that I ran into is that you have to whitelist gstatic.com so that you can get the Accessibility Javascript. It'd be great to see how the accessibility JS works and communicates with the two interfaces that it adds to the WebView. BTW: Here's the Java portion of Accessibility on the WebView: https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/webkit/AccessibilityInjector.java Any ideas on how we can take advantage of this, make it better when we're offline. Right now, it just treats the webview as one giant view. Thoughts on this would be great. Joe
Re: Android a11y, Whitelists and Offline Story
(I thought Android a11y was going to be Ally Ogilvie :) ) Some thoughts inline: On Thu, Aug 29, 2013 at 1:25 PM, Joe Bowser bows...@gmail.com wrote: Hey The last week, I've been doing some preliminary work on Android accessibility, and after fiddling with Cordova, I've come to some pretty bad realizations: 1. Android Accessibility in a WebView is achieved the same way we do PhoneGap, except that their JS is injected from a static server. This means that if the app is offline, it's not accessible to the blind Do you mean that this is true for most android applications / web sites, but that Cordova is currently better than that? (Or that PhoneGap is better than that, at least?) 2. Most of Android isn't actually accessible, namely the Play Store, which is how most people discover apps. Play Store, Play Store, Play Store, Play Store doesn't seem super useful. 3. There's no real point trying to make accessibility work on Gingerbread, since the accessibility libraries don't really work on that platform, and aren't as robust. 4. Accessibility is HARD, especially when you're not blind. Agreed. It takes an extra level of attention to detail to get that sort of stuff right, and you have to constantly stay on top of it. 5. The splashscreen says Alert. WTF? Is this the Cordova app splashscreen? That's really strange, unless something is intercepting / reading out the prompt call from the bridge. Although in that case, I would expect it to happen pretty much continuously through an app. So, one major issue that I ran into is that you have to whitelist gstatic.com so that you can get the Accessibility Javascript. It'd be great to see how the accessibility JS works and communicates with the two interfaces that it adds to the WebView. If there's an A11y plugin, then that can be added with plugin.xml. If this should be a core feature, then we can easily build it in to the whitelist, and enable it by default, like we do with file:///* and android-asset://* urls. Ian BTW: Here's the Java portion of Accessibility on the WebView: https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/webkit/AccessibilityInjector.java Any ideas on how we can take advantage of this, make it better when we're offline. Right now, it just treats the webview as one giant view. Thoughts on this would be great. Joe
Re: Android a11y, Whitelists and Offline Story
Not something I've dealt with before :( From your description, perhaps we could write a plugin that bundles a copy of the gstatic files and injects them when offline? On Thu, Aug 29, 2013 at 1:25 PM, Joe Bowser bows...@gmail.com wrote: Hey The last week, I've been doing some preliminary work on Android accessibility, and after fiddling with Cordova, I've come to some pretty bad realizations: 1. Android Accessibility in a WebView is achieved the same way we do PhoneGap, except that their JS is injected from a static server. This means that if the app is offline, it's not accessible to the blind 2. Most of Android isn't actually accessible, namely the Play Store, which is how most people discover apps. Play Store, Play Store, Play Store, Play Store doesn't seem super useful. 3. There's no real point trying to make accessibility work on Gingerbread, since the accessibility libraries don't really work on that platform, and aren't as robust. 4. Accessibility is HARD, especially when you're not blind. 5. The splashscreen says Alert. WTF? So, one major issue that I ran into is that you have to whitelist gstatic.com so that you can get the Accessibility Javascript. It'd be great to see how the accessibility JS works and communicates with the two interfaces that it adds to the WebView. BTW: Here's the Java portion of Accessibility on the WebView: https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/webkit/AccessibilityInjector.java Any ideas on how we can take advantage of this, make it better when we're offline. Right now, it just treats the webview as one giant view. Thoughts on this would be great. Joe
Re: Android a11y, Whitelists and Offline Story
More in-line comments: On Thu, Aug 29, 2013 at 1:25 PM, Joe Bowser bows...@gmail.com wrote: 3. There's no real point trying to make accessibility work on Gingerbread, since the accessibility libraries don't really work on that platform, and aren't as robust. Agreed, I've looked into this before and I haven't had any success with anything less than Android 4.0. 4. Accessibility is HARD, especially when you're not blind. Agreed. It takes an extra level of attention to detail to get that sort of stuff right, and you have to constantly stay on top of it. Double agreed. We had to do a full release of adding a11y to our product about 5 years ago and it was the most frustrating and yet enlightening development experience ever. 5. The splashscreen says Alert. WTF? Is this the Cordova app splashscreen? That's really strange, unless something is intercepting / reading out the prompt call from the bridge. Although in that case, I would expect it to happen pretty much continuously through an app. The splash screen on Android is actually a full screen dialog. Even though there is no title bar shown I'm betting it picks up the default value Alert. We should probably set it to something more accessible like Splash Screen. Although, then we get into internationalization (i18n) issues for blind Dutch users :) Simon
Re: Merge plugin dev branchs into master
Yes, updating the wiki would be helpful. I'd like to submit a fix but since I don't follow this list all this time, I'm not sure if I should be working off of dev or master. Based on the above thread I think dev? thanks, -becky On Thu, Aug 29, 2013 at 11:48 AM, Andrew Grieve agri...@chromium.orgwrote: Steve, did you do this? I didn't notice a JIRA issue or blog post. On Fri, Aug 16, 2013 at 10:59 AM, Andrew Grieve agri...@chromium.org wrote: Thought of another step! Generate a changelog, and turn it into a blog post so that people will know about the update :) On Thu, Aug 15, 2013 at 4:59 PM, Steven Gill stevengil...@gmail.com wrote: Thanks for the feedback Andrew! Sounds good to me. I am going to go through these steps today. On Thu, Aug 15, 2013 at 12:07 PM, Andrew Grieve agri...@chromium.org wrote: Great! I agree it's time someone take a stab at this! On Thu, Aug 15, 2013 at 3:00 PM, Steven Gill stevengil...@gmail.com wrote: I want to try and flush out the process for merging the dev branches for the core plugins into master and get it onto the wiki. Currently the dev branches have some readme changes, namespace changes and package changes for android. I don't believe any of these changes should be breaking changes. Process 1. Create issue on jira for running mobile spec tests on all platforms using dev branch of plugins 2. Test on all platforms 3. Merge in change into master 4. Publish to plugins.cordova.io? Do we really need to test the plugins on all the platforms for changes that won't affect them at all? I think no. And we should only test plugins that have changes to them (in this case all of them). Should add in bumping of the version number. I think one thing to add to the process is to create mobilespec with the existing versions of plugins, then `cordova plugin rm` them all, then `cordova plugin add` the new ones using a URL that points to the dev branch. aka, test out the upgrade process.
Cordova Continuous Integration
We are now running the continuous integration system internally, monitoring Android and iOS. If you are interested in testing, please have a look at what I have and comment. The readme is reasonably complete for a simple stand-alone system like I have here. https://github.com/drkemp/bb-test This is NOT checked into the medic repo. It is substantially diverged, so that might not even make sense. Also, I am working on getting the system exposed to the outside world so everyone can see the state of affairs. The document below outlines how I am proposing to deploy this in a (moderately) secure way. https://docs.google.com/document/d/1t94N8u4Sgf-545wWsRjoURUIF4C0pHYyAQKPbPWncVQ/edit?usp=sharing David Kemp
RE: Android a11y, Whitelists and Offline Story
(I thought Android a11y was going to be Ally Ogilvie :) ) Hell yeah! a11y o5e plugin, don't use it though, it won't aid accessibility for anything other than receiving beer :) :) Don't know much about accessibilityInjector, but could imagine some haxors would love to use TextToSpeechWrapper XD Sent from my Windows Phone From: Ian Clelland Sent: 30/08/2013 02:34 To: dev@cordova.apache.org; bows...@apache.org Subject: Re: Android a11y, Whitelists and Offline Story (I thought Android a11y was going to be Ally Ogilvie :) ) Some thoughts inline: On Thu, Aug 29, 2013 at 1:25 PM, Joe Bowser bows...@gmail.com wrote: Hey The last week, I've been doing some preliminary work on Android accessibility, and after fiddling with Cordova, I've come to some pretty bad realizations: 1. Android Accessibility in a WebView is achieved the same way we do PhoneGap, except that their JS is injected from a static server. This means that if the app is offline, it's not accessible to the blind Do you mean that this is true for most android applications / web sites, but that Cordova is currently better than that? (Or that PhoneGap is better than that, at least?) 2. Most of Android isn't actually accessible, namely the Play Store, which is how most people discover apps. Play Store, Play Store, Play Store, Play Store doesn't seem super useful. 3. There's no real point trying to make accessibility work on Gingerbread, since the accessibility libraries don't really work on that platform, and aren't as robust. 4. Accessibility is HARD, especially when you're not blind. Agreed. It takes an extra level of attention to detail to get that sort of stuff right, and you have to constantly stay on top of it. 5. The splashscreen says Alert. WTF? Is this the Cordova app splashscreen? That's really strange, unless something is intercepting / reading out the prompt call from the bridge. Although in that case, I would expect it to happen pretty much continuously through an app. So, one major issue that I ran into is that you have to whitelist gstatic.com so that you can get the Accessibility Javascript. It'd be great to see how the accessibility JS works and communicates with the two interfaces that it adds to the WebView. If there's an A11y plugin, then that can be added with plugin.xml. If this should be a core feature, then we can easily build it in to the whitelist, and enable it by default, like we do with file:///* and android-asset://* urls. Ian BTW: Here's the Java portion of Accessibility on the WebView: https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/webkit/AccessibilityInjector.java Any ideas on how we can take advantage of this, make it better when we're offline. Right now, it just treats the webview as one giant view. Thoughts on this would be great. Joe
Audio Data Manipulation
Hi, I'm working on a mobile speech recognition system and I'd like to use the cordova project. Unfortunately the AudioContext won't worked well on my tests since the current state of the platforms don't gives correct support, according the general comments on the web. So i wonder if the Media API can be extended to be able to manipulate the audio on the fly buffering the data on bytearray then given the full control over it to developer? Do you already think about that and/or do you have any plan to implement it on the future? Thanks -- Bruno Lima Cardoso Linkedin: http://br.linkedin.com/pub/bruno-lima/1b/7a8/755 Cel: +55 21 88511900 Skype: limazix MSN: blimacard...@hotmail.com
Re: Android a11y, Whitelists and Offline Story
Sadly, the main problem with accessibility that I found was more to do with WebKit's handling of DOM nodes, and less of the text-to-speech part. I guess it doesn't really matter if the DOM node's bounding box is far away from where the DIV appears if you're blind, but it's still confusing to me. The main advantage is really getting the gestures down, and not the TTS. TTS is just the output. On Thu, Aug 29, 2013 at 5:44 PM, Ally Ogilvie aogil...@wizcorp.jp wrote: (I thought Android a11y was going to be Ally Ogilvie :) ) Hell yeah! a11y o5e plugin, don't use it though, it won't aid accessibility for anything other than receiving beer :) :) Don't know much about accessibilityInjector, but could imagine some haxors would love to use TextToSpeechWrapper XD Sent from my Windows Phone From: Ian Clelland Sent: 30/08/2013 02:34 To: dev@cordova.apache.org; bows...@apache.org Subject: Re: Android a11y, Whitelists and Offline Story (I thought Android a11y was going to be Ally Ogilvie :) ) Some thoughts inline: On Thu, Aug 29, 2013 at 1:25 PM, Joe Bowser bows...@gmail.com wrote: Hey The last week, I've been doing some preliminary work on Android accessibility, and after fiddling with Cordova, I've come to some pretty bad realizations: 1. Android Accessibility in a WebView is achieved the same way we do PhoneGap, except that their JS is injected from a static server. This means that if the app is offline, it's not accessible to the blind Do you mean that this is true for most android applications / web sites, but that Cordova is currently better than that? (Or that PhoneGap is better than that, at least?) 2. Most of Android isn't actually accessible, namely the Play Store, which is how most people discover apps. Play Store, Play Store, Play Store, Play Store doesn't seem super useful. 3. There's no real point trying to make accessibility work on Gingerbread, since the accessibility libraries don't really work on that platform, and aren't as robust. 4. Accessibility is HARD, especially when you're not blind. Agreed. It takes an extra level of attention to detail to get that sort of stuff right, and you have to constantly stay on top of it. 5. The splashscreen says Alert. WTF? Is this the Cordova app splashscreen? That's really strange, unless something is intercepting / reading out the prompt call from the bridge. Although in that case, I would expect it to happen pretty much continuously through an app. So, one major issue that I ran into is that you have to whitelist gstatic.com so that you can get the Accessibility Javascript. It'd be great to see how the accessibility JS works and communicates with the two interfaces that it adds to the WebView. If there's an A11y plugin, then that can be added with plugin.xml. If this should be a core feature, then we can easily build it in to the whitelist, and enable it by default, like we do with file:///* and android-asset://* urls. Ian BTW: Here's the Java portion of Accessibility on the WebView: https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/webkit/AccessibilityInjector.java Any ideas on how we can take advantage of this, make it better when we're offline. Right now, it just treats the webview as one giant view. Thoughts on this would be great. Joe
