Re: Proposal: Change JIRA to have bugs as unassigned by default
What about the start/stop progress? On Wed, Sep 18, 2013 at 9:03 PM, Ian Clelland iclell...@chromium.org wrote: +1 Also, if you are a component owner, it's pretty simple in JIRA to add a dashboard widget that shows you all unassigned bugs in your component. Ian On Wed, Sep 18, 2013 at 11:49 PM, Joe Bowser bows...@gmail.com wrote: +1
Re: [Android] WebView, InAppBrowser and UI Threads
Why don't we make relative urls a developer concern? The developer should know
their own package, and it can be easily resolved using current window.location
and expected location of the file.
A minor rant, while we are on the subject of iab:
I don't understand why this executeScript madness was added. Why not just call
for a new URL with a javascript:prefix ?
If you want a full blown web-browser control then make a new plugin, iab
(originally ChildBrowser) was intended to show potentially unsafe code inside
your app without risk. The API is already non-standard, and worse still it
mimics a standard api but mutated. There are probably security implications to
all of these choices as well.
What is the use-case for insertCSS? Is it to load someone else's html with your
style sheet?
Sent from my iPhone
On Sep 18, 2013, at 7:31 PM, Andrew Grieve agri...@chromium.org wrote:
I assigned it to David just because I thought it would be a good bug for
him and thought it sounded important to fix. I don't think he's in any
hurry to get to it, so feel free to assign it to yourself. I don't really
consider bugs to be actually assigned when they are assigned to the default
person since it's not clear that anyone's looked at it. Maybe it'd be worth
having new bugs come in as unassigned, so that when someone assigns it,
it's more meaningful. I'll start another thread to discuss this idea.
Anyways, I've thought a good amount about this problem previously (what to
do with relative URLs), and I think the best solution is to resolve
relative URLs in JS. iOS also has no good way of resolving relative URLs
from native. I added a function to do just that in this release -
require('cordova/urlutil').makeAbsolute(url)
I'll make a note of this on the bug.
On Wed, Sep 18, 2013 at 5:21 PM, Joe Bowser bows...@gmail.com wrote:
I'm currently trying to figure out CB-4858, which got assigned to
David, but I'm finding that I'm getting stuck at this part:
private String updateUrl(String url) {
Uri newUrl = Uri.parse(url);
if (newUrl.isRelative()) {
//url = this.webView.getUrl().substring(0,
this.webView.getUrl().lastIndexOf(/)+1) + url;
}
return url;
}
The problem with this code is that all methods on the WebView class
must run on the UI thread. Now, there's no easy way for us to pass
this data back because now we're doing asynchronous Java where we have
to wait for the UI thread to give us back the URL so we can find out
what our base path is.
We could override this in CordovaWebView, getting around the check,
but I think that this might not be the right thing to do.
Anyway, I'm content letting David chew on this, since I didn't know it
got assigned to him (JIRA didn't send me the e-mail), but I'd be
interested in seeing how this gets solved, because it's particularly
ugly.
Re: 3.1 Release
Once the platforms are tagged, I can handle the docs. I'll need to review our release process and see how the docs can best abide by them. On Wed, Sep 18, 2013 at 1:34 PM, Andrew Grieve agri...@chromium.org wrote: Shaz - Thanks for the update :). If iOS is the last one then I'd say let's go without, but maybe keep at it until we get BB tagged? (just my opinion) Heading home now - anyone know if Lorin is away or not? On Wed, Sep 18, 2013 at 3:35 PM, Shazron shaz...@gmail.com wrote: When i mean ios-deploy still works, it _installs_ it on the device, but does _not_ run it. On Wed, Sep 18, 2013 at 12:31 PM, Shazron shaz...@gmail.com wrote: I'm 99% done with iOS specific fixes. One last one I'm trying to do is ios-deploy with lldb: https://issues.apache.org/jira/browse/CB-4804 This means if I don't get this fix in, we _can_ deploy from the command line using ios-deploy _but_ we can't attach to the debugger. Will that be acceptable you think? On Wed, Sep 18, 2013 at 12:07 PM, Andrew Grieve agri...@chromium.org wrote: Ping Lorin Shaz. On Wed, Sep 18, 2013 at 2:19 AM, Steven Gill stevengil...@gmail.com wrote: FFOS will be tagged tomorrow. I have a few changes I am going to get in tomorrow before tagging but it will be good to go very soon! With FFOS, Only two plugins have been ported so far (vibration and device). We are going to continue to add firefoxos support to plugins post release. I don't think we should start officially promoting support for FFOS until we have more plugins. For 3.1, it will be available for users to try out, test, give feedback, etc. Cheers, -Steve On Tue, Sep 17, 2013 at 7:38 PM, Andrew Grieve agri...@chromium.org wrote: Thanks Jesse! Great work on being on top of things. If changes were done in plugin repos, then those aren't a part of this release anyways and will be picked up by the RELEASENOTES.md within the plugin repos on the next plugins release. I think it's up to you if you want to start writing RELEASENOTES.md for WP7+8. My thinking was just that doing so would make release announcements easier. Since WP7 and WP8 are in the same repo, does it make sense to have different subtasks for their taggings? If so, I'll add it to the template, if not, maybe I'll just change WP8 to say WP7+WP8? WDYT? Shaz - I see you're still checking in iOS7 fixes. Do you think you'll be able to tag iOS / OSX soon? Lorin - Same question for BB. Will you be able to write an update script for it (CB-4776) Steve - Likewise for FF I'd really like this tagging to be done tomorrow so that we can test out RC1 using RC1 of CLI. On Tue, Sep 17, 2013 at 10:00 PM, Jesse purplecabb...@gmail.com wrote: WP7, WP8, and Windows8 are all tagged 3.1.0-rc1 re: Changelog It is a little more difficult in these cases, and I n'er volunteered to do it, so whatevs - WP7+8 live in one repo, so their changes would need to be demuxed - all the changes for Windows8 have happened in the plugin repos, and cordova-js, so changelog would be empty Maybe I'll get this together for the 3.1.0, we'll see. @purplecabbage risingj.com On Tue, Sep 17, 2013 at 12:34 PM, Andrew Grieve agri...@chromium.org wrote: For the last plugin release, I tagged them with the plugin's version. (e.g. r0.2.1 for cordova-plugin-file). Only plugins that had changes were included in the release, so some may still not have any release tags. On Tue, Sep 17, 2013 at 3:31 PM, Braden Shepherdson bra...@chromium.org wrote: My understanding is that the plugins are totally independent of Cordova versions, and release on their own weekly-at-the-most-frequent cycle. They only depend on Cordova versions when they need a sufficiently new platform to support some feature (binary bridge, for example), and then they set engine tags appropriately. Braden On Tue, Sep 17, 2013 at 3:18 PM, Marcel Kinard cmarc...@gmail.com wrote: Will the plugin repos get tagged? If so, do they get tagged on every weekly cycle, or only when a cadence lines up with a weekly cycle, or both? I see that StepsForPluginRelease wiki say it will happen, and the most recent coho looks like it will do it, but I currently see only tags for 3.0.0 and 3.0.0rc1 in the plugins repos, not a weekly tag. Thanks! On Sep 9, 2013, at 10:42 AM, Andrew Grieve agri...@chromium.org wrote: I think it's time to get the ball rolling on this. It'll be the first release post-3.0, so will likely have a few bumps to work through. How about:
Re: [Android] The state of WebSQL on Android 4.x
The troubling part here is that WebSQL is broken (iOS7 introduced new bugs,
too!) on iOS and Android, not supported on non-Webkit browsers, and crap.
But... IndexedDB is arguably more crap, though less buggy, but it isn't
supported on /anything/ mobile to my knowledge. This has been a crippling
problem when our chrome-apps-on-cordova team has been porting apps. If some
app uses IndexedDB, we're out of luck.
There is a shim that uses WebSQL as a back-end for IndexedDB, intended to
be used on these devices. But then it's still crap and buggy. I started
poking at it to see if I could replace this with a shim of IndexedDB with a
Cordova plugin (maybe File, more likely something specialized) as the
backend. That's probably possible, though it was complicated in a couple of
places by the fact that some IDB/WebSQL calls are sync but all Cordova
native calls are async. Probably still possible to do that port, if we
think it's worthwhile. It would be a nontrivial project, though, and the
IDB interface and performance still suck.
Braden
On Thu, Sep 19, 2013 at 8:08 AM, Brian LeRoux b...@brian.io wrote:
Deprecated.
On Sep 19, 2013 5:04 AM, Andrew Grieve agri...@chromium.org wrote:
If it's easy to support, then I think it's worth doing.
A custom scheme would work, but I think we can do it with a less
intrusive
change:
We came up with the following hack during our chrome-apps-on-cordova work
for having CORS work when on a custom scheme. Should work for WebSQL as
well though. It takes advantage of the fact that file:/// pages can
access
window objects of opened windows that are on different domains. It goes
like:
The JS Code:
var win = window.open(websql://ftw);
// wait for window to load. Maybe via onload event? Or via polling?
win.onload = function() {
window.openDatabase = win.openDatabase;
}
// The Java code:
app.getSettings().setSupportMultipleWindows(true);
// In Chrome Client:
@SuppressWarnings(unused)
private WebView newWebView = null;
public boolean onCreateWindow (WebView view, boolean isDialog,
boolean
isUserGesture, Message resultMsg) {
WebView.WebViewTransport transport = (WebView.WebViewTransport)
resultMsg.obj;
newWebView = new WebView(act);
newWebView.getSettings().setJavaScriptEnabled(true);
newWebView.setWebViewClient(new WebViewClient(){
@Override
public WebResourceResponse shouldInterceptRequest(final
WebView view, String url) {
return a response that is just an empty page.
}
});
transport.setWebView(newWebView);
resultMsg.sendToTarget();
return true;
}
On Wed, Sep 18, 2013 at 7:43 PM, Jesse purplecabb...@gmail.com wrote:
Windows Phone has never supported it. I have always felt that this is
more
of a browser responsibility and didn't belong in the 'phonegap
features'
matrix. Just like we don't list querySelectorAll or SVG support.
Someone needs to write a JS shim that uses the File API which IS
available
on all the devices in cordova.
@purplecabbage
risingj.com
On Wed, Sep 18, 2013 at 2:31 PM, Joe Bowser bows...@gmail.com wrote:
Ok, We've been ignoring this for quite a while, but it's not going
away:
There's still people who want to use WebSQL, and WebSQL is still
totally broken. Part of the reason it's broken is the fact that
Android prevents us from using the official WebSQL API on file URIs,
and that we have a nasty collision with the official API on Android.
So, what should we do?
1. Use a custom URI scheme?
2. Fix the JS so it aliases the existing WebSQL, and keep using our
own WebSQL plugin.
3. Just say it's deprecated and leave it at that?
If we say we're tossing WebSQL by the wayside, what do we support
instead? Seriously, what do people think of this, because I'm not
sure what we should do here.
Joe
Re: Proposal: Change JIRA to have bugs as unassigned by default
Does JIRA have the New state for a bug? That might be another way to signal whether the bug has ever been looked at, if they begin as New and then we change them to Accepted or whatever it's called. Braden On Thu, Sep 19, 2013 at 10:29 AM, Andrew Grieve agri...@chromium.orgwrote: Okay, I've made the change. Let's try it out :) I think start/stop is good if you've actually started working on something, but it's different from this new bug has been looked at by someone. On Thu, Sep 19, 2013 at 2:51 AM, Anis KADRI anis.ka...@gmail.com wrote: What about the start/stop progress? On Wed, Sep 18, 2013 at 9:03 PM, Ian Clelland iclell...@chromium.org wrote: +1 Also, if you are a component owner, it's pretty simple in JIRA to add a dashboard widget that shows you all unassigned bugs in your component. Ian On Wed, Sep 18, 2013 at 11:49 PM, Joe Bowser bows...@gmail.com wrote: +1
Re: 3.1 Release
+Jeffrey - maybe you could take on the BlackBerry component for this release? On Thu, Sep 19, 2013 at 10:00 AM, Michael Brooks mich...@michaelbrooks.cawrote: Once the platforms are tagged, I can handle the docs. I'll need to review our release process and see how the docs can best abide by them. On Wed, Sep 18, 2013 at 1:34 PM, Andrew Grieve agri...@chromium.org wrote: Shaz - Thanks for the update :). If iOS is the last one then I'd say let's go without, but maybe keep at it until we get BB tagged? (just my opinion) Heading home now - anyone know if Lorin is away or not? On Wed, Sep 18, 2013 at 3:35 PM, Shazron shaz...@gmail.com wrote: When i mean ios-deploy still works, it _installs_ it on the device, but does _not_ run it. On Wed, Sep 18, 2013 at 12:31 PM, Shazron shaz...@gmail.com wrote: I'm 99% done with iOS specific fixes. One last one I'm trying to do is ios-deploy with lldb: https://issues.apache.org/jira/browse/CB-4804 This means if I don't get this fix in, we _can_ deploy from the command line using ios-deploy _but_ we can't attach to the debugger. Will that be acceptable you think? On Wed, Sep 18, 2013 at 12:07 PM, Andrew Grieve agri...@chromium.org wrote: Ping Lorin Shaz. On Wed, Sep 18, 2013 at 2:19 AM, Steven Gill stevengil...@gmail.com wrote: FFOS will be tagged tomorrow. I have a few changes I am going to get in tomorrow before tagging but it will be good to go very soon! With FFOS, Only two plugins have been ported so far (vibration and device). We are going to continue to add firefoxos support to plugins post release. I don't think we should start officially promoting support for FFOS until we have more plugins. For 3.1, it will be available for users to try out, test, give feedback, etc. Cheers, -Steve On Tue, Sep 17, 2013 at 7:38 PM, Andrew Grieve agri...@chromium.org wrote: Thanks Jesse! Great work on being on top of things. If changes were done in plugin repos, then those aren't a part of this release anyways and will be picked up by the RELEASENOTES.md within the plugin repos on the next plugins release. I think it's up to you if you want to start writing RELEASENOTES.md for WP7+8. My thinking was just that doing so would make release announcements easier. Since WP7 and WP8 are in the same repo, does it make sense to have different subtasks for their taggings? If so, I'll add it to the template, if not, maybe I'll just change WP8 to say WP7+WP8? WDYT? Shaz - I see you're still checking in iOS7 fixes. Do you think you'll be able to tag iOS / OSX soon? Lorin - Same question for BB. Will you be able to write an update script for it (CB-4776) Steve - Likewise for FF I'd really like this tagging to be done tomorrow so that we can test out RC1 using RC1 of CLI. On Tue, Sep 17, 2013 at 10:00 PM, Jesse purplecabb...@gmail.com wrote: WP7, WP8, and Windows8 are all tagged 3.1.0-rc1 re: Changelog It is a little more difficult in these cases, and I n'er volunteered to do it, so whatevs - WP7+8 live in one repo, so their changes would need to be demuxed - all the changes for Windows8 have happened in the plugin repos, and cordova-js, so changelog would be empty Maybe I'll get this together for the 3.1.0, we'll see. @purplecabbage risingj.com On Tue, Sep 17, 2013 at 12:34 PM, Andrew Grieve agri...@chromium.org wrote: For the last plugin release, I tagged them with the plugin's version. (e.g. r0.2.1 for cordova-plugin-file). Only plugins that had changes were included in the release, so some may still not have any release tags. On Tue, Sep 17, 2013 at 3:31 PM, Braden Shepherdson bra...@chromium.org wrote: My understanding is that the plugins are totally independent of Cordova versions, and release on their own weekly-at-the-most-frequent cycle. They only depend on Cordova versions when they need a sufficiently new platform to support some feature (binary bridge, for example), and then they set engine tags appropriately. Braden On Tue, Sep 17, 2013 at 3:18 PM, Marcel Kinard cmarc...@gmail.com wrote: Will the plugin repos get tagged? If so, do they get tagged on every weekly cycle, or only when a cadence lines up with a weekly cycle, or both? I see that StepsForPluginRelease wiki say it will happen, and the most recent coho looks like it will do it, but I currently see only tags for 3.0.0 and 3.0.0rc1 in the plugins
Re: [Android] The state of WebSQL on Android 4.x
Although WebSQL is deprecated, it's what's currently available in mobile
browsers, so having it enables people to write apps that work on the web as
well as within a Cordova shell.
Let me paste my email code into actual Cordova and see if it works.
Having a plugin that provides a DB that works across all platforms would be
great as well.
On Thu, Sep 19, 2013 at 10:38 AM, Joe Bowser bows...@gmail.com wrote:
OK, here's a crazy concept that I'm going to throw out there.
How about we audit and recommend a third-party plugin and not do any
more work on this issue. I know that Android has a SQLite plugin that
works like WebSQL, but has a slightly different namespace. I haven't
recommended it because I don't feel comfortable doing that not knowing
how good it works. Then once we give our rubber stamp on that plugin,
we let our current solutions go on the ice flows to die.
What do people think of that idea? I'd rather not re-invent the wheel
if I don't have to.
On Thu, Sep 19, 2013 at 7:30 AM, Braden Shepherdson bra...@chromium.org
wrote:
The troubling part here is that WebSQL is broken (iOS7 introduced new
bugs,
too!) on iOS and Android, not supported on non-Webkit browsers, and crap.
But... IndexedDB is arguably more crap, though less buggy, but it isn't
supported on /anything/ mobile to my knowledge. This has been a crippling
problem when our chrome-apps-on-cordova team has been porting apps. If
some
app uses IndexedDB, we're out of luck.
There is a shim that uses WebSQL as a back-end for IndexedDB, intended
to be
used on these devices. But then it's still crap and buggy. I started
poking
at it to see if I could replace this with a shim of IndexedDB with a
Cordova
plugin (maybe File, more likely something specialized) as the backend.
That's probably possible, though it was complicated in a couple of
places by
the fact that some IDB/WebSQL calls are sync but all Cordova native calls
are async. Probably still possible to do that port, if we think it's
worthwhile. It would be a nontrivial project, though, and the IDB
interface
and performance still suck.
Braden
On Thu, Sep 19, 2013 at 8:08 AM, Brian LeRoux b...@brian.io wrote:
Deprecated.
On Sep 19, 2013 5:04 AM, Andrew Grieve agri...@chromium.org wrote:
If it's easy to support, then I think it's worth doing.
A custom scheme would work, but I think we can do it with a less
intrusive
change:
We came up with the following hack during our chrome-apps-on-cordova
work
for having CORS work when on a custom scheme. Should work for WebSQL
as
well though. It takes advantage of the fact that file:/// pages can
access
window objects of opened windows that are on different domains. It
goes
like:
The JS Code:
var win = window.open(websql://ftw);
// wait for window to load. Maybe via onload event? Or via polling?
win.onload = function() {
window.openDatabase = win.openDatabase;
}
// The Java code:
app.getSettings().setSupportMultipleWindows(true);
// In Chrome Client:
@SuppressWarnings(unused)
private WebView newWebView = null;
public boolean onCreateWindow (WebView view, boolean isDialog,
boolean
isUserGesture, Message resultMsg) {
WebView.WebViewTransport transport =
(WebView.WebViewTransport)
resultMsg.obj;
newWebView = new WebView(act);
newWebView.getSettings().setJavaScriptEnabled(true);
newWebView.setWebViewClient(new WebViewClient(){
@Override
public WebResourceResponse
shouldInterceptRequest(final
WebView view, String url) {
return a response that is just an empty page.
}
});
transport.setWebView(newWebView);
resultMsg.sendToTarget();
return true;
}
On Wed, Sep 18, 2013 at 7:43 PM, Jesse purplecabb...@gmail.com
wrote:
Windows Phone has never supported it. I have always felt that this
is
more
of a browser responsibility and didn't belong in the 'phonegap
features'
matrix. Just like we don't list querySelectorAll or SVG support.
Someone needs to write a JS shim that uses the File API which IS
available
on all the devices in cordova.
@purplecabbage
risingj.com
On Wed, Sep 18, 2013 at 2:31 PM, Joe Bowser bows...@gmail.com
wrote:
Ok, We've been ignoring this for quite a while, but it's not going
away:
There's still people who want to use WebSQL, and WebSQL is still
totally broken. Part of the reason it's broken is the fact that
Android prevents us from using the official WebSQL API on file
URIs,
and that we have a nasty collision with the official API on
Android.
So, what should we do?
1. Use a custom URI scheme?
2. Fix the JS so it aliases the existing WebSQL, and keep
Re: [Android] The state of WebSQL on Android 4.x
OK, here's a crazy concept that I'm going to throw out there.
How about we audit and recommend a third-party plugin and not do any
more work on this issue. I know that Android has a SQLite plugin that
works like WebSQL, but has a slightly different namespace. I haven't
recommended it because I don't feel comfortable doing that not knowing
how good it works. Then once we give our rubber stamp on that plugin,
we let our current solutions go on the ice flows to die.
What do people think of that idea? I'd rather not re-invent the wheel
if I don't have to.
On Thu, Sep 19, 2013 at 7:30 AM, Braden Shepherdson bra...@chromium.org wrote:
The troubling part here is that WebSQL is broken (iOS7 introduced new bugs,
too!) on iOS and Android, not supported on non-Webkit browsers, and crap.
But... IndexedDB is arguably more crap, though less buggy, but it isn't
supported on /anything/ mobile to my knowledge. This has been a crippling
problem when our chrome-apps-on-cordova team has been porting apps. If some
app uses IndexedDB, we're out of luck.
There is a shim that uses WebSQL as a back-end for IndexedDB, intended to be
used on these devices. But then it's still crap and buggy. I started poking
at it to see if I could replace this with a shim of IndexedDB with a Cordova
plugin (maybe File, more likely something specialized) as the backend.
That's probably possible, though it was complicated in a couple of places by
the fact that some IDB/WebSQL calls are sync but all Cordova native calls
are async. Probably still possible to do that port, if we think it's
worthwhile. It would be a nontrivial project, though, and the IDB interface
and performance still suck.
Braden
On Thu, Sep 19, 2013 at 8:08 AM, Brian LeRoux b...@brian.io wrote:
Deprecated.
On Sep 19, 2013 5:04 AM, Andrew Grieve agri...@chromium.org wrote:
If it's easy to support, then I think it's worth doing.
A custom scheme would work, but I think we can do it with a less
intrusive
change:
We came up with the following hack during our chrome-apps-on-cordova
work
for having CORS work when on a custom scheme. Should work for WebSQL as
well though. It takes advantage of the fact that file:/// pages can
access
window objects of opened windows that are on different domains. It goes
like:
The JS Code:
var win = window.open(websql://ftw);
// wait for window to load. Maybe via onload event? Or via polling?
win.onload = function() {
window.openDatabase = win.openDatabase;
}
// The Java code:
app.getSettings().setSupportMultipleWindows(true);
// In Chrome Client:
@SuppressWarnings(unused)
private WebView newWebView = null;
public boolean onCreateWindow (WebView view, boolean isDialog,
boolean
isUserGesture, Message resultMsg) {
WebView.WebViewTransport transport = (WebView.WebViewTransport)
resultMsg.obj;
newWebView = new WebView(act);
newWebView.getSettings().setJavaScriptEnabled(true);
newWebView.setWebViewClient(new WebViewClient(){
@Override
public WebResourceResponse shouldInterceptRequest(final
WebView view, String url) {
return a response that is just an empty page.
}
});
transport.setWebView(newWebView);
resultMsg.sendToTarget();
return true;
}
On Wed, Sep 18, 2013 at 7:43 PM, Jesse purplecabb...@gmail.com wrote:
Windows Phone has never supported it. I have always felt that this is
more
of a browser responsibility and didn't belong in the 'phonegap
features'
matrix. Just like we don't list querySelectorAll or SVG support.
Someone needs to write a JS shim that uses the File API which IS
available
on all the devices in cordova.
@purplecabbage
risingj.com
On Wed, Sep 18, 2013 at 2:31 PM, Joe Bowser bows...@gmail.com wrote:
Ok, We've been ignoring this for quite a while, but it's not going
away:
There's still people who want to use WebSQL, and WebSQL is still
totally broken. Part of the reason it's broken is the fact that
Android prevents us from using the official WebSQL API on file URIs,
and that we have a nasty collision with the official API on Android.
So, what should we do?
1. Use a custom URI scheme?
2. Fix the JS so it aliases the existing WebSQL, and keep using our
own WebSQL plugin.
3. Just say it's deprecated and leave it at that?
If we say we're tossing WebSQL by the wayside, what do we support
instead? Seriously, what do people think of this, because I'm not
sure what we should do here.
Joe
Re: [Android] The state of WebSQL on Android 4.x
+1 to not reinventing the wheel and sanctioning external contributions if
they are available, Joe.
Having said that, personally I'd prefer to see an IndexedDB-like-thing
instead of a WebSQL-like-thing since thats the direction all desktop
browsers have gone, and maps better to web developer
expectations/abilities. Also, there is hope that one day mobile webviews
will support IndexedDB and we can remove our polyfills, and the reverse is
not true, so I think an IDB polyfill aligns better with cordova goals.
-Michal
On Thu, Sep 19, 2013 at 7:38 AM, Joe Bowser bows...@gmail.com wrote:
OK, here's a crazy concept that I'm going to throw out there.
How about we audit and recommend a third-party plugin and not do any
more work on this issue. I know that Android has a SQLite plugin that
works like WebSQL, but has a slightly different namespace. I haven't
recommended it because I don't feel comfortable doing that not knowing
how good it works. Then once we give our rubber stamp on that plugin,
we let our current solutions go on the ice flows to die.
What do people think of that idea? I'd rather not re-invent the wheel
if I don't have to.
On Thu, Sep 19, 2013 at 7:30 AM, Braden Shepherdson bra...@chromium.org
wrote:
The troubling part here is that WebSQL is broken (iOS7 introduced new
bugs,
too!) on iOS and Android, not supported on non-Webkit browsers, and crap.
But... IndexedDB is arguably more crap, though less buggy, but it isn't
supported on /anything/ mobile to my knowledge. This has been a crippling
problem when our chrome-apps-on-cordova team has been porting apps. If
some
app uses IndexedDB, we're out of luck.
There is a shim that uses WebSQL as a back-end for IndexedDB, intended
to be
used on these devices. But then it's still crap and buggy. I started
poking
at it to see if I could replace this with a shim of IndexedDB with a
Cordova
plugin (maybe File, more likely something specialized) as the backend.
That's probably possible, though it was complicated in a couple of
places by
the fact that some IDB/WebSQL calls are sync but all Cordova native calls
are async. Probably still possible to do that port, if we think it's
worthwhile. It would be a nontrivial project, though, and the IDB
interface
and performance still suck.
Braden
On Thu, Sep 19, 2013 at 8:08 AM, Brian LeRoux b...@brian.io wrote:
Deprecated.
On Sep 19, 2013 5:04 AM, Andrew Grieve agri...@chromium.org wrote:
If it's easy to support, then I think it's worth doing.
A custom scheme would work, but I think we can do it with a less
intrusive
change:
We came up with the following hack during our chrome-apps-on-cordova
work
for having CORS work when on a custom scheme. Should work for WebSQL
as
well though. It takes advantage of the fact that file:/// pages can
access
window objects of opened windows that are on different domains. It
goes
like:
The JS Code:
var win = window.open(websql://ftw);
// wait for window to load. Maybe via onload event? Or via polling?
win.onload = function() {
window.openDatabase = win.openDatabase;
}
// The Java code:
app.getSettings().setSupportMultipleWindows(true);
// In Chrome Client:
@SuppressWarnings(unused)
private WebView newWebView = null;
public boolean onCreateWindow (WebView view, boolean isDialog,
boolean
isUserGesture, Message resultMsg) {
WebView.WebViewTransport transport =
(WebView.WebViewTransport)
resultMsg.obj;
newWebView = new WebView(act);
newWebView.getSettings().setJavaScriptEnabled(true);
newWebView.setWebViewClient(new WebViewClient(){
@Override
public WebResourceResponse
shouldInterceptRequest(final
WebView view, String url) {
return a response that is just an empty page.
}
});
transport.setWebView(newWebView);
resultMsg.sendToTarget();
return true;
}
On Wed, Sep 18, 2013 at 7:43 PM, Jesse purplecabb...@gmail.com
wrote:
Windows Phone has never supported it. I have always felt that this
is
more
of a browser responsibility and didn't belong in the 'phonegap
features'
matrix. Just like we don't list querySelectorAll or SVG support.
Someone needs to write a JS shim that uses the File API which IS
available
on all the devices in cordova.
@purplecabbage
risingj.com
On Wed, Sep 18, 2013 at 2:31 PM, Joe Bowser bows...@gmail.com
wrote:
Ok, We've been ignoring this for quite a while, but it's not going
away:
There's still people who want to use WebSQL, and WebSQL is still
totally broken. Part of the reason it's broken is the fact that
Android prevents us from using the official WebSQL API on file
URIs,
and that we have a
Re: [Android] The state of WebSQL on Android 4.x
Thats fine by me. We should not care if the w3c and browsers are moving in
a different direction anyhow.
On Thu, Sep 19, 2013 at 4:38 PM, Joe Bowser bows...@gmail.com wrote:
OK, here's a crazy concept that I'm going to throw out there.
How about we audit and recommend a third-party plugin and not do any
more work on this issue. I know that Android has a SQLite plugin that
works like WebSQL, but has a slightly different namespace. I haven't
recommended it because I don't feel comfortable doing that not knowing
how good it works. Then once we give our rubber stamp on that plugin,
we let our current solutions go on the ice flows to die.
What do people think of that idea? I'd rather not re-invent the wheel
if I don't have to.
On Thu, Sep 19, 2013 at 7:30 AM, Braden Shepherdson bra...@chromium.org
wrote:
The troubling part here is that WebSQL is broken (iOS7 introduced new
bugs,
too!) on iOS and Android, not supported on non-Webkit browsers, and crap.
But... IndexedDB is arguably more crap, though less buggy, but it isn't
supported on /anything/ mobile to my knowledge. This has been a crippling
problem when our chrome-apps-on-cordova team has been porting apps. If
some
app uses IndexedDB, we're out of luck.
There is a shim that uses WebSQL as a back-end for IndexedDB, intended
to be
used on these devices. But then it's still crap and buggy. I started
poking
at it to see if I could replace this with a shim of IndexedDB with a
Cordova
plugin (maybe File, more likely something specialized) as the backend.
That's probably possible, though it was complicated in a couple of
places by
the fact that some IDB/WebSQL calls are sync but all Cordova native calls
are async. Probably still possible to do that port, if we think it's
worthwhile. It would be a nontrivial project, though, and the IDB
interface
and performance still suck.
Braden
On Thu, Sep 19, 2013 at 8:08 AM, Brian LeRoux b...@brian.io wrote:
Deprecated.
On Sep 19, 2013 5:04 AM, Andrew Grieve agri...@chromium.org wrote:
If it's easy to support, then I think it's worth doing.
A custom scheme would work, but I think we can do it with a less
intrusive
change:
We came up with the following hack during our chrome-apps-on-cordova
work
for having CORS work when on a custom scheme. Should work for WebSQL
as
well though. It takes advantage of the fact that file:/// pages can
access
window objects of opened windows that are on different domains. It
goes
like:
The JS Code:
var win = window.open(websql://ftw);
// wait for window to load. Maybe via onload event? Or via polling?
win.onload = function() {
window.openDatabase = win.openDatabase;
}
// The Java code:
app.getSettings().setSupportMultipleWindows(true);
// In Chrome Client:
@SuppressWarnings(unused)
private WebView newWebView = null;
public boolean onCreateWindow (WebView view, boolean isDialog,
boolean
isUserGesture, Message resultMsg) {
WebView.WebViewTransport transport =
(WebView.WebViewTransport)
resultMsg.obj;
newWebView = new WebView(act);
newWebView.getSettings().setJavaScriptEnabled(true);
newWebView.setWebViewClient(new WebViewClient(){
@Override
public WebResourceResponse
shouldInterceptRequest(final
WebView view, String url) {
return a response that is just an empty page.
}
});
transport.setWebView(newWebView);
resultMsg.sendToTarget();
return true;
}
On Wed, Sep 18, 2013 at 7:43 PM, Jesse purplecabb...@gmail.com
wrote:
Windows Phone has never supported it. I have always felt that this
is
more
of a browser responsibility and didn't belong in the 'phonegap
features'
matrix. Just like we don't list querySelectorAll or SVG support.
Someone needs to write a JS shim that uses the File API which IS
available
on all the devices in cordova.
@purplecabbage
risingj.com
On Wed, Sep 18, 2013 at 2:31 PM, Joe Bowser bows...@gmail.com
wrote:
Ok, We've been ignoring this for quite a while, but it's not going
away:
There's still people who want to use WebSQL, and WebSQL is still
totally broken. Part of the reason it's broken is the fact that
Android prevents us from using the official WebSQL API on file
URIs,
and that we have a nasty collision with the official API on
Android.
So, what should we do?
1. Use a custom URI scheme?
2. Fix the JS so it aliases the existing WebSQL, and keep using
our
own WebSQL plugin.
3. Just say it's deprecated and leave it at that?
If we say we're tossing WebSQL by the wayside, what do we support
instead? Seriously, what do people think of this, because I'm not
Re: 3.1 Release
I think its this one: http://wiki.apache.org/cordova/CuttingReleases On Thu, Sep 19, 2013 at 7:52 AM, Jeffrey Heifetz jheif...@blackberry.comwrote: I can take the responsibility of tagging BlackBerry. Could you send me the wiki with instructions ? From: Andrew Grieve agri...@chromium.orgmailto:agri...@chromium.org Date: Thursday, 19 September, 2013 10:40 AM To: dev dev@cordova.apache.orgmailto:dev@cordova.apache.org, Jeffrey Heifetz jheif...@blackberry.commailto:jheif...@blackberry.com Subject: Re: 3.1 Release +Jeffrey - maybe you could take on the BlackBerry component for this release? On Thu, Sep 19, 2013 at 10:00 AM, Michael Brooks mich...@michaelbrooks.ca mailto:mich...@michaelbrooks.ca wrote: Once the platforms are tagged, I can handle the docs. I'll need to review our release process and see how the docs can best abide by them. On Wed, Sep 18, 2013 at 1:34 PM, Andrew Grieve agri...@chromium.org mailto:agri...@chromium.org wrote: Shaz - Thanks for the update :). If iOS is the last one then I'd say let's go without, but maybe keep at it until we get BB tagged? (just my opinion) Heading home now - anyone know if Lorin is away or not? On Wed, Sep 18, 2013 at 3:35 PM, Shazron shaz...@gmail.commailto: shaz...@gmail.com wrote: When i mean ios-deploy still works, it _installs_ it on the device, but does _not_ run it. On Wed, Sep 18, 2013 at 12:31 PM, Shazron shaz...@gmail.commailto: shaz...@gmail.com wrote: I'm 99% done with iOS specific fixes. One last one I'm trying to do is ios-deploy with lldb: https://issues.apache.org/jira/browse/CB-4804 This means if I don't get this fix in, we _can_ deploy from the command line using ios-deploy _but_ we can't attach to the debugger. Will that be acceptable you think? On Wed, Sep 18, 2013 at 12:07 PM, Andrew Grieve agri...@chromium.org mailto:agri...@chromium.org wrote: Ping Lorin Shaz. On Wed, Sep 18, 2013 at 2:19 AM, Steven Gill stevengil...@gmail.com mailto:stevengil...@gmail.com wrote: FFOS will be tagged tomorrow. I have a few changes I am going to get in tomorrow before tagging but it will be good to go very soon! With FFOS, Only two plugins have been ported so far (vibration and device). We are going to continue to add firefoxos support to plugins post release. I don't think we should start officially promoting support for FFOS until we have more plugins. For 3.1, it will be available for users to try out, test, give feedback, etc. Cheers, -Steve On Tue, Sep 17, 2013 at 7:38 PM, Andrew Grieve agri...@chromium.orgmailto:agri...@chromium.org wrote: Thanks Jesse! Great work on being on top of things. If changes were done in plugin repos, then those aren't a part of this release anyways and will be picked up by the RELEASENOTES.md within the plugin repos on the next plugins release. I think it's up to you if you want to start writing RELEASENOTES.md for WP7+8. My thinking was just that doing so would make release announcements easier. Since WP7 and WP8 are in the same repo, does it make sense to have different subtasks for their taggings? If so, I'll add it to the template, if not, maybe I'll just change WP8 to say WP7+WP8? WDYT? Shaz - I see you're still checking in iOS7 fixes. Do you think you'll be able to tag iOS / OSX soon? Lorin - Same question for BB. Will you be able to write an update script for it (CB-4776) Steve - Likewise for FF I'd really like this tagging to be done tomorrow so that we can test out RC1 using RC1 of CLI. On Tue, Sep 17, 2013 at 10:00 PM, Jesse purplecabb...@gmail.com mailto:purplecabb...@gmail.com wrote: WP7, WP8, and Windows8 are all tagged 3.1.0-rc1 re: Changelog It is a little more difficult in these cases, and I n'er volunteered to do it, so whatevs - WP7+8 live in one repo, so their changes would need to be demuxed - all the changes for Windows8 have happened in the plugin repos, and cordova-js, so changelog would be empty Maybe I'll get this together for the 3.1.0, we'll see. @purplecabbage risingj.comhttp://risingj.com On Tue, Sep 17, 2013 at 12:34 PM, Andrew Grieve agri...@chromium.orgmailto:agri...@chromium.org wrote: For the last plugin release, I tagged them with the plugin's version. (e.g. r0.2.1 for cordova-plugin-file). Only plugins that had changes were included in the release, so some may still not have any release tags. On Tue, Sep 17, 2013 at 3:31 PM, Braden Shepherdson bra...@chromium.orgmailto:bra...@chromium.org wrote: My understanding is that the plugins are totally independent of Cordova
Re: 3.1 Release
Specifically, I think the section Branch Tag RC1 for Platform Repositories On Thu, Sep 19, 2013 at 7:59 AM, Michal Mocny mmo...@chromium.org wrote: I think its this one: http://wiki.apache.org/cordova/CuttingReleases On Thu, Sep 19, 2013 at 7:52 AM, Jeffrey Heifetz jheif...@blackberry.comwrote: I can take the responsibility of tagging BlackBerry. Could you send me the wiki with instructions ? From: Andrew Grieve agri...@chromium.orgmailto:agri...@chromium.org Date: Thursday, 19 September, 2013 10:40 AM To: dev dev@cordova.apache.orgmailto:dev@cordova.apache.org, Jeffrey Heifetz jheif...@blackberry.commailto:jheif...@blackberry.com Subject: Re: 3.1 Release +Jeffrey - maybe you could take on the BlackBerry component for this release? On Thu, Sep 19, 2013 at 10:00 AM, Michael Brooks mich...@michaelbrooks.camailto:mich...@michaelbrooks.ca wrote: Once the platforms are tagged, I can handle the docs. I'll need to review our release process and see how the docs can best abide by them. On Wed, Sep 18, 2013 at 1:34 PM, Andrew Grieve agri...@chromium.org mailto:agri...@chromium.org wrote: Shaz - Thanks for the update :). If iOS is the last one then I'd say let's go without, but maybe keep at it until we get BB tagged? (just my opinion) Heading home now - anyone know if Lorin is away or not? On Wed, Sep 18, 2013 at 3:35 PM, Shazron shaz...@gmail.commailto: shaz...@gmail.com wrote: When i mean ios-deploy still works, it _installs_ it on the device, but does _not_ run it. On Wed, Sep 18, 2013 at 12:31 PM, Shazron shaz...@gmail.commailto: shaz...@gmail.com wrote: I'm 99% done with iOS specific fixes. One last one I'm trying to do is ios-deploy with lldb: https://issues.apache.org/jira/browse/CB-4804 This means if I don't get this fix in, we _can_ deploy from the command line using ios-deploy _but_ we can't attach to the debugger. Will that be acceptable you think? On Wed, Sep 18, 2013 at 12:07 PM, Andrew Grieve agri...@chromium.orgmailto:agri...@chromium.org wrote: Ping Lorin Shaz. On Wed, Sep 18, 2013 at 2:19 AM, Steven Gill stevengil...@gmail.commailto:stevengil...@gmail.com wrote: FFOS will be tagged tomorrow. I have a few changes I am going to get in tomorrow before tagging but it will be good to go very soon! With FFOS, Only two plugins have been ported so far (vibration and device). We are going to continue to add firefoxos support to plugins post release. I don't think we should start officially promoting support for FFOS until we have more plugins. For 3.1, it will be available for users to try out, test, give feedback, etc. Cheers, -Steve On Tue, Sep 17, 2013 at 7:38 PM, Andrew Grieve agri...@chromium.orgmailto:agri...@chromium.org wrote: Thanks Jesse! Great work on being on top of things. If changes were done in plugin repos, then those aren't a part of this release anyways and will be picked up by the RELEASENOTES.md within the plugin repos on the next plugins release. I think it's up to you if you want to start writing RELEASENOTES.md for WP7+8. My thinking was just that doing so would make release announcements easier. Since WP7 and WP8 are in the same repo, does it make sense to have different subtasks for their taggings? If so, I'll add it to the template, if not, maybe I'll just change WP8 to say WP7+WP8? WDYT? Shaz - I see you're still checking in iOS7 fixes. Do you think you'll be able to tag iOS / OSX soon? Lorin - Same question for BB. Will you be able to write an update script for it (CB-4776) Steve - Likewise for FF I'd really like this tagging to be done tomorrow so that we can test out RC1 using RC1 of CLI. On Tue, Sep 17, 2013 at 10:00 PM, Jesse purplecabb...@gmail.com mailto:purplecabb...@gmail.com wrote: WP7, WP8, and Windows8 are all tagged 3.1.0-rc1 re: Changelog It is a little more difficult in these cases, and I n'er volunteered to do it, so whatevs - WP7+8 live in one repo, so their changes would need to be demuxed - all the changes for Windows8 have happened in the plugin repos, and cordova-js, so changelog would be empty Maybe I'll get this together for the 3.1.0, we'll see. @purplecabbage risingj.comhttp://risingj.com On Tue, Sep 17, 2013 at 12:34 PM, Andrew Grieve agri...@chromium.orgmailto:agri...@chromium.org wrote: For the last plugin release, I tagged them with the plugin's version. (e.g. r0.2.1 for cordova-plugin-file). Only plugins that had changes were included in the release, so some may still not have any release tags. On Tue, Sep 17, 2013 at 3:31 PM, Braden Shepherdson
Re: Proposal: Change JIRA to have bugs as unassigned by default
12 hours? I think we have to wait longer before moving on a proposal. Sent from my iPhone On Sep 19, 2013, at 7:29 AM, Andrew Grieve agri...@chromium.org wrote: Okay, I've made the change. Let's try it out :) I think start/stop is good if you've actually started working on something, but it's different from this new bug has been looked at by someone. On Thu, Sep 19, 2013 at 2:51 AM, Anis KADRI anis.ka...@gmail.com wrote: What about the start/stop progress? On Wed, Sep 18, 2013 at 9:03 PM, Ian Clelland iclell...@chromium.org wrote: +1 Also, if you are a component owner, it's pretty simple in JIRA to add a dashboard widget that shows you all unassigned bugs in your component. Ian On Wed, Sep 18, 2013 at 11:49 PM, Joe Bowser bows...@gmail.com wrote: +1
Re: [Android] The state of WebSQL on Android 4.x
OK, how about we do this: 1. We indicate that we no longer support WebSQL on the docs and we list out why we don't support it as it currently exists 2. I'll look at the Android plugin that does do SQLite and see if it's appropriate for Android (if someone could do the same for iOS, that'd be cool): https://github.com/lite4mobi/Cordova-SQLitePlugin I think this looks far more promising than any of the hokey bullshit that we're currently doing, and it has contributors, and it's actually updated for Cordova 3.0. On Thu, Sep 19, 2013 at 7:53 AM, Ian Clelland iclell...@chromium.org wrote: On Thu, Sep 19, 2013 at 10:38 AM, Joe Bowser bows...@gmail.com wrote: OK, here's a crazy concept that I'm going to throw out there. How about we audit and recommend a third-party plugin and not do any more work on this issue. +1 I don't think there's enough consensus about whether WebSQL even belongs in the web platform for us to be insisting that it be part of Cordova. I would much rather see someone with a real interest in WebSQL be providing that functionality. Our job can be to make sure that we aren't getting in the way; that we are helping make plugins like that possible. Ian
Re: [Android] The state of WebSQL on Android 4.x
wp8 and windows8 support indexed db. Bb10 has partial support.
Sent from my iPhone
On Sep 19, 2013, at 7:30 AM, Braden Shepherdson bra...@chromium.org wrote:
The troubling part here is that WebSQL is broken (iOS7 introduced new bugs,
too!) on iOS and Android, not supported on non-Webkit browsers, and crap.
But... IndexedDB is arguably more crap, though less buggy, but it isn't
supported on /anything/ mobile to my knowledge. This has been a crippling
problem when our chrome-apps-on-cordova team has been porting apps. If some
app uses IndexedDB, we're out of luck.
There is a shim that uses WebSQL as a back-end for IndexedDB, intended to
be used on these devices. But then it's still crap and buggy. I started
poking at it to see if I could replace this with a shim of IndexedDB with a
Cordova plugin (maybe File, more likely something specialized) as the
backend. That's probably possible, though it was complicated in a couple of
places by the fact that some IDB/WebSQL calls are sync but all Cordova
native calls are async. Probably still possible to do that port, if we
think it's worthwhile. It would be a nontrivial project, though, and the
IDB interface and performance still suck.
Braden
On Thu, Sep 19, 2013 at 8:08 AM, Brian LeRoux b...@brian.io wrote:
Deprecated.
On Sep 19, 2013 5:04 AM, Andrew Grieve agri...@chromium.org wrote:
If it's easy to support, then I think it's worth doing.
A custom scheme would work, but I think we can do it with a less
intrusive
change:
We came up with the following hack during our chrome-apps-on-cordova work
for having CORS work when on a custom scheme. Should work for WebSQL as
well though. It takes advantage of the fact that file:/// pages can
access
window objects of opened windows that are on different domains. It goes
like:
The JS Code:
var win = window.open(websql://ftw);
// wait for window to load. Maybe via onload event? Or via polling?
win.onload = function() {
window.openDatabase = win.openDatabase;
}
// The Java code:
app.getSettings().setSupportMultipleWindows(true);
// In Chrome Client:
@SuppressWarnings(unused)
private WebView newWebView = null;
public boolean onCreateWindow (WebView view, boolean isDialog,
boolean
isUserGesture, Message resultMsg) {
WebView.WebViewTransport transport = (WebView.WebViewTransport)
resultMsg.obj;
newWebView = new WebView(act);
newWebView.getSettings().setJavaScriptEnabled(true);
newWebView.setWebViewClient(new WebViewClient(){
@Override
public WebResourceResponse shouldInterceptRequest(final
WebView view, String url) {
return a response that is just an empty page.
}
});
transport.setWebView(newWebView);
resultMsg.sendToTarget();
return true;
}
On Wed, Sep 18, 2013 at 7:43 PM, Jesse purplecabb...@gmail.com wrote:
Windows Phone has never supported it. I have always felt that this is
more
of a browser responsibility and didn't belong in the 'phonegap
features'
matrix. Just like we don't list querySelectorAll or SVG support.
Someone needs to write a JS shim that uses the File API which IS
available
on all the devices in cordova.
@purplecabbage
risingj.com
On Wed, Sep 18, 2013 at 2:31 PM, Joe Bowser bows...@gmail.com wrote:
Ok, We've been ignoring this for quite a while, but it's not going
away:
There's still people who want to use WebSQL, and WebSQL is still
totally broken. Part of the reason it's broken is the fact that
Android prevents us from using the official WebSQL API on file URIs,
and that we have a nasty collision with the official API on Android.
So, what should we do?
1. Use a custom URI scheme?
2. Fix the JS so it aliases the existing WebSQL, and keep using our
own WebSQL plugin.
3. Just say it's deprecated and leave it at that?
If we say we're tossing WebSQL by the wayside, what do we support
instead? Seriously, what do people think of this, because I'm not
sure what we should do here.
Joe
RE: [Android] The state of WebSQL on Android 4.x
I wrote a IndexedDB Shim that works on WebSQL and I am aware that there are
some bugs I need to fix. I am also in the process of converting the IndexedDB
shim into a Cordova plugin. However, with iOS7, the size of IndexedDB is still
smaller (5MB). Any help with fixing the plugin bugs would be appreciated.
Alternatively, Windows Phone does support SQLite and we could simply carve out
a SQLite plugin that has a webSQL like API across platforms.
-Original Message-
From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny
Sent: Thursday, September 19, 2013 7:49 AM
To: dev; bows...@apache.org
Cc: Braden Shepherdson
Subject: Re: [Android] The state of WebSQL on Android 4.x
+1 to not reinventing the wheel and sanctioning external contributions
+if
they are available, Joe.
Having said that, personally I'd prefer to see an IndexedDB-like-thing instead
of a WebSQL-like-thing since thats the direction all desktop browsers have
gone, and maps better to web developer expectations/abilities. Also, there is
hope that one day mobile webviews will support IndexedDB and we can remove our
polyfills, and the reverse is not true, so I think an IDB polyfill aligns
better with cordova goals.
-Michal
On Thu, Sep 19, 2013 at 7:38 AM, Joe Bowser bows...@gmail.com wrote:
OK, here's a crazy concept that I'm going to throw out there.
How about we audit and recommend a third-party plugin and not do any
more work on this issue. I know that Android has a SQLite plugin that
works like WebSQL, but has a slightly different namespace. I haven't
recommended it because I don't feel comfortable doing that not knowing
how good it works. Then once we give our rubber stamp on that plugin,
we let our current solutions go on the ice flows to die.
What do people think of that idea? I'd rather not re-invent the wheel
if I don't have to.
On Thu, Sep 19, 2013 at 7:30 AM, Braden Shepherdson
bra...@chromium.org
wrote:
The troubling part here is that WebSQL is broken (iOS7 introduced
new
bugs,
too!) on iOS and Android, not supported on non-Webkit browsers, and crap.
But... IndexedDB is arguably more crap, though less buggy, but it
isn't supported on /anything/ mobile to my knowledge. This has been
a crippling problem when our chrome-apps-on-cordova team has been
porting apps. If
some
app uses IndexedDB, we're out of luck.
There is a shim that uses WebSQL as a back-end for IndexedDB,
intended
to be
used on these devices. But then it's still crap and buggy. I started
poking
at it to see if I could replace this with a shim of IndexedDB with a
Cordova
plugin (maybe File, more likely something specialized) as the backend.
That's probably possible, though it was complicated in a couple of
places by
the fact that some IDB/WebSQL calls are sync but all Cordova native
calls are async. Probably still possible to do that port, if we
think it's worthwhile. It would be a nontrivial project, though, and
the IDB
interface
and performance still suck.
Braden
On Thu, Sep 19, 2013 at 8:08 AM, Brian LeRoux b...@brian.io wrote:
Deprecated.
On Sep 19, 2013 5:04 AM, Andrew Grieve agri...@chromium.org wrote:
If it's easy to support, then I think it's worth doing.
A custom scheme would work, but I think we can do it with a less
intrusive
change:
We came up with the following hack during our
chrome-apps-on-cordova work for having CORS work when on a custom
scheme. Should work for WebSQL
as
well though. It takes advantage of the fact that file:/// pages
can access window objects of opened windows that are on different
domains. It
goes
like:
The JS Code:
var win = window.open(websql://ftw); // wait for window to
load. Maybe via onload event? Or via polling?
win.onload = function() {
window.openDatabase = win.openDatabase; }
// The Java code:
app.getSettings().setSupportMultipleWindows(true);
// In Chrome Client:
@SuppressWarnings(unused)
private WebView newWebView = null;
public boolean onCreateWindow (WebView view, boolean
isDialog, boolean isUserGesture, Message resultMsg) {
WebView.WebViewTransport transport =
(WebView.WebViewTransport)
resultMsg.obj;
newWebView = new WebView(act);
newWebView.getSettings().setJavaScriptEnabled(true);
newWebView.setWebViewClient(new WebViewClient(){
@Override
public WebResourceResponse
shouldInterceptRequest(final
WebView view, String url) {
return a response that is just an empty page.
}
});
transport.setWebView(newWebView);
resultMsg.sendToTarget();
return true;
}
On Wed, Sep 18, 2013 at 7:43 PM, Jesse purplecabb...@gmail.com
wrote:
Windows Phone has never supported it. I have always felt
Re: [Android] The state of WebSQL on Android 4.x
yup. On Thu, Sep 19, 2013 at 5:42 PM, Joe Bowser bows...@gmail.com wrote: OK, how about we do this: 1. We indicate that we no longer support WebSQL on the docs and we list out why we don't support it as it currently exists 2. I'll look at the Android plugin that does do SQLite and see if it's appropriate for Android (if someone could do the same for iOS, that'd be cool): https://github.com/lite4mobi/Cordova-SQLitePlugin I think this looks far more promising than any of the hokey bullshit that we're currently doing, and it has contributors, and it's actually updated for Cordova 3.0. On Thu, Sep 19, 2013 at 7:53 AM, Ian Clelland iclell...@chromium.org wrote: On Thu, Sep 19, 2013 at 10:38 AM, Joe Bowser bows...@gmail.com wrote: OK, here's a crazy concept that I'm going to throw out there. How about we audit and recommend a third-party plugin and not do any more work on this issue. +1 I don't think there's enough consensus about whether WebSQL even belongs in the web platform for us to be insisting that it be part of Cordova. I would much rather see someone with a real interest in WebSQL be providing that functionality. Our job can be to make sure that we aren't getting in the way; that we are helping make plugins like that possible. Ian
Re: 3.1 Release
I can take the responsibility of tagging BlackBerry. Could you send me the wiki with instructions ? From: Andrew Grieve agri...@chromium.orgmailto:agri...@chromium.org Date: Thursday, 19 September, 2013 10:40 AM To: dev dev@cordova.apache.orgmailto:dev@cordova.apache.org, Jeffrey Heifetz jheif...@blackberry.commailto:jheif...@blackberry.com Subject: Re: 3.1 Release +Jeffrey - maybe you could take on the BlackBerry component for this release? On Thu, Sep 19, 2013 at 10:00 AM, Michael Brooks mich...@michaelbrooks.camailto:mich...@michaelbrooks.ca wrote: Once the platforms are tagged, I can handle the docs. I'll need to review our release process and see how the docs can best abide by them. On Wed, Sep 18, 2013 at 1:34 PM, Andrew Grieve agri...@chromium.orgmailto:agri...@chromium.org wrote: Shaz - Thanks for the update :). If iOS is the last one then I'd say let's go without, but maybe keep at it until we get BB tagged? (just my opinion) Heading home now - anyone know if Lorin is away or not? On Wed, Sep 18, 2013 at 3:35 PM, Shazron shaz...@gmail.commailto:shaz...@gmail.com wrote: When i mean ios-deploy still works, it _installs_ it on the device, but does _not_ run it. On Wed, Sep 18, 2013 at 12:31 PM, Shazron shaz...@gmail.commailto:shaz...@gmail.com wrote: I'm 99% done with iOS specific fixes. One last one I'm trying to do is ios-deploy with lldb: https://issues.apache.org/jira/browse/CB-4804 This means if I don't get this fix in, we _can_ deploy from the command line using ios-deploy _but_ we can't attach to the debugger. Will that be acceptable you think? On Wed, Sep 18, 2013 at 12:07 PM, Andrew Grieve agri...@chromium.orgmailto:agri...@chromium.org wrote: Ping Lorin Shaz. On Wed, Sep 18, 2013 at 2:19 AM, Steven Gill stevengil...@gmail.commailto:stevengil...@gmail.com wrote: FFOS will be tagged tomorrow. I have a few changes I am going to get in tomorrow before tagging but it will be good to go very soon! With FFOS, Only two plugins have been ported so far (vibration and device). We are going to continue to add firefoxos support to plugins post release. I don't think we should start officially promoting support for FFOS until we have more plugins. For 3.1, it will be available for users to try out, test, give feedback, etc. Cheers, -Steve On Tue, Sep 17, 2013 at 7:38 PM, Andrew Grieve agri...@chromium.orgmailto:agri...@chromium.org wrote: Thanks Jesse! Great work on being on top of things. If changes were done in plugin repos, then those aren't a part of this release anyways and will be picked up by the RELEASENOTES.md within the plugin repos on the next plugins release. I think it's up to you if you want to start writing RELEASENOTES.md for WP7+8. My thinking was just that doing so would make release announcements easier. Since WP7 and WP8 are in the same repo, does it make sense to have different subtasks for their taggings? If so, I'll add it to the template, if not, maybe I'll just change WP8 to say WP7+WP8? WDYT? Shaz - I see you're still checking in iOS7 fixes. Do you think you'll be able to tag iOS / OSX soon? Lorin - Same question for BB. Will you be able to write an update script for it (CB-4776) Steve - Likewise for FF I'd really like this tagging to be done tomorrow so that we can test out RC1 using RC1 of CLI. On Tue, Sep 17, 2013 at 10:00 PM, Jesse purplecabb...@gmail.commailto:purplecabb...@gmail.com wrote: WP7, WP8, and Windows8 are all tagged 3.1.0-rc1 re: Changelog It is a little more difficult in these cases, and I n'er volunteered to do it, so whatevs - WP7+8 live in one repo, so their changes would need to be demuxed - all the changes for Windows8 have happened in the plugin repos, and cordova-js, so changelog would be empty Maybe I'll get this together for the 3.1.0, we'll see. @purplecabbage risingj.comhttp://risingj.com On Tue, Sep 17, 2013 at 12:34 PM, Andrew Grieve agri...@chromium.orgmailto:agri...@chromium.org wrote: For the last plugin release, I tagged them with the plugin's version. (e.g. r0.2.1 for cordova-plugin-file). Only plugins that had changes were included in the release, so some may still not have any release tags. On Tue, Sep 17, 2013 at 3:31 PM, Braden Shepherdson bra...@chromium.orgmailto:bra...@chromium.org wrote: My understanding is that the plugins are totally independent of Cordova versions, and release on their own weekly-at-the-most-frequent cycle. They only depend on Cordova versions when they need a sufficiently new platform to support some feature (binary bridge, for example), and then they set engine tags appropriately. Braden
Re: [Android] The state of WebSQL on Android 4.x
On Thu, Sep 19, 2013 at 10:38 AM, Joe Bowser bows...@gmail.com wrote: OK, here's a crazy concept that I'm going to throw out there. How about we audit and recommend a third-party plugin and not do any more work on this issue. +1 I don't think there's enough consensus about whether WebSQL even belongs in the web platform for us to be insisting that it be part of Cordova. I would much rather see someone with a real interest in WebSQL be providing that functionality. Our job can be to make sure that we aren't getting in the way; that we are helping make plugins like that possible. Ian
Re: Proposal: Change JIRA to have bugs as unassigned by default
This sounds like a solution to workflow issue. But what is our workflow? So if I understand correctly, the proposal is that a new bug that is unassigned means it has not been triaged. What would Jira state be for the following: - triaged and nobody plans to work on it yet (low priority) - triaged and person X plans to work on it, but they haven't started yet (person X's to do list) - triaged and person X plans to work on it, and they have started (in progress) And do these states need to be captured in Jira or is that overkill? Is it expected that the component owner does all the triage-ing? On Sep 18, 2013, at 11:00 PM, Andrew Grieve agri...@chromium.org wrote: Motivation: It's impossible to know whether new bugs have been looked at by the default assignee. Rationale: Setting it to unassigned, means new bugs will be obviously untriaged. Once assigned, it will mean someone intends to work on it. This won't eliminate bugs that get assigned and then not fixed in a timely fashion. I think that's okay though. It'll be an improvement anyways.
Re: Proposal: Change JIRA to have bugs as unassigned by default
apology already posted, but I'll reiterate that 12 hours for a process change that affects all assignees is way to short, especially on a project with contributors across the globe. On Thu, Sep 19, 2013 at 9:29 AM, Andrew Grieve agri...@chromium.org wrote: Sorry for jumping the gun - figured this would be an easy thing the change back if people started -1ing. Also don't think we necessarily need all components to work the same. I'm specifically only interested in the components that I do triage on: Android, iOS, Mobile Spec, JS, Plugins. Jesse - What's your rationale for wanting it to stay the way it was before? (I've changed the windows ones back) Joe - I also spend a lot of time triaging bugs as they come in. I've been doing it for many months now. I think it's fine for anyone to triage, because often the best person to do so changes depending on the bug. I actually think having an explicit triage step will make our project seem more alive, since people will see action taken on their bugs (adding an assignee). Marcel - I like your JIRA states that you've listed out. I think it's important for JIRA to contain this amount of state for the components that have several people in different places working on them. On Thu, Sep 19, 2013 at 12:09 PM, Marcel Kinard cmarc...@gmail.com wrote: This sounds like a solution to workflow issue. But what is our workflow? So if I understand correctly, the proposal is that a new bug that is unassigned means it has not been triaged. What would Jira state be for the following: - triaged and nobody plans to work on it yet (low priority) - triaged and person X plans to work on it, but they haven't started yet (person X's to do list) - triaged and person X plans to work on it, and they have started (in progress) And do these states need to be captured in Jira or is that overkill? Is it expected that the component owner does all the triage-ing? On Sep 18, 2013, at 11:00 PM, Andrew Grieve agri...@chromium.org wrote: Motivation: It's impossible to know whether new bugs have been looked at by the default assignee. Rationale: Setting it to unassigned, means new bugs will be obviously untriaged. Once assigned, it will mean someone intends to work on it. This won't eliminate bugs that get assigned and then not fixed in a timely fashion. I think that's okay though. It'll be an improvement anyways.
Re: [Android] WebView, InAppBrowser and UI Threads
Andrew, can you post a detailed use case of what you think is broken with URL
resolution? I think I am missing something.
Sent from my iPhone
On Sep 19, 2013, at 7:35 AM, Andrew Grieve agri...@chromium.org wrote:
On Thu, Sep 19, 2013 at 3:50 AM, purplecabbage purplecabb...@gmail.comwrote:
Why don't we make relative urls a developer concern? The developer should
know their own package, and it can be easily resolved using current
window.location and expected location of the file.
URLs are such a core piece of web APIs, that I think it would be quite bad
if we didn't properly support them (plus it's quite easy to do).
A minor rant, while we are on the subject of iab:
I don't understand why this executeScript madness was added. Why not just
call for a new URL with a javascript:prefix ?
If you want a full blown web-browser control then make a new plugin, iab
(originally ChildBrowser) was intended to show potentially unsafe code
inside your app without risk. The API is already non-standard, and worse
still it mimics a standard api but mutated. There are probably security
implications to all of these choices as well.
Native app WebView controls can inject JS, so why would we make ours less
powerful?
What is the use-case for insertCSS? Is it to load someone else's html with
your style sheet?
That would be my guess.
Sent from my iPhone
On Sep 18, 2013, at 7:31 PM, Andrew Grieve agri...@chromium.org wrote:
I assigned it to David just because I thought it would be a good bug for
him and thought it sounded important to fix. I don't think he's in any
hurry to get to it, so feel free to assign it to yourself. I don't really
consider bugs to be actually assigned when they are assigned to the
default
person since it's not clear that anyone's looked at it. Maybe it'd be
worth
having new bugs come in as unassigned, so that when someone assigns it,
it's more meaningful. I'll start another thread to discuss this idea.
Anyways, I've thought a good amount about this problem previously (what
to
do with relative URLs), and I think the best solution is to resolve
relative URLs in JS. iOS also has no good way of resolving relative URLs
from native. I added a function to do just that in this release -
require('cordova/urlutil').makeAbsolute(url)
I'll make a note of this on the bug.
On Wed, Sep 18, 2013 at 5:21 PM, Joe Bowser bows...@gmail.com wrote:
I'm currently trying to figure out CB-4858, which got assigned to
David, but I'm finding that I'm getting stuck at this part:
private String updateUrl(String url) {
Uri newUrl = Uri.parse(url);
if (newUrl.isRelative()) {
//url = this.webView.getUrl().substring(0,
this.webView.getUrl().lastIndexOf(/)+1) + url;
}
return url;
}
The problem with this code is that all methods on the WebView class
must run on the UI thread. Now, there's no easy way for us to pass
this data back because now we're doing asynchronous Java where we have
to wait for the UI thread to give us back the URL so we can find out
what our base path is.
We could override this in CordovaWebView, getting around the check,
but I think that this might not be the right thing to do.
Anyway, I'm content letting David chew on this, since I didn't know it
got assigned to him (JIRA didn't send me the e-mail), but I'd be
interested in seeing how this gets solved, because it's particularly
ugly.
Re: 3.1 Release
I was away a good chunk of yesterday due to a sick wife, getting BB tagged today. Sorry for the delay. On Thu, Sep 19, 2013 at 9:59 AM, Shazron shaz...@gmail.com wrote: Sorry for the iOS release guys I'm getting it out today On Thu, Sep 19, 2013 at 8:00 AM, Michal Mocny mmo...@chromium.org wrote: Specifically, I think the section Branch Tag RC1 for Platform Repositories On Thu, Sep 19, 2013 at 7:59 AM, Michal Mocny mmo...@chromium.org wrote: I think its this one: http://wiki.apache.org/cordova/CuttingReleases On Thu, Sep 19, 2013 at 7:52 AM, Jeffrey Heifetz jheif...@blackberry.comwrote: I can take the responsibility of tagging BlackBerry. Could you send me the wiki with instructions ? From: Andrew Grieve agri...@chromium.orgmailto:agri...@chromium.org Date: Thursday, 19 September, 2013 10:40 AM To: dev dev@cordova.apache.orgmailto:dev@cordova.apache.org, Jeffrey Heifetz jheif...@blackberry.commailto:jheif...@blackberry.com Subject: Re: 3.1 Release +Jeffrey - maybe you could take on the BlackBerry component for this release? On Thu, Sep 19, 2013 at 10:00 AM, Michael Brooks mich...@michaelbrooks.camailto:mich...@michaelbrooks.ca wrote: Once the platforms are tagged, I can handle the docs. I'll need to review our release process and see how the docs can best abide by them. On Wed, Sep 18, 2013 at 1:34 PM, Andrew Grieve agri...@chromium.org mailto:agri...@chromium.org wrote: Shaz - Thanks for the update :). If iOS is the last one then I'd say let's go without, but maybe keep at it until we get BB tagged? (just my opinion) Heading home now - anyone know if Lorin is away or not? On Wed, Sep 18, 2013 at 3:35 PM, Shazron shaz...@gmail.commailto: shaz...@gmail.com wrote: When i mean ios-deploy still works, it _installs_ it on the device, but does _not_ run it. On Wed, Sep 18, 2013 at 12:31 PM, Shazron shaz...@gmail.com mailto: shaz...@gmail.com wrote: I'm 99% done with iOS specific fixes. One last one I'm trying to do is ios-deploy with lldb: https://issues.apache.org/jira/browse/CB-4804 This means if I don't get this fix in, we _can_ deploy from the command line using ios-deploy _but_ we can't attach to the debugger. Will that be acceptable you think? On Wed, Sep 18, 2013 at 12:07 PM, Andrew Grieve agri...@chromium.orgmailto:agri...@chromium.org wrote: Ping Lorin Shaz. On Wed, Sep 18, 2013 at 2:19 AM, Steven Gill stevengil...@gmail.commailto:stevengil...@gmail.com wrote: FFOS will be tagged tomorrow. I have a few changes I am going to get in tomorrow before tagging but it will be good to go very soon! With FFOS, Only two plugins have been ported so far (vibration and device). We are going to continue to add firefoxos support to plugins post release. I don't think we should start officially promoting support for FFOS until we have more plugins. For 3.1, it will be available for users to try out, test, give feedback, etc. Cheers, -Steve On Tue, Sep 17, 2013 at 7:38 PM, Andrew Grieve agri...@chromium.orgmailto:agri...@chromium.org wrote: Thanks Jesse! Great work on being on top of things. If changes were done in plugin repos, then those aren't a part of this release anyways and will be picked up by the RELEASENOTES.md within the plugin repos on the next plugins release. I think it's up to you if you want to start writing RELEASENOTES.md for WP7+8. My thinking was just that doing so would make release announcements easier. Since WP7 and WP8 are in the same repo, does it make sense to have different subtasks for their taggings? If so, I'll add it to the template, if not, maybe I'll just change WP8 to say WP7+WP8? WDYT? Shaz - I see you're still checking in iOS7 fixes. Do you think you'll be able to tag iOS / OSX soon? Lorin - Same question for BB. Will you be able to write an update script for it (CB-4776) Steve - Likewise for FF I'd really like this tagging to be done tomorrow so that we can test out RC1 using RC1 of CLI. On Tue, Sep 17, 2013 at 10:00 PM, Jesse purplecabb...@gmail.com mailto:purplecabb...@gmail.com wrote: WP7, WP8, and Windows8 are all tagged 3.1.0-rc1 re: Changelog It is a little more difficult in these cases, and I n'er volunteered to do it, so whatevs - WP7+8 live in one repo, so their changes would need to be demuxed - all the changes for Windows8 have happened in the plugin repos,
Re: [Android] The state of WebSQL on Android 4.x
Tried out my email code, and despite my confidence, it doesn't work :P. So... Joe - like your plan. On Thu, Sep 19, 2013 at 12:32 PM, Brian LeRoux b...@brian.io wrote: yup. On Thu, Sep 19, 2013 at 5:42 PM, Joe Bowser bows...@gmail.com wrote: OK, how about we do this: 1. We indicate that we no longer support WebSQL on the docs and we list out why we don't support it as it currently exists 2. I'll look at the Android plugin that does do SQLite and see if it's appropriate for Android (if someone could do the same for iOS, that'd be cool): https://github.com/lite4mobi/Cordova-SQLitePlugin I think this looks far more promising than any of the hokey bullshit that we're currently doing, and it has contributors, and it's actually updated for Cordova 3.0. On Thu, Sep 19, 2013 at 7:53 AM, Ian Clelland iclell...@chromium.org wrote: On Thu, Sep 19, 2013 at 10:38 AM, Joe Bowser bows...@gmail.com wrote: OK, here's a crazy concept that I'm going to throw out there. How about we audit and recommend a third-party plugin and not do any more work on this issue. +1 I don't think there's enough consensus about whether WebSQL even belongs in the web platform for us to be insisting that it be part of Cordova. I would much rather see someone with a real interest in WebSQL be providing that functionality. Our job can be to make sure that we aren't getting in the way; that we are helping make plugins like that possible. Ian
Re: Proposal: Change JIRA to have bugs as unassigned by default
Leave it the way it was. Sent from my iPhone On Sep 19, 2013, at 8:49 AM, Joe Bowser bows...@gmail.com wrote: On second thought, I don't know if I like this proposal. Right now, everything Android gets assigned to me. Most people don't think I'm a real person when this stuff gets assigned, or they instantly hate me because I spend my time triaging the bugs as they come in. We do need someone to go through, read these issues, close the poorly written ones that have duplicates (i.e. Everything to do with WebSQL that's not written by Peter, ironically). This chews up a lot of my time. What WOULD be good is if people would be more aggressive with the JIRA issues. Even if you don't have time to fix the issue, just pinging people and letting them know that we haven't forgot about them goes a long way. I think that leaving everything unassigned is going to make it look like we're abandoning Cordova, which isn't the case. That being said, we should rotate who handles the firehose. On Thu, Sep 19, 2013 at 8:36 AM, purplecabbage purplecabb...@gmail.com wrote: 12 hours? I think we have to wait longer before moving on a proposal. Sent from my iPhone On Sep 19, 2013, at 7:29 AM, Andrew Grieve agri...@chromium.org wrote: Okay, I've made the change. Let's try it out :) I think start/stop is good if you've actually started working on something, but it's different from this new bug has been looked at by someone. On Thu, Sep 19, 2013 at 2:51 AM, Anis KADRI anis.ka...@gmail.com wrote: What about the start/stop progress? On Wed, Sep 18, 2013 at 9:03 PM, Ian Clelland iclell...@chromium.org wrote: +1 Also, if you are a component owner, it's pretty simple in JIRA to add a dashboard widget that shows you all unassigned bugs in your component. Ian On Wed, Sep 18, 2013 at 11:49 PM, Joe Bowser bows...@gmail.com wrote: +1
Re: Proposal: Change JIRA to have bugs as unassigned by default
On second thought, I don't know if I like this proposal. Right now, everything Android gets assigned to me. Most people don't think I'm a real person when this stuff gets assigned, or they instantly hate me because I spend my time triaging the bugs as they come in. We do need someone to go through, read these issues, close the poorly written ones that have duplicates (i.e. Everything to do with WebSQL that's not written by Peter, ironically). This chews up a lot of my time. What WOULD be good is if people would be more aggressive with the JIRA issues. Even if you don't have time to fix the issue, just pinging people and letting them know that we haven't forgot about them goes a long way. I think that leaving everything unassigned is going to make it look like we're abandoning Cordova, which isn't the case. That being said, we should rotate who handles the firehose. On Thu, Sep 19, 2013 at 8:36 AM, purplecabbage purplecabb...@gmail.com wrote: 12 hours? I think we have to wait longer before moving on a proposal. Sent from my iPhone On Sep 19, 2013, at 7:29 AM, Andrew Grieve agri...@chromium.org wrote: Okay, I've made the change. Let's try it out :) I think start/stop is good if you've actually started working on something, but it's different from this new bug has been looked at by someone. On Thu, Sep 19, 2013 at 2:51 AM, Anis KADRI anis.ka...@gmail.com wrote: What about the start/stop progress? On Wed, Sep 18, 2013 at 9:03 PM, Ian Clelland iclell...@chromium.org wrote: +1 Also, if you are a component owner, it's pretty simple in JIRA to add a dashboard widget that shows you all unassigned bugs in your component. Ian On Wed, Sep 18, 2013 at 11:49 PM, Joe Bowser bows...@gmail.com wrote: +1
Change plugin IDs from org.cordova.core.FOO - org.cordova.FOO
Anis and I discussed a bit on https://issues.apache.org/jira/browse/CB-4493 So I filed https://issues.apache.org/jira/browse/CB-4874 Wanted to see if anyone could think of what adverse effects this might have before going through with it. Only thing I can think of is that I'd need to update the dependency tags of all plugins (mobile spec and our own). The result of not updating them isn't horrible since the dependencies still install via URL. On a related note - we need remove the url= parameter from the dependency so that it looks to the registry. Once we discuss / take one of these paths, I'd like to do a plugins release so that we can test this flow with RC1.
Re: 3.1 Release
Sorry for the iOS release guys I'm getting it out today On Thu, Sep 19, 2013 at 8:00 AM, Michal Mocny mmo...@chromium.org wrote: Specifically, I think the section Branch Tag RC1 for Platform Repositories On Thu, Sep 19, 2013 at 7:59 AM, Michal Mocny mmo...@chromium.org wrote: I think its this one: http://wiki.apache.org/cordova/CuttingReleases On Thu, Sep 19, 2013 at 7:52 AM, Jeffrey Heifetz jheif...@blackberry.comwrote: I can take the responsibility of tagging BlackBerry. Could you send me the wiki with instructions ? From: Andrew Grieve agri...@chromium.orgmailto:agri...@chromium.org Date: Thursday, 19 September, 2013 10:40 AM To: dev dev@cordova.apache.orgmailto:dev@cordova.apache.org, Jeffrey Heifetz jheif...@blackberry.commailto:jheif...@blackberry.com Subject: Re: 3.1 Release +Jeffrey - maybe you could take on the BlackBerry component for this release? On Thu, Sep 19, 2013 at 10:00 AM, Michael Brooks mich...@michaelbrooks.camailto:mich...@michaelbrooks.ca wrote: Once the platforms are tagged, I can handle the docs. I'll need to review our release process and see how the docs can best abide by them. On Wed, Sep 18, 2013 at 1:34 PM, Andrew Grieve agri...@chromium.org mailto:agri...@chromium.org wrote: Shaz - Thanks for the update :). If iOS is the last one then I'd say let's go without, but maybe keep at it until we get BB tagged? (just my opinion) Heading home now - anyone know if Lorin is away or not? On Wed, Sep 18, 2013 at 3:35 PM, Shazron shaz...@gmail.commailto: shaz...@gmail.com wrote: When i mean ios-deploy still works, it _installs_ it on the device, but does _not_ run it. On Wed, Sep 18, 2013 at 12:31 PM, Shazron shaz...@gmail.com mailto: shaz...@gmail.com wrote: I'm 99% done with iOS specific fixes. One last one I'm trying to do is ios-deploy with lldb: https://issues.apache.org/jira/browse/CB-4804 This means if I don't get this fix in, we _can_ deploy from the command line using ios-deploy _but_ we can't attach to the debugger. Will that be acceptable you think? On Wed, Sep 18, 2013 at 12:07 PM, Andrew Grieve agri...@chromium.orgmailto:agri...@chromium.org wrote: Ping Lorin Shaz. On Wed, Sep 18, 2013 at 2:19 AM, Steven Gill stevengil...@gmail.commailto:stevengil...@gmail.com wrote: FFOS will be tagged tomorrow. I have a few changes I am going to get in tomorrow before tagging but it will be good to go very soon! With FFOS, Only two plugins have been ported so far (vibration and device). We are going to continue to add firefoxos support to plugins post release. I don't think we should start officially promoting support for FFOS until we have more plugins. For 3.1, it will be available for users to try out, test, give feedback, etc. Cheers, -Steve On Tue, Sep 17, 2013 at 7:38 PM, Andrew Grieve agri...@chromium.orgmailto:agri...@chromium.org wrote: Thanks Jesse! Great work on being on top of things. If changes were done in plugin repos, then those aren't a part of this release anyways and will be picked up by the RELEASENOTES.md within the plugin repos on the next plugins release. I think it's up to you if you want to start writing RELEASENOTES.md for WP7+8. My thinking was just that doing so would make release announcements easier. Since WP7 and WP8 are in the same repo, does it make sense to have different subtasks for their taggings? If so, I'll add it to the template, if not, maybe I'll just change WP8 to say WP7+WP8? WDYT? Shaz - I see you're still checking in iOS7 fixes. Do you think you'll be able to tag iOS / OSX soon? Lorin - Same question for BB. Will you be able to write an update script for it (CB-4776) Steve - Likewise for FF I'd really like this tagging to be done tomorrow so that we can test out RC1 using RC1 of CLI. On Tue, Sep 17, 2013 at 10:00 PM, Jesse purplecabb...@gmail.com mailto:purplecabb...@gmail.com wrote: WP7, WP8, and Windows8 are all tagged 3.1.0-rc1 re: Changelog It is a little more difficult in these cases, and I n'er volunteered to do it, so whatevs - WP7+8 live in one repo, so their changes would need to be demuxed - all the changes for Windows8 have happened in the plugin repos, and cordova-js, so changelog would be empty Maybe I'll get this together for the 3.1.0, we'll see. @purplecabbage risingj.comhttp://risingj.com On Tue, Sep 17, 2013 at 12:34 PM, Andrew Grieve agri...@chromium.orgmailto:agri...@chromium.org wrote: For
Re: Registry based plugins and dependency tags
npm must have some way of doing this. ie. some combination of link+install that resolves dependencies locally. @purplecabbage risingj.com On Thu, Sep 19, 2013 at 11:56 AM, Andrew Grieve agri...@chromium.orgwrote: The logic is: - If there's a url, use it, otherwise use the registry. If I'm developing on a plugin, and that plugin has a dependency, I don't want it fetching it from the registry. I could change the dependency to have a url= to the local path, but then I need to remember to take that out before publishing. So... I'm thinking it would be useful to allow projects to provide their own file-backed local registry. E.g. a JSON file of pluginId - url/path. Where the new algorithm would be: if id in localRegistry, use that url, otherwise, use the registry. I think this will be super useful for projects that want to distribute plugins off-registry as well. Question is - where's the best place for this? My first thought was in CLI's .cordova/config.json, but that won't work for plugman projects. homedir may address some use-cases, but project-specific local registry is still important I think. So... Maybe for CLI projects, we put it in .cordova/config.json and for plugman you use a --localregistry=FILE flag?
Plugin Generator
I was looking for something to help me create a plugin but i didn't see anything, so i created a yeoman generator: https://npmjs.org/package/generator-cordova-plugin here is version 0.0.1
Re: Plugin Generator
version 0.0.1 :) On Sep 19, 2013, at 3:28 PM, Shazron shaz...@gmail.com wrote: Awesome! Any reason not to use js-module instead? On Thu, Sep 19, 2013 at 12:22 PM, Lucas Holmquist lholm...@redhat.comwrote: I was looking for something to help me create a plugin but i didn't see anything, so i created a yeoman generator: https://npmjs.org/package/generator-cordova-plugin here is version 0.0.1
Re: Plugin Generator
also, i didn't scroll down that far. On Sep 19, 2013, at 3:29 PM, Lucas Holmquist lholm...@redhat.com wrote: version 0.0.1 :) On Sep 19, 2013, at 3:28 PM, Shazron shaz...@gmail.com wrote: Awesome! Any reason not to use js-module instead? On Thu, Sep 19, 2013 at 12:22 PM, Lucas Holmquist lholm...@redhat.comwrote: I was looking for something to help me create a plugin but i didn't see anything, so i created a yeoman generator: https://npmjs.org/package/generator-cordova-plugin here is version 0.0.1
Re: Plugin Generator
Heh ;) I was waiting for patches welcome :) On Thu, Sep 19, 2013 at 12:29 PM, Lucas Holmquist lholm...@redhat.comwrote: version 0.0.1 :) On Sep 19, 2013, at 3:28 PM, Shazron shaz...@gmail.com wrote: Awesome! Any reason not to use js-module instead? On Thu, Sep 19, 2013 at 12:22 PM, Lucas Holmquist lholm...@redhat.com wrote: I was looking for something to help me create a plugin but i didn't see anything, so i created a yeoman generator: https://npmjs.org/package/generator-cordova-plugin here is version 0.0.1
Re: [Android] WebView, InAppBrowser and UI Threads
Is this the use case ?
window.open('subFldr/page.html','_blank');
or are you talking about the page inside the iab loading another page
via relative url?
Sent from my iPhone
On Sep 19, 2013, at 9:31 AM, Andrew Grieve agri...@chromium.org wrote:
You suggested making relative URLs a developer concern. I thought by this
you meant our plugins shouldn't support relative URLs. Not supporting
relative URLs would be broken IMO. Maybe you meant something different by
that?
On Thu, Sep 19, 2013 at 11:48 AM, purplecabbage
purplecabb...@gmail.comwrote:
Andrew, can you post a detailed use case of what you think is broken with
URL resolution? I think I am missing something.
Sent from my iPhone
On Sep 19, 2013, at 7:35 AM, Andrew Grieve agri...@chromium.org wrote:
On Thu, Sep 19, 2013 at 3:50 AM, purplecabbage purplecabb...@gmail.com
wrote:
Why don't we make relative urls a developer concern? The developer
should
know their own package, and it can be easily resolved using current
window.location and expected location of the file.
URLs are such a core piece of web APIs, that I think it would be quite
bad
if we didn't properly support them (plus it's quite easy to do).
A minor rant, while we are on the subject of iab:
I don't understand why this executeScript madness was added. Why not
just
call for a new URL with a javascript:prefix ?
If you want a full blown web-browser control then make a new plugin, iab
(originally ChildBrowser) was intended to show potentially unsafe code
inside your app without risk. The API is already non-standard, and worse
still it mimics a standard api but mutated. There are probably security
implications to all of these choices as well.
Native app WebView controls can inject JS, so why would we make ours less
powerful?
What is the use-case for insertCSS? Is it to load someone else's html
with
your style sheet?
That would be my guess.
Sent from my iPhone
On Sep 18, 2013, at 7:31 PM, Andrew Grieve agri...@chromium.org
wrote:
I assigned it to David just because I thought it would be a good bug
for
him and thought it sounded important to fix. I don't think he's in any
hurry to get to it, so feel free to assign it to yourself. I don't
really
consider bugs to be actually assigned when they are assigned to the
default
person since it's not clear that anyone's looked at it. Maybe it'd be
worth
having new bugs come in as unassigned, so that when someone assigns
it,
it's more meaningful. I'll start another thread to discuss this idea.
Anyways, I've thought a good amount about this problem previously (what
to
do with relative URLs), and I think the best solution is to resolve
relative URLs in JS. iOS also has no good way of resolving relative
URLs
from native. I added a function to do just that in this release -
require('cordova/urlutil').makeAbsolute(url)
I'll make a note of this on the bug.
On Wed, Sep 18, 2013 at 5:21 PM, Joe Bowser bows...@gmail.com
wrote:
I'm currently trying to figure out CB-4858, which got assigned to
David, but I'm finding that I'm getting stuck at this part:
private String updateUrl(String url) {
Uri newUrl = Uri.parse(url);
if (newUrl.isRelative()) {
//url = this.webView.getUrl().substring(0,
this.webView.getUrl().lastIndexOf(/)+1) + url;
}
return url;
}
The problem with this code is that all methods on the WebView class
must run on the UI thread. Now, there's no easy way for us to pass
this data back because now we're doing asynchronous Java where we have
to wait for the UI thread to give us back the URL so we can find out
what our base path is.
We could override this in CordovaWebView, getting around the check,
but I think that this might not be the right thing to do.
Anyway, I'm content letting David chew on this, since I didn't know it
got assigned to him (JIRA didn't send me the e-mail), but I'd be
interested in seeing how this gets solved, because it's particularly
ugly.
Re: Proposal: Change JIRA to have bugs as unassigned by default
Is it expected that the component owner does all the triage-ing? -- That is what I expected, but this may not work with multiple committers and/or vacation schedules Personally after a release I triage all issues (starting with component iOS) regardless of assignment, mainly because some issues have no component and are miscategorized, and I unassign stuff that I don't think I can work on. This only works for me of course but does not communicate much to others in the interim. I also try to triage issues that come in when I am notified by JIRA through email. Thus, I think the unassigned default is fine, component owners should have a search filter for the component == [platform] and assigned = '' for triage going forward I suppose. On Thu, Sep 19, 2013 at 11:58 AM, Jesse purplecabb...@gmail.com wrote: My rationale was/is that this change will inevitably lead to a whiteboard state machine diagram where we overly define the lifetime of a defect/task/feature in jira. I was still half asleep though ... I am okay with the way it was, and the way it is now is fine too. Unassigned does makes sense for the more volatile repos. @purplecabbage risingj.com On Thu, Sep 19, 2013 at 11:49 AM, Steven Gill stevengil...@gmail.com wrote: I think for plugins it should be unassigned by default seeing how it can affect any/all platforms. On Thu, Sep 19, 2013 at 10:35 AM, Lorin Beer lorin.beer@gmail.com wrote: apology already posted, but I'll reiterate that 12 hours for a process change that affects all assignees is way to short, especially on a project with contributors across the globe. On Thu, Sep 19, 2013 at 9:29 AM, Andrew Grieve agri...@chromium.org wrote: Sorry for jumping the gun - figured this would be an easy thing the change back if people started -1ing. Also don't think we necessarily need all components to work the same. I'm specifically only interested in the components that I do triage on: Android, iOS, Mobile Spec, JS, Plugins. Jesse - What's your rationale for wanting it to stay the way it was before? (I've changed the windows ones back) Joe - I also spend a lot of time triaging bugs as they come in. I've been doing it for many months now. I think it's fine for anyone to triage, because often the best person to do so changes depending on the bug. I actually think having an explicit triage step will make our project seem more alive, since people will see action taken on their bugs (adding an assignee). Marcel - I like your JIRA states that you've listed out. I think it's important for JIRA to contain this amount of state for the components that have several people in different places working on them. On Thu, Sep 19, 2013 at 12:09 PM, Marcel Kinard cmarc...@gmail.com wrote: This sounds like a solution to workflow issue. But what is our workflow? So if I understand correctly, the proposal is that a new bug that is unassigned means it has not been triaged. What would Jira state be for the following: - triaged and nobody plans to work on it yet (low priority) - triaged and person X plans to work on it, but they haven't started yet (person X's to do list) - triaged and person X plans to work on it, and they have started (in progress) And do these states need to be captured in Jira or is that overkill? Is it expected that the component owner does all the triage-ing? On Sep 18, 2013, at 11:00 PM, Andrew Grieve agri...@chromium.org wrote: Motivation: It's impossible to know whether new bugs have been looked at by the default assignee. Rationale: Setting it to unassigned, means new bugs will be obviously untriaged. Once assigned, it will mean someone intends to work on it. This won't eliminate bugs that get assigned and then not fixed in a timely fashion. I think that's okay though. It'll be an improvement anyways.
Re: Registry based plugins and dependency tags
+1 for project specific registry (not home dir) On Thu, Sep 19, 2013 at 2:59 PM, Braden Shepherdson bra...@chromium.orgwrote: One alternative is to symlink it into $HOME/.plugman/cache/my.plugin.id. Then plugman when fetching it will use that, assuming the version is new enough. I think the right place for the file is in ~/.plugman/localRegistry.json or similar, since fetching plugins is definitely plugman's responsibility and not CLI's. Braden On Thu, Sep 19, 2013 at 2:56 PM, Andrew Grieve agri...@chromium.org wrote: The logic is: - If there's a url, use it, otherwise use the registry. If I'm developing on a plugin, and that plugin has a dependency, I don't want it fetching it from the registry. I could change the dependency to have a url= to the local path, but then I need to remember to take that out before publishing. So... I'm thinking it would be useful to allow projects to provide their own file-backed local registry. E.g. a JSON file of pluginId - url/path. Where the new algorithm would be: if id in localRegistry, use that url, otherwise, use the registry. I think this will be super useful for projects that want to distribute plugins off-registry as well. Question is - where's the best place for this? My first thought was in CLI's .cordova/config.json, but that won't work for plugman projects. homedir may address some use-cases, but project-specific local registry is still important I think. So... Maybe for CLI projects, we put it in .cordova/config.json and for plugman you use a --localregistry=FILE flag?
Re: plugman / cli verbose by default?
https://issues.apache.org/jira/browse/CB-4877 On Fri, Sep 6, 2013 at 9:39 PM, James Jong wjamesj...@gmail.com wrote: +1 SGTM -James Jong On Sep 6, 2013, at 6:41 PM, Tommy-Carlos Williams to...@devgeeks.org wrote: This. +1 On 07/09/2013, at 2:57 AM, Brian LeRoux b...@brian.io wrote: I think this is reasonable. So, default is 'light logging'. As a module it is no logging. As an option it is very verbose java style logging. - tommy
Re: [Android] WebView, InAppBrowser and UI Threads
On Thu, Sep 19, 2013 at 3:06 PM, Jesse purplecabb...@gmail.com wrote:
Is this the use case ?
window.open('subFldr/page.html','_blank');
or are you talking about the page inside the iab loading another page
via relative url?
I think that's the use case.
Sent from my iPhone
On Sep 19, 2013, at 9:31 AM, Andrew Grieve agri...@chromium.org wrote:
You suggested making relative URLs a developer concern. I thought by this
you meant our plugins shouldn't support relative URLs. Not supporting
relative URLs would be broken IMO. Maybe you meant something different by
that?
On Thu, Sep 19, 2013 at 11:48 AM, purplecabbage purplecabb...@gmail.com
wrote:
Andrew, can you post a detailed use case of what you think is broken
with
URL resolution? I think I am missing something.
Sent from my iPhone
On Sep 19, 2013, at 7:35 AM, Andrew Grieve agri...@chromium.org
wrote:
On Thu, Sep 19, 2013 at 3:50 AM, purplecabbage
purplecabb...@gmail.com
wrote:
Why don't we make relative urls a developer concern? The developer
should
know their own package, and it can be easily resolved using current
window.location and expected location of the file.
URLs are such a core piece of web APIs, that I think it would be quite
bad
if we didn't properly support them (plus it's quite easy to do).
A minor rant, while we are on the subject of iab:
I don't understand why this executeScript madness was added. Why not
just
call for a new URL with a javascript:prefix ?
If you want a full blown web-browser control then make a new plugin,
iab
(originally ChildBrowser) was intended to show potentially unsafe code
inside your app without risk. The API is already non-standard, and
worse
still it mimics a standard api but mutated. There are probably
security
implications to all of these choices as well.
Native app WebView controls can inject JS, so why would we make ours
less
powerful?
What is the use-case for insertCSS? Is it to load someone else's html
with
your style sheet?
That would be my guess.
Sent from my iPhone
On Sep 18, 2013, at 7:31 PM, Andrew Grieve agri...@chromium.org
wrote:
I assigned it to David just because I thought it would be a good bug
for
him and thought it sounded important to fix. I don't think he's in
any
hurry to get to it, so feel free to assign it to yourself. I don't
really
consider bugs to be actually assigned when they are assigned to the
default
person since it's not clear that anyone's looked at it. Maybe it'd be
worth
having new bugs come in as unassigned, so that when someone assigns
it,
it's more meaningful. I'll start another thread to discuss this idea.
Anyways, I've thought a good amount about this problem previously
(what
to
do with relative URLs), and I think the best solution is to resolve
relative URLs in JS. iOS also has no good way of resolving relative
URLs
from native. I added a function to do just that in this release -
require('cordova/urlutil').makeAbsolute(url)
I'll make a note of this on the bug.
On Wed, Sep 18, 2013 at 5:21 PM, Joe Bowser bows...@gmail.com
wrote:
I'm currently trying to figure out CB-4858, which got assigned to
David, but I'm finding that I'm getting stuck at this part:
private String updateUrl(String url) {
Uri newUrl = Uri.parse(url);
if (newUrl.isRelative()) {
//url = this.webView.getUrl().substring(0,
this.webView.getUrl().lastIndexOf(/)+1) + url;
}
return url;
}
The problem with this code is that all methods on the WebView class
must run on the UI thread. Now, there's no easy way for us to pass
this data back because now we're doing asynchronous Java where we
have
to wait for the UI thread to give us back the URL so we can find out
what our base path is.
We could override this in CordovaWebView, getting around the check,
but I think that this might not be the right thing to do.
Anyway, I'm content letting David chew on this, since I didn't know
it
got assigned to him (JIRA didn't send me the e-mail), but I'd be
interested in seeing how this gets solved, because it's particularly
ugly.
Re: Proposal: Change JIRA to have bugs as unassigned by default
I think for plugins it should be unassigned by default seeing how it can affect any/all platforms. On Thu, Sep 19, 2013 at 10:35 AM, Lorin Beer lorin.beer@gmail.comwrote: apology already posted, but I'll reiterate that 12 hours for a process change that affects all assignees is way to short, especially on a project with contributors across the globe. On Thu, Sep 19, 2013 at 9:29 AM, Andrew Grieve agri...@chromium.org wrote: Sorry for jumping the gun - figured this would be an easy thing the change back if people started -1ing. Also don't think we necessarily need all components to work the same. I'm specifically only interested in the components that I do triage on: Android, iOS, Mobile Spec, JS, Plugins. Jesse - What's your rationale for wanting it to stay the way it was before? (I've changed the windows ones back) Joe - I also spend a lot of time triaging bugs as they come in. I've been doing it for many months now. I think it's fine for anyone to triage, because often the best person to do so changes depending on the bug. I actually think having an explicit triage step will make our project seem more alive, since people will see action taken on their bugs (adding an assignee). Marcel - I like your JIRA states that you've listed out. I think it's important for JIRA to contain this amount of state for the components that have several people in different places working on them. On Thu, Sep 19, 2013 at 12:09 PM, Marcel Kinard cmarc...@gmail.com wrote: This sounds like a solution to workflow issue. But what is our workflow? So if I understand correctly, the proposal is that a new bug that is unassigned means it has not been triaged. What would Jira state be for the following: - triaged and nobody plans to work on it yet (low priority) - triaged and person X plans to work on it, but they haven't started yet (person X's to do list) - triaged and person X plans to work on it, and they have started (in progress) And do these states need to be captured in Jira or is that overkill? Is it expected that the component owner does all the triage-ing? On Sep 18, 2013, at 11:00 PM, Andrew Grieve agri...@chromium.org wrote: Motivation: It's impossible to know whether new bugs have been looked at by the default assignee. Rationale: Setting it to unassigned, means new bugs will be obviously untriaged. Once assigned, it will mean someone intends to work on it. This won't eliminate bugs that get assigned and then not fixed in a timely fashion. I think that's okay though. It'll be an improvement anyways.
Re: Proposal: Change JIRA to have bugs as unassigned by default
Sorry for jumping the gun - figured this would be an easy thing the change back if people started -1ing. Also don't think we necessarily need all components to work the same. I'm specifically only interested in the components that I do triage on: Android, iOS, Mobile Spec, JS, Plugins. Jesse - What's your rationale for wanting it to stay the way it was before? (I've changed the windows ones back) Joe - I also spend a lot of time triaging bugs as they come in. I've been doing it for many months now. I think it's fine for anyone to triage, because often the best person to do so changes depending on the bug. I actually think having an explicit triage step will make our project seem more alive, since people will see action taken on their bugs (adding an assignee). Marcel - I like your JIRA states that you've listed out. I think it's important for JIRA to contain this amount of state for the components that have several people in different places working on them. On Thu, Sep 19, 2013 at 12:09 PM, Marcel Kinard cmarc...@gmail.com wrote: This sounds like a solution to workflow issue. But what is our workflow? So if I understand correctly, the proposal is that a new bug that is unassigned means it has not been triaged. What would Jira state be for the following: - triaged and nobody plans to work on it yet (low priority) - triaged and person X plans to work on it, but they haven't started yet (person X's to do list) - triaged and person X plans to work on it, and they have started (in progress) And do these states need to be captured in Jira or is that overkill? Is it expected that the component owner does all the triage-ing? On Sep 18, 2013, at 11:00 PM, Andrew Grieve agri...@chromium.org wrote: Motivation: It's impossible to know whether new bugs have been looked at by the default assignee. Rationale: Setting it to unassigned, means new bugs will be obviously untriaged. Once assigned, it will mean someone intends to work on it. This won't eliminate bugs that get assigned and then not fixed in a timely fashion. I think that's okay though. It'll be an improvement anyways.
Re: [Android] WebView, InAppBrowser and UI Threads
You suggested making relative URLs a developer concern. I thought by this
you meant our plugins shouldn't support relative URLs. Not supporting
relative URLs would be broken IMO. Maybe you meant something different by
that?
On Thu, Sep 19, 2013 at 11:48 AM, purplecabbage purplecabb...@gmail.comwrote:
Andrew, can you post a detailed use case of what you think is broken with
URL resolution? I think I am missing something.
Sent from my iPhone
On Sep 19, 2013, at 7:35 AM, Andrew Grieve agri...@chromium.org wrote:
On Thu, Sep 19, 2013 at 3:50 AM, purplecabbage purplecabb...@gmail.com
wrote:
Why don't we make relative urls a developer concern? The developer
should
know their own package, and it can be easily resolved using current
window.location and expected location of the file.
URLs are such a core piece of web APIs, that I think it would be quite
bad
if we didn't properly support them (plus it's quite easy to do).
A minor rant, while we are on the subject of iab:
I don't understand why this executeScript madness was added. Why not
just
call for a new URL with a javascript:prefix ?
If you want a full blown web-browser control then make a new plugin, iab
(originally ChildBrowser) was intended to show potentially unsafe code
inside your app without risk. The API is already non-standard, and worse
still it mimics a standard api but mutated. There are probably security
implications to all of these choices as well.
Native app WebView controls can inject JS, so why would we make ours less
powerful?
What is the use-case for insertCSS? Is it to load someone else's html
with
your style sheet?
That would be my guess.
Sent from my iPhone
On Sep 18, 2013, at 7:31 PM, Andrew Grieve agri...@chromium.org
wrote:
I assigned it to David just because I thought it would be a good bug
for
him and thought it sounded important to fix. I don't think he's in any
hurry to get to it, so feel free to assign it to yourself. I don't
really
consider bugs to be actually assigned when they are assigned to the
default
person since it's not clear that anyone's looked at it. Maybe it'd be
worth
having new bugs come in as unassigned, so that when someone assigns
it,
it's more meaningful. I'll start another thread to discuss this idea.
Anyways, I've thought a good amount about this problem previously (what
to
do with relative URLs), and I think the best solution is to resolve
relative URLs in JS. iOS also has no good way of resolving relative
URLs
from native. I added a function to do just that in this release -
require('cordova/urlutil').makeAbsolute(url)
I'll make a note of this on the bug.
On Wed, Sep 18, 2013 at 5:21 PM, Joe Bowser bows...@gmail.com
wrote:
I'm currently trying to figure out CB-4858, which got assigned to
David, but I'm finding that I'm getting stuck at this part:
private String updateUrl(String url) {
Uri newUrl = Uri.parse(url);
if (newUrl.isRelative()) {
//url = this.webView.getUrl().substring(0,
this.webView.getUrl().lastIndexOf(/)+1) + url;
}
return url;
}
The problem with this code is that all methods on the WebView class
must run on the UI thread. Now, there's no easy way for us to pass
this data back because now we're doing asynchronous Java where we have
to wait for the UI thread to give us back the URL so we can find out
what our base path is.
We could override this in CordovaWebView, getting around the check,
but I think that this might not be the right thing to do.
Anyway, I'm content letting David chew on this, since I didn't know it
got assigned to him (JIRA didn't send me the e-mail), but I'd be
interested in seeing how this gets solved, because it's particularly
ugly.
Re: [Android] The state of WebSQL on Android 4.x
OK, I tried the tests included with the plugin, and they don't run. Can someone sanity check this for me? I'm going to try running this on additional devices, since it could be a weird Cyanogen thing. But yeah, if other people can try this plugin, that'd be awesome. On Thu, Sep 19, 2013 at 10:12 AM, Andrew Grieve agri...@chromium.org wrote: Tried out my email code, and despite my confidence, it doesn't work :P. So... Joe - like your plan. On Thu, Sep 19, 2013 at 12:32 PM, Brian LeRoux b...@brian.io wrote: yup. On Thu, Sep 19, 2013 at 5:42 PM, Joe Bowser bows...@gmail.com wrote: OK, how about we do this: 1. We indicate that we no longer support WebSQL on the docs and we list out why we don't support it as it currently exists 2. I'll look at the Android plugin that does do SQLite and see if it's appropriate for Android (if someone could do the same for iOS, that'd be cool): https://github.com/lite4mobi/Cordova-SQLitePlugin I think this looks far more promising than any of the hokey bullshit that we're currently doing, and it has contributors, and it's actually updated for Cordova 3.0. On Thu, Sep 19, 2013 at 7:53 AM, Ian Clelland iclell...@chromium.org wrote: On Thu, Sep 19, 2013 at 10:38 AM, Joe Bowser bows...@gmail.com wrote: OK, here's a crazy concept that I'm going to throw out there. How about we audit and recommend a third-party plugin and not do any more work on this issue. +1 I don't think there's enough consensus about whether WebSQL even belongs in the web platform for us to be insisting that it be part of Cordova. I would much rather see someone with a real interest in WebSQL be providing that functionality. Our job can be to make sure that we aren't getting in the way; that we are helping make plugins like that possible. Ian
Re: Proposal: Change JIRA to have bugs as unassigned by default
My rationale was/is that this change will inevitably lead to a whiteboard state machine diagram where we overly define the lifetime of a defect/task/feature in jira. I was still half asleep though ... I am okay with the way it was, and the way it is now is fine too. Unassigned does makes sense for the more volatile repos. @purplecabbage risingj.com On Thu, Sep 19, 2013 at 11:49 AM, Steven Gill stevengil...@gmail.comwrote: I think for plugins it should be unassigned by default seeing how it can affect any/all platforms. On Thu, Sep 19, 2013 at 10:35 AM, Lorin Beer lorin.beer@gmail.com wrote: apology already posted, but I'll reiterate that 12 hours for a process change that affects all assignees is way to short, especially on a project with contributors across the globe. On Thu, Sep 19, 2013 at 9:29 AM, Andrew Grieve agri...@chromium.org wrote: Sorry for jumping the gun - figured this would be an easy thing the change back if people started -1ing. Also don't think we necessarily need all components to work the same. I'm specifically only interested in the components that I do triage on: Android, iOS, Mobile Spec, JS, Plugins. Jesse - What's your rationale for wanting it to stay the way it was before? (I've changed the windows ones back) Joe - I also spend a lot of time triaging bugs as they come in. I've been doing it for many months now. I think it's fine for anyone to triage, because often the best person to do so changes depending on the bug. I actually think having an explicit triage step will make our project seem more alive, since people will see action taken on their bugs (adding an assignee). Marcel - I like your JIRA states that you've listed out. I think it's important for JIRA to contain this amount of state for the components that have several people in different places working on them. On Thu, Sep 19, 2013 at 12:09 PM, Marcel Kinard cmarc...@gmail.com wrote: This sounds like a solution to workflow issue. But what is our workflow? So if I understand correctly, the proposal is that a new bug that is unassigned means it has not been triaged. What would Jira state be for the following: - triaged and nobody plans to work on it yet (low priority) - triaged and person X plans to work on it, but they haven't started yet (person X's to do list) - triaged and person X plans to work on it, and they have started (in progress) And do these states need to be captured in Jira or is that overkill? Is it expected that the component owner does all the triage-ing? On Sep 18, 2013, at 11:00 PM, Andrew Grieve agri...@chromium.org wrote: Motivation: It's impossible to know whether new bugs have been looked at by the default assignee. Rationale: Setting it to unassigned, means new bugs will be obviously untriaged. Once assigned, it will mean someone intends to work on it. This won't eliminate bugs that get assigned and then not fixed in a timely fashion. I think that's okay though. It'll be an improvement anyways.
Registry based plugins and dependency tags
The logic is: - If there's a url, use it, otherwise use the registry. If I'm developing on a plugin, and that plugin has a dependency, I don't want it fetching it from the registry. I could change the dependency to have a url= to the local path, but then I need to remember to take that out before publishing. So... I'm thinking it would be useful to allow projects to provide their own file-backed local registry. E.g. a JSON file of pluginId - url/path. Where the new algorithm would be: if id in localRegistry, use that url, otherwise, use the registry. I think this will be super useful for projects that want to distribute plugins off-registry as well. Question is - where's the best place for this? My first thought was in CLI's .cordova/config.json, but that won't work for plugman projects. homedir may address some use-cases, but project-specific local registry is still important I think. So... Maybe for CLI projects, we put it in .cordova/config.json and for plugman you use a --localregistry=FILE flag?
Re: Want to contribute
you've taken the first step by emailing de-subscr...@cordova.apache.org. The second step should be to sign the CLA. You can read about it and the contributor workflow here: http://wiki.apache.org/cordova/ContributorWorkflowhttp://wiki.apache.org/cordova/ContributorWorkflow Once you've signed and submitted your CLA, feel free to browse currently open issues on the project here: https://issues.apache.org/jira/browse/CB https://issues.apache.org/jira/browse/CB If you see an issue you are interested in, just ping the assignee to get any background information, and you can ask the list if you need any help. Thanks for your interest and we welcome your first contribution! - Lorin On Thu, Sep 19, 2013 at 10:53 AM, Naik, Archana na...@lab126.com wrote: Hello, Cordova Devs, I would like to subscribe to Cordova as a dev and contribute possibly in near future. Please add me to these mailing list. Thanks Archana
NSURLCache from disk behavior
We have an enterprise app, a part of which is online and we are seeing that NSURLCache works fine when the cache bits are served from the memory. Now if the app exited and is restarted (as opposed to resumed) NSURLCache is not serving the pages from the disk (as memory cache is wiped) The disk part of the cache below seems to be populated as the sqlite DB is not empty and is growing in size as the online part of the application is browsed but returns nil when asked for the cached copy of the document. Has anybody run into this ? int cacheSizeMemory = 8 * 1024 * 1024; // 8MB int cacheSizeDisk = 32 * 1024 * 1024; // 32MB NSURLCache* sharedCache = [[NSURLCache alloc] initWithMemoryCapacity:cacheSizeMemory diskCapacity:cacheSizeDisk diskPath:@nsurlcache]; [NSURLCache setSharedURLCache:sharedCache]; Thanks Raman
Re: NSURLCache from disk behavior
See: https://issues.apache.org/jira/browse/CB-3071 On Thu, Sep 19, 2013 at 3:46 PM, Sethi, Raman ra.se...@sap.com wrote: We have an enterprise app, a part of which is online and we are seeing that NSURLCache works fine when the cache bits are served from the memory. Now if the app exited and is restarted (as opposed to resumed) NSURLCache is not serving the pages from the disk (as memory cache is wiped) The disk part of the cache below seems to be populated as the sqlite DB is not empty and is growing in size as the online part of the application is browsed but returns nil when asked for the cached copy of the document. Has anybody run into this ? int cacheSizeMemory = 8 * 1024 * 1024; // 8MB int cacheSizeDisk = 32 * 1024 * 1024; // 32MB NSURLCache* sharedCache = [[NSURLCache alloc] initWithMemoryCapacity:cacheSizeMemory diskCapacity:cacheSizeDisk diskPath:@ nsurlcache]; [NSURLCache setSharedURLCache:sharedCache]; Thanks Raman
Re: Git Push Summary
Should this be 3.1.0-rc1 instead? On Thu, Sep 19, 2013 at 1:58 PM, lorinb...@apache.org wrote: Updated Tags: refs/tags/3.1.0rc1 [created] 213bb9f4e
Re: [Android] The state of WebSQL on Android 4.x
Managed to get a simpler version of my email coding to work!
var ifr = document.createElement('iframe');
ifr.src = websql://foo;
ifr.onload = function() {
window.openDatabase = function() {
return
ifr.contentWindow.openDatabase.apply(ifr.contentWindow, arguments);
};
Also needs a couple lines of Java to return html/html for the
request to websql://foo
The gotcha here is that you need to make sure to not detach the iframe from
the document. No biggie, but need to be aware of it.
This can all be easily put into a plugin without any modification to core
:) The existing android storage plugin is in cordova-labs#plugins. I think
the right move would be to update this plugin, post it to the registry, and
tell people about it?
On Thu, Sep 19, 2013 at 5:03 PM, Joe Bowser bows...@gmail.com wrote:
OK, I tried the tests included with the plugin, and they don't run.
Can someone sanity check this for me? I'm going to try running this
on additional devices, since it could be a weird Cyanogen thing. But
yeah, if other people can try this plugin, that'd be awesome.
On Thu, Sep 19, 2013 at 10:12 AM, Andrew Grieve agri...@chromium.org
wrote:
Tried out my email code, and despite my confidence, it doesn't work :P.
So... Joe - like your plan.
On Thu, Sep 19, 2013 at 12:32 PM, Brian LeRoux b...@brian.io wrote:
yup.
On Thu, Sep 19, 2013 at 5:42 PM, Joe Bowser bows...@gmail.com wrote:
OK, how about we do this:
1. We indicate that we no longer support WebSQL on the docs and we
list out why we don't support it as it currently exists
2. I'll look at the Android plugin that does do SQLite and see if it's
appropriate for Android (if someone could do the same for iOS, that'd
be cool): https://github.com/lite4mobi/Cordova-SQLitePlugin
I think this looks far more promising than any of the hokey bullshit
that we're currently doing, and it has contributors, and it's actually
updated for Cordova 3.0.
On Thu, Sep 19, 2013 at 7:53 AM, Ian Clelland iclell...@chromium.org
wrote:
On Thu, Sep 19, 2013 at 10:38 AM, Joe Bowser bows...@gmail.com
wrote:
OK, here's a crazy concept that I'm going to throw out there.
How about we audit and recommend a third-party plugin and not do
any
more work on this issue.
+1
I don't think there's enough consensus about whether WebSQL even
belongs
in
the web platform for us to be insisting that it be part of Cordova.
I
would
much rather see someone with a real interest in WebSQL be providing
that
functionality. Our job can be to make sure that we aren't getting in
the
way; that we are helping make plugins like that possible.
Ian
Re: Git Push Summary
Just changed it to have a -. On Thu, Sep 19, 2013 at 8:41 PM, Shazron shaz...@gmail.com wrote: Should this be 3.1.0-rc1 instead? On Thu, Sep 19, 2013 at 1:58 PM, lorinb...@apache.org wrote: Updated Tags: refs/tags/3.1.0rc1 [created] 213bb9f4e
Re: 3.1 Release
Thanks Shaz. Do you want to do OSX as well, or should we skip that for this release? On Thu, Sep 19, 2013 at 8:56 PM, Shazron shaz...@gmail.com wrote: ios-deploy stuff a no go so I left it out (check out the issue for the sordid details) :( sorry for the delay, I had other pressing work related stuff. Tested mob-spec on iOS 7 and iOS 6 - it works fine, iOS tagged. Only one failure on iOS 6 - contacts.spec.24. On Thu, Sep 19, 2013 at 10:37 AM, Lorin Beer lorin.beer@gmail.com wrote: I was away a good chunk of yesterday due to a sick wife, getting BB tagged today. Sorry for the delay. On Thu, Sep 19, 2013 at 9:59 AM, Shazron shaz...@gmail.com wrote: Sorry for the iOS release guys I'm getting it out today On Thu, Sep 19, 2013 at 8:00 AM, Michal Mocny mmo...@chromium.org wrote: Specifically, I think the section Branch Tag RC1 for Platform Repositories On Thu, Sep 19, 2013 at 7:59 AM, Michal Mocny mmo...@chromium.org wrote: I think its this one: http://wiki.apache.org/cordova/CuttingReleases On Thu, Sep 19, 2013 at 7:52 AM, Jeffrey Heifetz jheif...@blackberry.comwrote: I can take the responsibility of tagging BlackBerry. Could you send me the wiki with instructions ? From: Andrew Grieve agri...@chromium.orgmailto: agri...@chromium.org Date: Thursday, 19 September, 2013 10:40 AM To: dev dev@cordova.apache.orgmailto:dev@cordova.apache.org, Jeffrey Heifetz jheif...@blackberry.commailto:jheif...@blackberry.com Subject: Re: 3.1 Release +Jeffrey - maybe you could take on the BlackBerry component for this release? On Thu, Sep 19, 2013 at 10:00 AM, Michael Brooks mich...@michaelbrooks.camailto:mich...@michaelbrooks.ca wrote: Once the platforms are tagged, I can handle the docs. I'll need to review our release process and see how the docs can best abide by them. On Wed, Sep 18, 2013 at 1:34 PM, Andrew Grieve agri...@chromium.org mailto:agri...@chromium.org wrote: Shaz - Thanks for the update :). If iOS is the last one then I'd say let's go without, but maybe keep at it until we get BB tagged? (just my opinion) Heading home now - anyone know if Lorin is away or not? On Wed, Sep 18, 2013 at 3:35 PM, Shazron shaz...@gmail.com mailto: shaz...@gmail.com wrote: When i mean ios-deploy still works, it _installs_ it on the device, but does _not_ run it. On Wed, Sep 18, 2013 at 12:31 PM, Shazron shaz...@gmail.com mailto: shaz...@gmail.com wrote: I'm 99% done with iOS specific fixes. One last one I'm trying to do is ios-deploy with lldb: https://issues.apache.org/jira/browse/CB-4804 This means if I don't get this fix in, we _can_ deploy from the command line using ios-deploy _but_ we can't attach to the debugger. Will that be acceptable you think? On Wed, Sep 18, 2013 at 12:07 PM, Andrew Grieve agri...@chromium.orgmailto:agri...@chromium.org wrote: Ping Lorin Shaz. On Wed, Sep 18, 2013 at 2:19 AM, Steven Gill stevengil...@gmail.commailto:stevengil...@gmail.com wrote: FFOS will be tagged tomorrow. I have a few changes I am going to get in tomorrow before tagging but it will be good to go very soon! With FFOS, Only two plugins have been ported so far (vibration and device). We are going to continue to add firefoxos support to plugins post release. I don't think we should start officially promoting support for FFOS until we have more plugins. For 3.1, it will be available for users to try out, test, give feedback, etc. Cheers, -Steve On Tue, Sep 17, 2013 at 7:38 PM, Andrew Grieve agri...@chromium.orgmailto:agri...@chromium.org wrote: Thanks Jesse! Great work on being on top of things. If changes were done in plugin repos, then those aren't a part of this release anyways and will be picked up by the RELEASENOTES.md within the plugin repos on the next plugins release. I think it's up to you if you want to start writing RELEASENOTES.md for WP7+8. My thinking was just that doing so would make release announcements easier. Since WP7 and WP8 are in the same repo, does it make sense to have different subtasks for their taggings? If so, I'll add it to the template, if not, maybe I'll just change WP8 to say WP7+WP8? WDYT? Shaz - I see you're still
Re: 3.1 Release
Lets skip it, it's unchanged On Thursday, September 19, 2013, Andrew Grieve wrote: Thanks Shaz. Do you want to do OSX as well, or should we skip that for this release? On Thu, Sep 19, 2013 at 8:56 PM, Shazron shaz...@gmail.com wrote: ios-deploy stuff a no go so I left it out (check out the issue for the sordid details) :( sorry for the delay, I had other pressing work related stuff. Tested mob-spec on iOS 7 and iOS 6 - it works fine, iOS tagged. Only one failure on iOS 6 - contacts.spec.24. On Thu, Sep 19, 2013 at 10:37 AM, Lorin Beer lorin.beer@gmail.com wrote: I was away a good chunk of yesterday due to a sick wife, getting BB tagged today. Sorry for the delay. On Thu, Sep 19, 2013 at 9:59 AM, Shazron shaz...@gmail.com wrote: Sorry for the iOS release guys I'm getting it out today On Thu, Sep 19, 2013 at 8:00 AM, Michal Mocny mmo...@chromium.org wrote: Specifically, I think the section Branch Tag RC1 for Platform Repositories On Thu, Sep 19, 2013 at 7:59 AM, Michal Mocny mmo...@chromium.org wrote: I think its this one: http://wiki.apache.org/cordova/CuttingReleases On Thu, Sep 19, 2013 at 7:52 AM, Jeffrey Heifetz jheif...@blackberry.comwrote: I can take the responsibility of tagging BlackBerry. Could you send me the wiki with instructions ? From: Andrew Grieve agri...@chromium.orgmailto: agri...@chromium.org Date: Thursday, 19 September, 2013 10:40 AM To: dev dev@cordova.apache.orgmailto:dev@cordova.apache.org , Jeffrey Heifetz jheif...@blackberry.commailto:jheif...@blackberry.com Subject: Re: 3.1 Release +Jeffrey - maybe you could take on the BlackBerry component for this release? On Thu, Sep 19, 2013 at 10:00 AM, Michael Brooks mich...@michaelbrooks.camailto:mich...@michaelbrooks.ca wrote: Once the platforms are tagged, I can handle the docs. I'll need to review our release process and see how the docs can best abide by them. On Wed, Sep 18, 2013 at 1:34 PM, Andrew Grieve agri...@chromium.org mailto:agri...@chromium.org wrote: Shaz - Thanks for the update :). If iOS is the last one then I'd say
Re: 3.1 Release
Sounds good. So - here's what I'm thinking for next steps: Friday: - Remove core from plugin IDs - Remove URLs from dependency tags - Do a plugins release - Do a plugman release - Do a CLI release, but don't tag it as latest, tag it as rc instead. This will cause it to be installed only if you type npm install cordova@rc - Add cordova platform update instructions to the upgrade guides within the docs - Upload RC1 of cordova-docs - Write blog post about the availability of the RC1. Tweet it. Next Thursday: - If everything seems fine with RC1, release 3.1.0 final. Sound good? Michael: I noticed that the launch bug I created is missing any subtasks for cordova-docs (whoops!). Also - in the current CuttingReleases page, we don't actually say that the docs branch should be created until once we're ready to launch final. I think this is wrong, but wanted to know what your thoughts are for it. I'm thinking: - cordova-docs should have a release branch created as soon as the RCs of the platforms are tagged - I don't think there's much value in having an RC tag for the docs, since they tend to change a bunch post RC1 of platforms - cordova-docs 3.1.0-rc1 should be uploaded to the website, but not be made the default. We can keep re-uploading it as changes are made. - Once we're ready for the final release, we delete the rc1 version, upload the non-rc version, and make that the default. Does this sound good? On Thu, Sep 19, 2013 at 11:04 PM, Shazron shaz...@gmail.com wrote: Lets skip it, it's unchanged On Thursday, September 19, 2013, Andrew Grieve wrote: Thanks Shaz. Do you want to do OSX as well, or should we skip that for this release? On Thu, Sep 19, 2013 at 8:56 PM, Shazron shaz...@gmail.com wrote: ios-deploy stuff a no go so I left it out (check out the issue for the sordid details) :( sorry for the delay, I had other pressing work related stuff. Tested mob-spec on iOS 7 and iOS 6 - it works fine, iOS tagged. Only one failure on iOS 6 - contacts.spec.24. On Thu, Sep 19, 2013 at 10:37 AM, Lorin Beer lorin.beer@gmail.com wrote: I was away a good chunk of yesterday due to a sick wife, getting BB tagged today. Sorry for the delay. On Thu, Sep 19, 2013 at 9:59 AM, Shazron shaz...@gmail.com wrote: Sorry for the iOS release guys I'm getting it out today On Thu, Sep 19, 2013 at 8:00 AM, Michal Mocny mmo...@chromium.org wrote: Specifically, I think the section Branch Tag RC1 for Platform Repositories On Thu, Sep 19, 2013 at 7:59 AM, Michal Mocny mmo...@chromium.org wrote: I think its this one: http://wiki.apache.org/cordova/CuttingReleases On Thu, Sep 19, 2013 at 7:52 AM, Jeffrey Heifetz jheif...@blackberry.comwrote: I can take the responsibility of tagging BlackBerry. Could you send me the wiki with instructions ? From: Andrew Grieve agri...@chromium.orgmailto: agri...@chromium.org Date: Thursday, 19 September, 2013 10:40 AM To: dev dev@cordova.apache.orgmailto:dev@cordova.apache.org , Jeffrey Heifetz jheif...@blackberry.commailto: jheif...@blackberry.com Subject: Re: 3.1 Release +Jeffrey - maybe you could take on the BlackBerry component for this release? On Thu, Sep 19, 2013 at 10:00 AM, Michael Brooks mich...@michaelbrooks.camailto:mich...@michaelbrooks.ca wrote: Once the platforms are tagged, I can handle the docs. I'll need to review our release process and see how the docs can best abide by them. On Wed, Sep 18, 2013 at 1:34 PM, Andrew Grieve agri...@chromium.org mailto:agri...@chromium.org wrote: Shaz - Thanks for the update :). If iOS is the last one then I'd say
Re: Plugin Generator
This is great. I think we have it in our backlog to have something like `plugman create ...` and thusly `cordova plugin create ...`. Would you be up for contributing back to the cordova tools? On Thu, Sep 19, 2013 at 9:31 PM, Shazron shaz...@gmail.com wrote: Heh ;) I was waiting for patches welcome :) On Thu, Sep 19, 2013 at 12:29 PM, Lucas Holmquist lholm...@redhat.com wrote: version 0.0.1 :) On Sep 19, 2013, at 3:28 PM, Shazron shaz...@gmail.com wrote: Awesome! Any reason not to use js-module instead? On Thu, Sep 19, 2013 at 12:22 PM, Lucas Holmquist lholm...@redhat.com wrote: I was looking for something to help me create a plugin but i didn't see anything, so i created a yeoman generator: https://npmjs.org/package/generator-cordova-plugin here is version 0.0.1
