Re: [DISCUSS] cordova-ios-4.x release (for real)
Please label issues "cordova-ios-4.0.1" for the upcoming patch release like so: https://issues.apache.org/jira/browse/CB-10162 On Tue, Dec 8, 2015 at 5:19 AM, Shazron wrote: > I removed the root node_modules in cordova-ios, and re-created the > archive. They are re-published at: > https://dist.apache.org/repos/dist/dev/cordova/CB-10147 > > > On Tue, Dec 8, 2015 at 5:12 AM, Carlos Santana wrote: >> Wow good find ! >> >> I some times do a rm -r node_modules then npm install before running coho >> create-archive, but not all the time. So I can see this happening >> >> I agree we should automate this in coho. >> >> The coho create-archive should clean node_modules for repo ios only, or also >> do rm and then an npm install --production for each repo in the specific way >> for each repo >> >> - Carlos >> @csantanapr >> >>> On Dec 8, 2015, at 7:55 AM, Shazron wrote: >>> >>> Mystery solved. >>> >>> cordova-ios has devDependencies in the root package.josn. This will >>> install a "node_modules" in the root, which npm pack will ignore and >>> git will as well (since it is in the .gitignore). However, even though >>> it is not packed, it will affect 'npm pack', as I will explain... >>> >>> I hadn't run "npm install" in a while, and I had q, nopt, and glob in >>> there from a previous "bundledDependencies": >>> https://github.com/apache/cordova-ios/commit/a56cb22ee3f60f9c71abcf200aec1e96e324e343 >>> >>> So when I ran 'npm pack', this affected the packing of nested >>> node_modules because at the root those modules where there. I think. >>> >>> If I ran a fresh "npm install" at the root, 'npm pack` seems fine (the >>> missing folders are there) but because of this weird behaviour I think >>> we should run `npm pack` without the root `node_modules`. >>> >>> Any other explanation on what's going on, and what's the best way to >>> fix this? (npm install, then npm pack? or remove root node_modules?). >>> I'd rather find an "automated" way through coho rather than do this >>> manually just in case it happens again. Removing root node_modules >>> won't work in the generic case since cordova-android has >>> bundledDependencies. >>> >>> I tried using .npmignore and it didn't work (at least for npm@2.11.3) >>> On Tue, Dec 8, 2015 at 4:10 AM, Shazron wrote: A regular `tar -cvzf` the missing folders are included, it's just `npm pack` not liking my local repo for some reason. > On Tue, Dec 8, 2015 at 3:51 AM, Shazron wrote: > This is certainly bizarre. > > I've verified that my local repo copy of the cordova-ios 4.0.x branch > does have those modules, then ran "npm pack" on the repo folder (which > coho create-archive calls): > > > [cordova-ios (4.0.x)]$ npm pack --verbose > npm info it worked if it ends with ok > npm verb cli [ '/Users/shazron/.nvm/versions/node/v0.12.7/bin/node', > npm verb cli '/Users/shazron/.nvm/versions/node/v0.12.7/bin/npm', > npm verb cli 'pack', > npm verb cli '--verbose' ] > npm info using npm@2.11.3 > npm info using node@v0.12.7 > npm verb cache add spec . > npm verb addLocalDirectory > /Users/shazron/.npm/cordova-ios/4.0.0/package.tgz not in flight; > packing > npm verb tar pack [ '/Users/shazron/.npm/cordova-ios/4.0.0/package.tgz', > npm verb tar pack '/Users/shazron/Documents/git/apache/cordova-ios' ] > npm verb tarball /Users/shazron/.npm/cordova-ios/4.0.0/package.tgz > npm verb folder /Users/shazron/Documents/git/apache/cordova-ios > npm info prepublish cordova-ios@4.0.0 > npm verb addLocalTarball adding from inside cache > /Users/shazron/.npm/cordova-ios/4.0.0/package.tgz > npm verb afterAdd > /Users/shazron/.npm/cordova-ios/4.0.0/package/package.json not in > flight; writing > npm verb afterAdd > /Users/shazron/.npm/cordova-ios/4.0.0/package/package.json written > cordova-ios-4.0.0.tgz > npm verb exit [ 0, true ] > npm info ok > --- > > After expanding the .tgz I found that the modules mentioned are *not* > there, but I don't know why. > > However, when I check out a fresh copy of cordova-ios and "npm pack" > the 4.0.x branch there, the modules *are* there in the .tgz! Chalk > this one up to the C-Files (cue X-Files theme). > > > >> On Mon, Dec 7, 2015 at 6:05 PM, Carlos Santana >> wrote: >> Currently finding a discrepancy when recreating the archive >> >> The tgz dist/ [1] is missing 3 node modules, they are located in git [2] >> Running the command coho create-archive --tag 4.0.0 -r ios --dest >> test-ios4/ >> I ran with npm@2.11.3 and npm@3.3.12 and was able to get all three in >> expected location >> >> bin/node_modules/cordova-common/node_modules/glob >> bin/node_modules/cordova-common/node_modules/q >> bin/node_modules/ios-sim/node_modules/nopt >> >> [1]: >> https://dist.apache.org/repos/dist/dev/cordo
Re: [DISCUSS] cordova-ios-4.x release (for real)
I removed the root node_modules in cordova-ios, and re-created the archive. They are re-published at: https://dist.apache.org/repos/dist/dev/cordova/CB-10147 On Tue, Dec 8, 2015 at 5:12 AM, Carlos Santana wrote: > Wow good find ! > > I some times do a rm -r node_modules then npm install before running coho > create-archive, but not all the time. So I can see this happening > > I agree we should automate this in coho. > > The coho create-archive should clean node_modules for repo ios only, or also > do rm and then an npm install --production for each repo in the specific way > for each repo > > - Carlos > @csantanapr > >> On Dec 8, 2015, at 7:55 AM, Shazron wrote: >> >> Mystery solved. >> >> cordova-ios has devDependencies in the root package.josn. This will >> install a "node_modules" in the root, which npm pack will ignore and >> git will as well (since it is in the .gitignore). However, even though >> it is not packed, it will affect 'npm pack', as I will explain... >> >> I hadn't run "npm install" in a while, and I had q, nopt, and glob in >> there from a previous "bundledDependencies": >> https://github.com/apache/cordova-ios/commit/a56cb22ee3f60f9c71abcf200aec1e96e324e343 >> >> So when I ran 'npm pack', this affected the packing of nested >> node_modules because at the root those modules where there. I think. >> >> If I ran a fresh "npm install" at the root, 'npm pack` seems fine (the >> missing folders are there) but because of this weird behaviour I think >> we should run `npm pack` without the root `node_modules`. >> >> Any other explanation on what's going on, and what's the best way to >> fix this? (npm install, then npm pack? or remove root node_modules?). >> I'd rather find an "automated" way through coho rather than do this >> manually just in case it happens again. Removing root node_modules >> won't work in the generic case since cordova-android has >> bundledDependencies. >> >> I tried using .npmignore and it didn't work (at least for npm@2.11.3) >> >>> On Tue, Dec 8, 2015 at 4:10 AM, Shazron wrote: >>> A regular `tar -cvzf` the missing folders are included, it's just `npm >>> pack` not liking my local repo for some reason. >>> On Tue, Dec 8, 2015 at 3:51 AM, Shazron wrote: This is certainly bizarre. I've verified that my local repo copy of the cordova-ios 4.0.x branch does have those modules, then ran "npm pack" on the repo folder (which coho create-archive calls): [cordova-ios (4.0.x)]$ npm pack --verbose npm info it worked if it ends with ok npm verb cli [ '/Users/shazron/.nvm/versions/node/v0.12.7/bin/node', npm verb cli '/Users/shazron/.nvm/versions/node/v0.12.7/bin/npm', npm verb cli 'pack', npm verb cli '--verbose' ] npm info using npm@2.11.3 npm info using node@v0.12.7 npm verb cache add spec . npm verb addLocalDirectory /Users/shazron/.npm/cordova-ios/4.0.0/package.tgz not in flight; packing npm verb tar pack [ '/Users/shazron/.npm/cordova-ios/4.0.0/package.tgz', npm verb tar pack '/Users/shazron/Documents/git/apache/cordova-ios' ] npm verb tarball /Users/shazron/.npm/cordova-ios/4.0.0/package.tgz npm verb folder /Users/shazron/Documents/git/apache/cordova-ios npm info prepublish cordova-ios@4.0.0 npm verb addLocalTarball adding from inside cache /Users/shazron/.npm/cordova-ios/4.0.0/package.tgz npm verb afterAdd /Users/shazron/.npm/cordova-ios/4.0.0/package/package.json not in flight; writing npm verb afterAdd /Users/shazron/.npm/cordova-ios/4.0.0/package/package.json written cordova-ios-4.0.0.tgz npm verb exit [ 0, true ] npm info ok --- After expanding the .tgz I found that the modules mentioned are *not* there, but I don't know why. However, when I check out a fresh copy of cordova-ios and "npm pack" the 4.0.x branch there, the modules *are* there in the .tgz! Chalk this one up to the C-Files (cue X-Files theme). > On Mon, Dec 7, 2015 at 6:05 PM, Carlos Santana > wrote: > Currently finding a discrepancy when recreating the archive > > The tgz dist/ [1] is missing 3 node modules, they are located in git [2] > Running the command coho create-archive --tag 4.0.0 -r ios --dest > test-ios4/ > I ran with npm@2.11.3 and npm@3.3.12 and was able to get all three in > expected location > > bin/node_modules/cordova-common/node_modules/glob > bin/node_modules/cordova-common/node_modules/q > bin/node_modules/ios-sim/node_modules/nopt > > [1]: > https://dist.apache.org/repos/dist/dev/cordova/CB-10147/cordova-ios-4.0.0.tgz > [2]: https://github.com/apache/cordova-ios/tree/4.0.0/bin/node_modules > > > > >> On Mon, Dec 7, 2015 at 7:12 PM Carlos Santana >> wrote: >> >> Currently working on it... >> >> - Carlos >> @csantanapr >> >
Re: [DISCUSS] cordova-ios-4.x release (for real)
Wow good find ! I some times do a rm -r node_modules then npm install before running coho create-archive, but not all the time. So I can see this happening I agree we should automate this in coho. The coho create-archive should clean node_modules for repo ios only, or also do rm and then an npm install --production for each repo in the specific way for each repo - Carlos @csantanapr > On Dec 8, 2015, at 7:55 AM, Shazron wrote: > > Mystery solved. > > cordova-ios has devDependencies in the root package.josn. This will > install a "node_modules" in the root, which npm pack will ignore and > git will as well (since it is in the .gitignore). However, even though > it is not packed, it will affect 'npm pack', as I will explain... > > I hadn't run "npm install" in a while, and I had q, nopt, and glob in > there from a previous "bundledDependencies": > https://github.com/apache/cordova-ios/commit/a56cb22ee3f60f9c71abcf200aec1e96e324e343 > > So when I ran 'npm pack', this affected the packing of nested > node_modules because at the root those modules where there. I think. > > If I ran a fresh "npm install" at the root, 'npm pack` seems fine (the > missing folders are there) but because of this weird behaviour I think > we should run `npm pack` without the root `node_modules`. > > Any other explanation on what's going on, and what's the best way to > fix this? (npm install, then npm pack? or remove root node_modules?). > I'd rather find an "automated" way through coho rather than do this > manually just in case it happens again. Removing root node_modules > won't work in the generic case since cordova-android has > bundledDependencies. > > I tried using .npmignore and it didn't work (at least for npm@2.11.3) > >> On Tue, Dec 8, 2015 at 4:10 AM, Shazron wrote: >> A regular `tar -cvzf` the missing folders are included, it's just `npm >> pack` not liking my local repo for some reason. >> >>> On Tue, Dec 8, 2015 at 3:51 AM, Shazron wrote: >>> This is certainly bizarre. >>> >>> I've verified that my local repo copy of the cordova-ios 4.0.x branch >>> does have those modules, then ran "npm pack" on the repo folder (which >>> coho create-archive calls): >>> >>> >>> [cordova-ios (4.0.x)]$ npm pack --verbose >>> npm info it worked if it ends with ok >>> npm verb cli [ '/Users/shazron/.nvm/versions/node/v0.12.7/bin/node', >>> npm verb cli '/Users/shazron/.nvm/versions/node/v0.12.7/bin/npm', >>> npm verb cli 'pack', >>> npm verb cli '--verbose' ] >>> npm info using npm@2.11.3 >>> npm info using node@v0.12.7 >>> npm verb cache add spec . >>> npm verb addLocalDirectory >>> /Users/shazron/.npm/cordova-ios/4.0.0/package.tgz not in flight; >>> packing >>> npm verb tar pack [ '/Users/shazron/.npm/cordova-ios/4.0.0/package.tgz', >>> npm verb tar pack '/Users/shazron/Documents/git/apache/cordova-ios' ] >>> npm verb tarball /Users/shazron/.npm/cordova-ios/4.0.0/package.tgz >>> npm verb folder /Users/shazron/Documents/git/apache/cordova-ios >>> npm info prepublish cordova-ios@4.0.0 >>> npm verb addLocalTarball adding from inside cache >>> /Users/shazron/.npm/cordova-ios/4.0.0/package.tgz >>> npm verb afterAdd >>> /Users/shazron/.npm/cordova-ios/4.0.0/package/package.json not in >>> flight; writing >>> npm verb afterAdd >>> /Users/shazron/.npm/cordova-ios/4.0.0/package/package.json written >>> cordova-ios-4.0.0.tgz >>> npm verb exit [ 0, true ] >>> npm info ok >>> --- >>> >>> After expanding the .tgz I found that the modules mentioned are *not* >>> there, but I don't know why. >>> >>> However, when I check out a fresh copy of cordova-ios and "npm pack" >>> the 4.0.x branch there, the modules *are* there in the .tgz! Chalk >>> this one up to the C-Files (cue X-Files theme). >>> >>> >>> On Mon, Dec 7, 2015 at 6:05 PM, Carlos Santana wrote: Currently finding a discrepancy when recreating the archive The tgz dist/ [1] is missing 3 node modules, they are located in git [2] Running the command coho create-archive --tag 4.0.0 -r ios --dest test-ios4/ I ran with npm@2.11.3 and npm@3.3.12 and was able to get all three in expected location bin/node_modules/cordova-common/node_modules/glob bin/node_modules/cordova-common/node_modules/q bin/node_modules/ios-sim/node_modules/nopt [1]: https://dist.apache.org/repos/dist/dev/cordova/CB-10147/cordova-ios-4.0.0.tgz [2]: https://github.com/apache/cordova-ios/tree/4.0.0/bin/node_modules > On Mon, Dec 7, 2015 at 7:12 PM Carlos Santana > wrote: > > Currently working on it... > > - Carlos > @csantanapr > >> On Dec 7, 2015, at 6:50 PM, Steven Gill wrote: >> >> both ios@4 and cordova-plugin-wkwebviewengine need 1 more vote. Someone >> step up so Shaz can wrap up the vote threads and publish these! >> >>> On Fri, Dec 4, 2015 at 2:07 PM, Carlos Santana > wrote: >>> >>> +1 >>>
Re: [DISCUSS] cordova-ios-4.x release (for real)
Mystery solved. cordova-ios has devDependencies in the root package.josn. This will install a "node_modules" in the root, which npm pack will ignore and git will as well (since it is in the .gitignore). However, even though it is not packed, it will affect 'npm pack', as I will explain... I hadn't run "npm install" in a while, and I had q, nopt, and glob in there from a previous "bundledDependencies": https://github.com/apache/cordova-ios/commit/a56cb22ee3f60f9c71abcf200aec1e96e324e343 So when I ran 'npm pack', this affected the packing of nested node_modules because at the root those modules where there. I think. If I ran a fresh "npm install" at the root, 'npm pack` seems fine (the missing folders are there) but because of this weird behaviour I think we should run `npm pack` without the root `node_modules`. Any other explanation on what's going on, and what's the best way to fix this? (npm install, then npm pack? or remove root node_modules?). I'd rather find an "automated" way through coho rather than do this manually just in case it happens again. Removing root node_modules won't work in the generic case since cordova-android has bundledDependencies. I tried using .npmignore and it didn't work (at least for npm@2.11.3) On Tue, Dec 8, 2015 at 4:10 AM, Shazron wrote: > A regular `tar -cvzf` the missing folders are included, it's just `npm > pack` not liking my local repo for some reason. > > On Tue, Dec 8, 2015 at 3:51 AM, Shazron wrote: >> This is certainly bizarre. >> >> I've verified that my local repo copy of the cordova-ios 4.0.x branch >> does have those modules, then ran "npm pack" on the repo folder (which >> coho create-archive calls): >> >> >> [cordova-ios (4.0.x)]$ npm pack --verbose >> npm info it worked if it ends with ok >> npm verb cli [ '/Users/shazron/.nvm/versions/node/v0.12.7/bin/node', >> npm verb cli '/Users/shazron/.nvm/versions/node/v0.12.7/bin/npm', >> npm verb cli 'pack', >> npm verb cli '--verbose' ] >> npm info using npm@2.11.3 >> npm info using node@v0.12.7 >> npm verb cache add spec . >> npm verb addLocalDirectory >> /Users/shazron/.npm/cordova-ios/4.0.0/package.tgz not in flight; >> packing >> npm verb tar pack [ '/Users/shazron/.npm/cordova-ios/4.0.0/package.tgz', >> npm verb tar pack '/Users/shazron/Documents/git/apache/cordova-ios' ] >> npm verb tarball /Users/shazron/.npm/cordova-ios/4.0.0/package.tgz >> npm verb folder /Users/shazron/Documents/git/apache/cordova-ios >> npm info prepublish cordova-ios@4.0.0 >> npm verb addLocalTarball adding from inside cache >> /Users/shazron/.npm/cordova-ios/4.0.0/package.tgz >> npm verb afterAdd >> /Users/shazron/.npm/cordova-ios/4.0.0/package/package.json not in >> flight; writing >> npm verb afterAdd >> /Users/shazron/.npm/cordova-ios/4.0.0/package/package.json written >> cordova-ios-4.0.0.tgz >> npm verb exit [ 0, true ] >> npm info ok >> --- >> >> After expanding the .tgz I found that the modules mentioned are *not* >> there, but I don't know why. >> >> However, when I check out a fresh copy of cordova-ios and "npm pack" >> the 4.0.x branch there, the modules *are* there in the .tgz! Chalk >> this one up to the C-Files (cue X-Files theme). >> >> >> >> On Mon, Dec 7, 2015 at 6:05 PM, Carlos Santana wrote: >>> Currently finding a discrepancy when recreating the archive >>> >>> The tgz dist/ [1] is missing 3 node modules, they are located in git [2] >>> Running the command coho create-archive --tag 4.0.0 -r ios --dest test-ios4/ >>> I ran with npm@2.11.3 and npm@3.3.12 and was able to get all three in >>> expected location >>> >>> bin/node_modules/cordova-common/node_modules/glob >>> bin/node_modules/cordova-common/node_modules/q >>> bin/node_modules/ios-sim/node_modules/nopt >>> >>> [1]: >>> https://dist.apache.org/repos/dist/dev/cordova/CB-10147/cordova-ios-4.0.0.tgz >>> [2]: https://github.com/apache/cordova-ios/tree/4.0.0/bin/node_modules >>> >>> >>> >>> >>> On Mon, Dec 7, 2015 at 7:12 PM Carlos Santana wrote: >>> Currently working on it... - Carlos @csantanapr > On Dec 7, 2015, at 6:50 PM, Steven Gill wrote: > > both ios@4 and cordova-plugin-wkwebviewengine need 1 more vote. Someone > step up so Shaz can wrap up the vote threads and publish these! > >> On Fri, Dec 4, 2015 at 2:07 PM, Carlos Santana wrote: >> >> +1 >> >>> On Fri, Dec 4, 2015 at 3:07 PM Shazron wrote: >>> >>> After working out some bridge improvements and fixing some Platform >>> API bugs and testing, I believe it's ready. I'll start a [VOTE] thread >>> soon. >>> >>> On Thu, Dec 3, 2015 at 5:19 PM, Carlos Santana >>> wrote: +1 let's move forward this items with WKWebview I don't see holding up >>> the platform. Don't see any changes going on the platform, if any they will go into >> the pluggable webview plugin or creating new plugin to handle. > On Wed,
Re: [DISCUSS] cordova-ios-4.x release (for real)
Thanks for the update Did you said you tried a new directory via clone What about updating to latest npm@2.x ? On Tue, Dec 8, 2015 at 7:16 AM Shazron wrote: > A regular `tar -cvzf` the missing folders are included, it's just `npm > pack` not liking my local repo for some reason. > > On Tue, Dec 8, 2015 at 3:51 AM, Shazron wrote: > > This is certainly bizarre. > > > > I've verified that my local repo copy of the cordova-ios 4.0.x branch > > does have those modules, then ran "npm pack" on the repo folder (which > > coho create-archive calls): > > > > > > [cordova-ios (4.0.x)]$ npm pack --verbose > > npm info it worked if it ends with ok > > npm verb cli [ '/Users/shazron/.nvm/versions/node/v0.12.7/bin/node', > > npm verb cli '/Users/shazron/.nvm/versions/node/v0.12.7/bin/npm', > > npm verb cli 'pack', > > npm verb cli '--verbose' ] > > npm info using npm@2.11.3 > > npm info using node@v0.12.7 > > npm verb cache add spec . > > npm verb addLocalDirectory > > /Users/shazron/.npm/cordova-ios/4.0.0/package.tgz not in flight; > > packing > > npm verb tar pack [ '/Users/shazron/.npm/cordova-ios/4.0.0/package.tgz', > > npm verb tar pack '/Users/shazron/Documents/git/apache/cordova-ios' ] > > npm verb tarball /Users/shazron/.npm/cordova-ios/4.0.0/package.tgz > > npm verb folder /Users/shazron/Documents/git/apache/cordova-ios > > npm info prepublish cordova-ios@4.0.0 > > npm verb addLocalTarball adding from inside cache > > /Users/shazron/.npm/cordova-ios/4.0.0/package.tgz > > npm verb afterAdd > > /Users/shazron/.npm/cordova-ios/4.0.0/package/package.json not in > > flight; writing > > npm verb afterAdd > > /Users/shazron/.npm/cordova-ios/4.0.0/package/package.json written > > cordova-ios-4.0.0.tgz > > npm verb exit [ 0, true ] > > npm info ok > > --- > > > > After expanding the .tgz I found that the modules mentioned are *not* > > there, but I don't know why. > > > > However, when I check out a fresh copy of cordova-ios and "npm pack" > > the 4.0.x branch there, the modules *are* there in the .tgz! Chalk > > this one up to the C-Files (cue X-Files theme). > > > > > > > > On Mon, Dec 7, 2015 at 6:05 PM, Carlos Santana > wrote: > >> Currently finding a discrepancy when recreating the archive > >> > >> The tgz dist/ [1] is missing 3 node modules, they are located in git [2] > >> Running the command coho create-archive --tag 4.0.0 -r ios --dest > test-ios4/ > >> I ran with npm@2.11.3 and npm@3.3.12 and was able to get all three in > >> expected location > >> > >> bin/node_modules/cordova-common/node_modules/glob > >> bin/node_modules/cordova-common/node_modules/q > >> bin/node_modules/ios-sim/node_modules/nopt > >> > >> [1]: > >> > https://dist.apache.org/repos/dist/dev/cordova/CB-10147/cordova-ios-4.0.0.tgz > >> [2]: https://github.com/apache/cordova-ios/tree/4.0.0/bin/node_modules > >> > >> > >> > >> > >> On Mon, Dec 7, 2015 at 7:12 PM Carlos Santana > wrote: > >> > >>> Currently working on it... > >>> > >>> - Carlos > >>> @csantanapr > >>> > >>> > On Dec 7, 2015, at 6:50 PM, Steven Gill > wrote: > >>> > > >>> > both ios@4 and cordova-plugin-wkwebviewengine need 1 more vote. > Someone > >>> > step up so Shaz can wrap up the vote threads and publish these! > >>> > > >>> >> On Fri, Dec 4, 2015 at 2:07 PM, Carlos Santana < > csantan...@gmail.com> > >>> wrote: > >>> >> > >>> >> +1 > >>> >> > >>> >>> On Fri, Dec 4, 2015 at 3:07 PM Shazron wrote: > >>> >>> > >>> >>> After working out some bridge improvements and fixing some Platform > >>> >>> API bugs and testing, I believe it's ready. I'll start a [VOTE] > thread > >>> >>> soon. > >>> >>> > >>> >>> On Thu, Dec 3, 2015 at 5:19 PM, Carlos Santana < > csantan...@gmail.com> > >>> >>> wrote: > >>> +1 let's move forward this items with WKWebview I don't see > holding up > >>> >>> the > >>> platform. > >>> > >>> Don't see any changes going on the platform, if any they will go > into > >>> >> the > >>> pluggable webview plugin or creating new plugin to handle. > >>> > On Wed, Dec 2, 2015 at 8:40 PM Shazron > wrote: > >>> > > >>> > Regarding Platform API, Vladimir Kotikov and Sergey Grebnov > agree in > >>> > the PR comments that the changes can go in to cordova-ios-4.x: > >>> > https://github.com/apache/cordova-ios/pull/176 > >>> > > >>> >> On Wed, Dec 2, 2015 at 5:38 PM, Shazron > wrote: > >>> >> Also, check footnote 3 above. > >>> >> > >>> >> Yes, WebKit defines window.openDatabase but it doesn't do > anything. > >>> >> Not sure why their tests didn't catch this... (see footnote for > the > >>> >> bug) > >>> >> > >>> >> With CSP off to rule things out: > >>> >> XHR to yourself of course works, but doesn't really make sense > for > >>> >> real-world use. XHR to a sibling file, parent file, or any child > >>> >> file > >>> >> results in the error ""Cross origin requests are only supported > for > >>> >> HTTP”. > >>> >> > >>> >> To illustrate: > >>> >>
Re: [DISCUSS] cordova-ios-4.x release (for real)
A regular `tar -cvzf` the missing folders are included, it's just `npm pack` not liking my local repo for some reason. On Tue, Dec 8, 2015 at 3:51 AM, Shazron wrote: > This is certainly bizarre. > > I've verified that my local repo copy of the cordova-ios 4.0.x branch > does have those modules, then ran "npm pack" on the repo folder (which > coho create-archive calls): > > > [cordova-ios (4.0.x)]$ npm pack --verbose > npm info it worked if it ends with ok > npm verb cli [ '/Users/shazron/.nvm/versions/node/v0.12.7/bin/node', > npm verb cli '/Users/shazron/.nvm/versions/node/v0.12.7/bin/npm', > npm verb cli 'pack', > npm verb cli '--verbose' ] > npm info using npm@2.11.3 > npm info using node@v0.12.7 > npm verb cache add spec . > npm verb addLocalDirectory > /Users/shazron/.npm/cordova-ios/4.0.0/package.tgz not in flight; > packing > npm verb tar pack [ '/Users/shazron/.npm/cordova-ios/4.0.0/package.tgz', > npm verb tar pack '/Users/shazron/Documents/git/apache/cordova-ios' ] > npm verb tarball /Users/shazron/.npm/cordova-ios/4.0.0/package.tgz > npm verb folder /Users/shazron/Documents/git/apache/cordova-ios > npm info prepublish cordova-ios@4.0.0 > npm verb addLocalTarball adding from inside cache > /Users/shazron/.npm/cordova-ios/4.0.0/package.tgz > npm verb afterAdd > /Users/shazron/.npm/cordova-ios/4.0.0/package/package.json not in > flight; writing > npm verb afterAdd > /Users/shazron/.npm/cordova-ios/4.0.0/package/package.json written > cordova-ios-4.0.0.tgz > npm verb exit [ 0, true ] > npm info ok > --- > > After expanding the .tgz I found that the modules mentioned are *not* > there, but I don't know why. > > However, when I check out a fresh copy of cordova-ios and "npm pack" > the 4.0.x branch there, the modules *are* there in the .tgz! Chalk > this one up to the C-Files (cue X-Files theme). > > > > On Mon, Dec 7, 2015 at 6:05 PM, Carlos Santana wrote: >> Currently finding a discrepancy when recreating the archive >> >> The tgz dist/ [1] is missing 3 node modules, they are located in git [2] >> Running the command coho create-archive --tag 4.0.0 -r ios --dest test-ios4/ >> I ran with npm@2.11.3 and npm@3.3.12 and was able to get all three in >> expected location >> >> bin/node_modules/cordova-common/node_modules/glob >> bin/node_modules/cordova-common/node_modules/q >> bin/node_modules/ios-sim/node_modules/nopt >> >> [1]: >> https://dist.apache.org/repos/dist/dev/cordova/CB-10147/cordova-ios-4.0.0.tgz >> [2]: https://github.com/apache/cordova-ios/tree/4.0.0/bin/node_modules >> >> >> >> >> On Mon, Dec 7, 2015 at 7:12 PM Carlos Santana wrote: >> >>> Currently working on it... >>> >>> - Carlos >>> @csantanapr >>> >>> > On Dec 7, 2015, at 6:50 PM, Steven Gill wrote: >>> > >>> > both ios@4 and cordova-plugin-wkwebviewengine need 1 more vote. Someone >>> > step up so Shaz can wrap up the vote threads and publish these! >>> > >>> >> On Fri, Dec 4, 2015 at 2:07 PM, Carlos Santana >>> wrote: >>> >> >>> >> +1 >>> >> >>> >>> On Fri, Dec 4, 2015 at 3:07 PM Shazron wrote: >>> >>> >>> >>> After working out some bridge improvements and fixing some Platform >>> >>> API bugs and testing, I believe it's ready. I'll start a [VOTE] thread >>> >>> soon. >>> >>> >>> >>> On Thu, Dec 3, 2015 at 5:19 PM, Carlos Santana >>> >>> wrote: >>> +1 let's move forward this items with WKWebview I don't see holding up >>> >>> the >>> platform. >>> >>> Don't see any changes going on the platform, if any they will go into >>> >> the >>> pluggable webview plugin or creating new plugin to handle. >>> > On Wed, Dec 2, 2015 at 8:40 PM Shazron wrote: >>> > >>> > Regarding Platform API, Vladimir Kotikov and Sergey Grebnov agree in >>> > the PR comments that the changes can go in to cordova-ios-4.x: >>> > https://github.com/apache/cordova-ios/pull/176 >>> > >>> >> On Wed, Dec 2, 2015 at 5:38 PM, Shazron wrote: >>> >> Also, check footnote 3 above. >>> >> >>> >> Yes, WebKit defines window.openDatabase but it doesn't do anything. >>> >> Not sure why their tests didn't catch this... (see footnote for the >>> >> bug) >>> >> >>> >> With CSP off to rule things out: >>> >> XHR to yourself of course works, but doesn't really make sense for >>> >> real-world use. XHR to a sibling file, parent file, or any child >>> >> file >>> >> results in the error ""Cross origin requests are only supported for >>> >> HTTP”. >>> >> >>> >> To illustrate: >>> >> >>> >> | >>> >> parent.xml >>> >> | >>> >> www >>> >> | index.html (file currently loaded) >>> >> | sibling.xml >>> >> | child-folder >>> >> | | child.xml >>> >> >>> >> index.html is the currently loaded file in the WebView. From it, you >>> >> can't load parent.xml, sibling.xml nor child.xml using XHR according >>> >> to my tests. >>> >> >>> >> Regarding *why* we have these storage tests, that is
Re: [DISCUSS] cordova-ios-4.x release (for real)
This is certainly bizarre. I've verified that my local repo copy of the cordova-ios 4.0.x branch does have those modules, then ran "npm pack" on the repo folder (which coho create-archive calls): [cordova-ios (4.0.x)]$ npm pack --verbose npm info it worked if it ends with ok npm verb cli [ '/Users/shazron/.nvm/versions/node/v0.12.7/bin/node', npm verb cli '/Users/shazron/.nvm/versions/node/v0.12.7/bin/npm', npm verb cli 'pack', npm verb cli '--verbose' ] npm info using npm@2.11.3 npm info using node@v0.12.7 npm verb cache add spec . npm verb addLocalDirectory /Users/shazron/.npm/cordova-ios/4.0.0/package.tgz not in flight; packing npm verb tar pack [ '/Users/shazron/.npm/cordova-ios/4.0.0/package.tgz', npm verb tar pack '/Users/shazron/Documents/git/apache/cordova-ios' ] npm verb tarball /Users/shazron/.npm/cordova-ios/4.0.0/package.tgz npm verb folder /Users/shazron/Documents/git/apache/cordova-ios npm info prepublish cordova-ios@4.0.0 npm verb addLocalTarball adding from inside cache /Users/shazron/.npm/cordova-ios/4.0.0/package.tgz npm verb afterAdd /Users/shazron/.npm/cordova-ios/4.0.0/package/package.json not in flight; writing npm verb afterAdd /Users/shazron/.npm/cordova-ios/4.0.0/package/package.json written cordova-ios-4.0.0.tgz npm verb exit [ 0, true ] npm info ok --- After expanding the .tgz I found that the modules mentioned are *not* there, but I don't know why. However, when I check out a fresh copy of cordova-ios and "npm pack" the 4.0.x branch there, the modules *are* there in the .tgz! Chalk this one up to the C-Files (cue X-Files theme). On Mon, Dec 7, 2015 at 6:05 PM, Carlos Santana wrote: > Currently finding a discrepancy when recreating the archive > > The tgz dist/ [1] is missing 3 node modules, they are located in git [2] > Running the command coho create-archive --tag 4.0.0 -r ios --dest test-ios4/ > I ran with npm@2.11.3 and npm@3.3.12 and was able to get all three in > expected location > > bin/node_modules/cordova-common/node_modules/glob > bin/node_modules/cordova-common/node_modules/q > bin/node_modules/ios-sim/node_modules/nopt > > [1]: > https://dist.apache.org/repos/dist/dev/cordova/CB-10147/cordova-ios-4.0.0.tgz > [2]: https://github.com/apache/cordova-ios/tree/4.0.0/bin/node_modules > > > > > On Mon, Dec 7, 2015 at 7:12 PM Carlos Santana wrote: > >> Currently working on it... >> >> - Carlos >> @csantanapr >> >> > On Dec 7, 2015, at 6:50 PM, Steven Gill wrote: >> > >> > both ios@4 and cordova-plugin-wkwebviewengine need 1 more vote. Someone >> > step up so Shaz can wrap up the vote threads and publish these! >> > >> >> On Fri, Dec 4, 2015 at 2:07 PM, Carlos Santana >> wrote: >> >> >> >> +1 >> >> >> >>> On Fri, Dec 4, 2015 at 3:07 PM Shazron wrote: >> >>> >> >>> After working out some bridge improvements and fixing some Platform >> >>> API bugs and testing, I believe it's ready. I'll start a [VOTE] thread >> >>> soon. >> >>> >> >>> On Thu, Dec 3, 2015 at 5:19 PM, Carlos Santana >> >>> wrote: >> +1 let's move forward this items with WKWebview I don't see holding up >> >>> the >> platform. >> >> Don't see any changes going on the platform, if any they will go into >> >> the >> pluggable webview plugin or creating new plugin to handle. >> > On Wed, Dec 2, 2015 at 8:40 PM Shazron wrote: >> > >> > Regarding Platform API, Vladimir Kotikov and Sergey Grebnov agree in >> > the PR comments that the changes can go in to cordova-ios-4.x: >> > https://github.com/apache/cordova-ios/pull/176 >> > >> >> On Wed, Dec 2, 2015 at 5:38 PM, Shazron wrote: >> >> Also, check footnote 3 above. >> >> >> >> Yes, WebKit defines window.openDatabase but it doesn't do anything. >> >> Not sure why their tests didn't catch this... (see footnote for the >> >> bug) >> >> >> >> With CSP off to rule things out: >> >> XHR to yourself of course works, but doesn't really make sense for >> >> real-world use. XHR to a sibling file, parent file, or any child >> >> file >> >> results in the error ""Cross origin requests are only supported for >> >> HTTP”. >> >> >> >> To illustrate: >> >> >> >> | >> >> parent.xml >> >> | >> >> www >> >> | index.html (file currently loaded) >> >> | sibling.xml >> >> | child-folder >> >> | | child.xml >> >> >> >> index.html is the currently loaded file in the WebView. From it, you >> >> can't load parent.xml, sibling.xml nor child.xml using XHR according >> >> to my tests. >> >> >> >> Regarding *why* we have these storage tests, that is out of scope >> >> for >> >> this discussion, but I agree. >> >> >> >> >> >> On Wed, Dec 2, 2015 at 6:37 AM, Carlos Santana < >> >> csantan...@gmail.com> >> > wrote: >> >>> I'm guessing "pending" is the same as skipping the test. >> >>> I'm guessing WKWebView doesn't support Web SQL, but >> >>> window.openDat
Re: [DISCUSS] cordova-ios-4.x release (for real)
Currently finding a discrepancy when recreating the archive The tgz dist/ [1] is missing 3 node modules, they are located in git [2] Running the command coho create-archive --tag 4.0.0 -r ios --dest test-ios4/ I ran with npm@2.11.3 and npm@3.3.12 and was able to get all three in expected location bin/node_modules/cordova-common/node_modules/glob bin/node_modules/cordova-common/node_modules/q bin/node_modules/ios-sim/node_modules/nopt [1]: https://dist.apache.org/repos/dist/dev/cordova/CB-10147/cordova-ios-4.0.0.tgz [2]: https://github.com/apache/cordova-ios/tree/4.0.0/bin/node_modules On Mon, Dec 7, 2015 at 7:12 PM Carlos Santana wrote: > Currently working on it... > > - Carlos > @csantanapr > > > On Dec 7, 2015, at 6:50 PM, Steven Gill wrote: > > > > both ios@4 and cordova-plugin-wkwebviewengine need 1 more vote. Someone > > step up so Shaz can wrap up the vote threads and publish these! > > > >> On Fri, Dec 4, 2015 at 2:07 PM, Carlos Santana > wrote: > >> > >> +1 > >> > >>> On Fri, Dec 4, 2015 at 3:07 PM Shazron wrote: > >>> > >>> After working out some bridge improvements and fixing some Platform > >>> API bugs and testing, I believe it's ready. I'll start a [VOTE] thread > >>> soon. > >>> > >>> On Thu, Dec 3, 2015 at 5:19 PM, Carlos Santana > >>> wrote: > +1 let's move forward this items with WKWebview I don't see holding up > >>> the > platform. > > Don't see any changes going on the platform, if any they will go into > >> the > pluggable webview plugin or creating new plugin to handle. > > On Wed, Dec 2, 2015 at 8:40 PM Shazron wrote: > > > > Regarding Platform API, Vladimir Kotikov and Sergey Grebnov agree in > > the PR comments that the changes can go in to cordova-ios-4.x: > > https://github.com/apache/cordova-ios/pull/176 > > > >> On Wed, Dec 2, 2015 at 5:38 PM, Shazron wrote: > >> Also, check footnote 3 above. > >> > >> Yes, WebKit defines window.openDatabase but it doesn't do anything. > >> Not sure why their tests didn't catch this... (see footnote for the > >> bug) > >> > >> With CSP off to rule things out: > >> XHR to yourself of course works, but doesn't really make sense for > >> real-world use. XHR to a sibling file, parent file, or any child > >> file > >> results in the error ""Cross origin requests are only supported for > >> HTTP”. > >> > >> To illustrate: > >> > >> | > >> parent.xml > >> | > >> www > >> | index.html (file currently loaded) > >> | sibling.xml > >> | child-folder > >> | | child.xml > >> > >> index.html is the currently loaded file in the WebView. From it, you > >> can't load parent.xml, sibling.xml nor child.xml using XHR according > >> to my tests. > >> > >> Regarding *why* we have these storage tests, that is out of scope > >> for > >> this discussion, but I agree. > >> > >> > >> On Wed, Dec 2, 2015 at 6:37 AM, Carlos Santana < > >> csantan...@gmail.com> > > wrote: > >>> I'm guessing "pending" is the same as skipping the test. > >>> I'm guessing WKWebView doesn't support Web SQL, but > >>> window.openDatabase > >>> exist but it doesn't do anything? > >>> I ask because I only saw the pending for wkwebview spec.18 for > >> using > >>> it, > >>> not for spec.9 where it checks that exists. > >>> Anyway after all questions, why the we are still testing for > >> storage > > APIs? > >>> Cordova doesn't supported code to provide this storage APIs. > >>> I think we should remove the storage tests all together, this is > >>> webview/browser testing space. > >>> > >>> As for local xhr, is the problem only with specifying "../" > >> relative > > path > >>> in the xhr url and not local resources? > >>> I see that doing xhr "index.html" that's a local resource and it > >>> works, > > and > >>> also "./" also passes. > >>> Aren't all this relative paths transform into full urls, and they > >>> will > > have > >>> file:// in the final path used? > >>> This means that xhr "folder1/data.json" works, but xhr > >>> "../someparent/data.json" doesn't? > >>> > >>> > On Wed, Dec 2, 2015 at 4:52 AM Shazron wrote: > > Marked the two known failures as pending. Now everything is green > >>> (and > yellow) across the board for UIWebView and WKWebView. > > On Tue, Dec 1, 2015 at 11:49 PM, Jesse > > wrote: > >>> Or should I just let it fail still? > > It depends how long it'll be until we fix them. The build will > >> be > > broken > > in the CI until it is fixed so probably marking them as pending > >> is > > the > > better option. > > > > > > @purplecabbage > > risingj.com > > > > On Tue, Dec 1, 2015 at 10:42 PM, Shazron > >>> wro
Re: [DISCUSS] cordova-ios-4.x release (for real)
Currently working on it... - Carlos @csantanapr > On Dec 7, 2015, at 6:50 PM, Steven Gill wrote: > > both ios@4 and cordova-plugin-wkwebviewengine need 1 more vote. Someone > step up so Shaz can wrap up the vote threads and publish these! > >> On Fri, Dec 4, 2015 at 2:07 PM, Carlos Santana wrote: >> >> +1 >> >>> On Fri, Dec 4, 2015 at 3:07 PM Shazron wrote: >>> >>> After working out some bridge improvements and fixing some Platform >>> API bugs and testing, I believe it's ready. I'll start a [VOTE] thread >>> soon. >>> >>> On Thu, Dec 3, 2015 at 5:19 PM, Carlos Santana >>> wrote: +1 let's move forward this items with WKWebview I don't see holding up >>> the platform. Don't see any changes going on the platform, if any they will go into >> the pluggable webview plugin or creating new plugin to handle. > On Wed, Dec 2, 2015 at 8:40 PM Shazron wrote: > > Regarding Platform API, Vladimir Kotikov and Sergey Grebnov agree in > the PR comments that the changes can go in to cordova-ios-4.x: > https://github.com/apache/cordova-ios/pull/176 > >> On Wed, Dec 2, 2015 at 5:38 PM, Shazron wrote: >> Also, check footnote 3 above. >> >> Yes, WebKit defines window.openDatabase but it doesn't do anything. >> Not sure why their tests didn't catch this... (see footnote for the >> bug) >> >> With CSP off to rule things out: >> XHR to yourself of course works, but doesn't really make sense for >> real-world use. XHR to a sibling file, parent file, or any child >> file >> results in the error ""Cross origin requests are only supported for >> HTTP”. >> >> To illustrate: >> >> | >> parent.xml >> | >> www >> | index.html (file currently loaded) >> | sibling.xml >> | child-folder >> | | child.xml >> >> index.html is the currently loaded file in the WebView. From it, you >> can't load parent.xml, sibling.xml nor child.xml using XHR according >> to my tests. >> >> Regarding *why* we have these storage tests, that is out of scope >> for >> this discussion, but I agree. >> >> >> On Wed, Dec 2, 2015 at 6:37 AM, Carlos Santana < >> csantan...@gmail.com> > wrote: >>> I'm guessing "pending" is the same as skipping the test. >>> I'm guessing WKWebView doesn't support Web SQL, but >>> window.openDatabase >>> exist but it doesn't do anything? >>> I ask because I only saw the pending for wkwebview spec.18 for >> using >>> it, >>> not for spec.9 where it checks that exists. >>> Anyway after all questions, why the we are still testing for >> storage > APIs? >>> Cordova doesn't supported code to provide this storage APIs. >>> I think we should remove the storage tests all together, this is >>> webview/browser testing space. >>> >>> As for local xhr, is the problem only with specifying "../" >> relative > path >>> in the xhr url and not local resources? >>> I see that doing xhr "index.html" that's a local resource and it >>> works, > and >>> also "./" also passes. >>> Aren't all this relative paths transform into full urls, and they >>> will > have >>> file:// in the final path used? >>> This means that xhr "folder1/data.json" works, but xhr >>> "../someparent/data.json" doesn't? >>> >>> On Wed, Dec 2, 2015 at 4:52 AM Shazron wrote: Marked the two known failures as pending. Now everything is green >>> (and yellow) across the board for UIWebView and WKWebView. On Tue, Dec 1, 2015 at 11:49 PM, Jesse > wrote: >>> Or should I just let it fail still? > It depends how long it'll be until we fix them. The build will >> be > broken > in the CI until it is fixed so probably marking them as pending >> is > the > better option. > > > @purplecabbage > risingj.com > > On Tue, Dec 1, 2015 at 10:42 PM, Shazron >>> wrote: > >> Couldn't wait. All file-transfer specs now pass for uiwebview >> and >> wkwebview. >> >> For those two WKWebView tests that are failing, but are >> expected >>> to >> fail -- I'll try to modify the tests to mark the test as >> pending >>> if >> the platform is iOS and the WKWebView bridge is found. >> >> Or should I just let it fail still? >> >> On Tue, Dec 1, 2015 at 9:49 PM, Shazron >>> wrote: >>> Thanks! - yeah after I posted it, of course I realized it is >>> all > open >>> source (duh) and I can run a local server or throw it on a >>> digitalocean instance or something :) >>> I'll do that tomorrow... >>> >>> On Tue, Dec 1, 2015 at 9:24 PM, Carlos Santana < > csantan...@gmail.com> >> wrote: >>
Re: [DISCUSS] cordova-ios-4.x release (for real)
both ios@4 and cordova-plugin-wkwebviewengine need 1 more vote. Someone step up so Shaz can wrap up the vote threads and publish these! On Fri, Dec 4, 2015 at 2:07 PM, Carlos Santana wrote: > +1 > > On Fri, Dec 4, 2015 at 3:07 PM Shazron wrote: > > > After working out some bridge improvements and fixing some Platform > > API bugs and testing, I believe it's ready. I'll start a [VOTE] thread > > soon. > > > > On Thu, Dec 3, 2015 at 5:19 PM, Carlos Santana > > wrote: > > > +1 let's move forward this items with WKWebview I don't see holding up > > the > > > platform. > > > > > > Don't see any changes going on the platform, if any they will go into > the > > > pluggable webview plugin or creating new plugin to handle. > > > On Wed, Dec 2, 2015 at 8:40 PM Shazron wrote: > > > > > >> Regarding Platform API, Vladimir Kotikov and Sergey Grebnov agree in > > >> the PR comments that the changes can go in to cordova-ios-4.x: > > >> https://github.com/apache/cordova-ios/pull/176 > > >> > > >> On Wed, Dec 2, 2015 at 5:38 PM, Shazron wrote: > > >> > Also, check footnote 3 above. > > >> > > > >> > Yes, WebKit defines window.openDatabase but it doesn't do anything. > > >> > Not sure why their tests didn't catch this... (see footnote for the > > >> > bug) > > >> > > > >> > With CSP off to rule things out: > > >> > XHR to yourself of course works, but doesn't really make sense for > > >> > real-world use. XHR to a sibling file, parent file, or any child > file > > >> > results in the error ""Cross origin requests are only supported for > > >> > HTTP”. > > >> > > > >> > To illustrate: > > >> > > > >> > | > > >> > parent.xml > > >> > | > > >> > www > > >> > | index.html (file currently loaded) > > >> > | sibling.xml > > >> > | child-folder > > >> > | | child.xml > > >> > > > >> > index.html is the currently loaded file in the WebView. From it, you > > >> > can't load parent.xml, sibling.xml nor child.xml using XHR according > > >> > to my tests. > > >> > > > >> > Regarding *why* we have these storage tests, that is out of scope > for > > >> > this discussion, but I agree. > > >> > > > >> > > > >> > On Wed, Dec 2, 2015 at 6:37 AM, Carlos Santana < > csantan...@gmail.com> > > >> wrote: > > >> >> I'm guessing "pending" is the same as skipping the test. > > >> >> I'm guessing WKWebView doesn't support Web SQL, but > > window.openDatabase > > >> >> exist but it doesn't do anything? > > >> >> I ask because I only saw the pending for wkwebview spec.18 for > using > > it, > > >> >> not for spec.9 where it checks that exists. > > >> >> Anyway after all questions, why the we are still testing for > storage > > >> APIs? > > >> >> Cordova doesn't supported code to provide this storage APIs. > > >> >> I think we should remove the storage tests all together, this is > > >> >> webview/browser testing space. > > >> >> > > >> >> As for local xhr, is the problem only with specifying "../" > relative > > >> path > > >> >> in the xhr url and not local resources? > > >> >> I see that doing xhr "index.html" that's a local resource and it > > works, > > >> and > > >> >> also "./" also passes. > > >> >> Aren't all this relative paths transform into full urls, and they > > will > > >> have > > >> >> file:// in the final path used? > > >> >> This means that xhr "folder1/data.json" works, but xhr > > >> >> "../someparent/data.json" doesn't? > > >> >> > > >> >> > > >> >> On Wed, Dec 2, 2015 at 4:52 AM Shazron wrote: > > >> >> > > >> >>> Marked the two known failures as pending. Now everything is green > > (and > > >> >>> yellow) across the board for UIWebView and WKWebView. > > >> >>> > > >> >>> On Tue, Dec 1, 2015 at 11:49 PM, Jesse > > >> wrote: > > >> >>> >>> Or should I just let it fail still? > > >> >>> > It depends how long it'll be until we fix them. The build will > be > > >> broken > > >> >>> > in the CI until it is fixed so probably marking them as pending > is > > >> the > > >> >>> > better option. > > >> >>> > > > >> >>> > > > >> >>> > @purplecabbage > > >> >>> > risingj.com > > >> >>> > > > >> >>> > On Tue, Dec 1, 2015 at 10:42 PM, Shazron > > wrote: > > >> >>> > > > >> >>> >> Couldn't wait. All file-transfer specs now pass for uiwebview > and > > >> >>> >> wkwebview. > > >> >>> >> > > >> >>> >> For those two WKWebView tests that are failing, but are > expected > > to > > >> >>> >> fail -- I'll try to modify the tests to mark the test as > pending > > if > > >> >>> >> the platform is iOS and the WKWebView bridge is found. > > >> >>> >> > > >> >>> >> Or should I just let it fail still? > > >> >>> >> > > >> >>> >> On Tue, Dec 1, 2015 at 9:49 PM, Shazron > > wrote: > > >> >>> >> > Thanks! - yeah after I posted it, of course I realized it is > > all > > >> open > > >> >>> >> > source (duh) and I can run a local server or throw it on a > > >> >>> >> > digitalocean instance or something :) > > >> >>> >> > I'll do that tomorrow... > > >> >>> >> > > > >> >>> >> > On Tue, Dec 1, 2015 at 9:24 PM, Carlos S
Re: [DISCUSS] cordova-ios-4.x release (for real)
+1 On Fri, Dec 4, 2015 at 3:07 PM Shazron wrote: > After working out some bridge improvements and fixing some Platform > API bugs and testing, I believe it's ready. I'll start a [VOTE] thread > soon. > > On Thu, Dec 3, 2015 at 5:19 PM, Carlos Santana > wrote: > > +1 let's move forward this items with WKWebview I don't see holding up > the > > platform. > > > > Don't see any changes going on the platform, if any they will go into the > > pluggable webview plugin or creating new plugin to handle. > > On Wed, Dec 2, 2015 at 8:40 PM Shazron wrote: > > > >> Regarding Platform API, Vladimir Kotikov and Sergey Grebnov agree in > >> the PR comments that the changes can go in to cordova-ios-4.x: > >> https://github.com/apache/cordova-ios/pull/176 > >> > >> On Wed, Dec 2, 2015 at 5:38 PM, Shazron wrote: > >> > Also, check footnote 3 above. > >> > > >> > Yes, WebKit defines window.openDatabase but it doesn't do anything. > >> > Not sure why their tests didn't catch this... (see footnote for the > >> > bug) > >> > > >> > With CSP off to rule things out: > >> > XHR to yourself of course works, but doesn't really make sense for > >> > real-world use. XHR to a sibling file, parent file, or any child file > >> > results in the error ""Cross origin requests are only supported for > >> > HTTP”. > >> > > >> > To illustrate: > >> > > >> > | > >> > parent.xml > >> > | > >> > www > >> > | index.html (file currently loaded) > >> > | sibling.xml > >> > | child-folder > >> > | | child.xml > >> > > >> > index.html is the currently loaded file in the WebView. From it, you > >> > can't load parent.xml, sibling.xml nor child.xml using XHR according > >> > to my tests. > >> > > >> > Regarding *why* we have these storage tests, that is out of scope for > >> > this discussion, but I agree. > >> > > >> > > >> > On Wed, Dec 2, 2015 at 6:37 AM, Carlos Santana > >> wrote: > >> >> I'm guessing "pending" is the same as skipping the test. > >> >> I'm guessing WKWebView doesn't support Web SQL, but > window.openDatabase > >> >> exist but it doesn't do anything? > >> >> I ask because I only saw the pending for wkwebview spec.18 for using > it, > >> >> not for spec.9 where it checks that exists. > >> >> Anyway after all questions, why the we are still testing for storage > >> APIs? > >> >> Cordova doesn't supported code to provide this storage APIs. > >> >> I think we should remove the storage tests all together, this is > >> >> webview/browser testing space. > >> >> > >> >> As for local xhr, is the problem only with specifying "../" relative > >> path > >> >> in the xhr url and not local resources? > >> >> I see that doing xhr "index.html" that's a local resource and it > works, > >> and > >> >> also "./" also passes. > >> >> Aren't all this relative paths transform into full urls, and they > will > >> have > >> >> file:// in the final path used? > >> >> This means that xhr "folder1/data.json" works, but xhr > >> >> "../someparent/data.json" doesn't? > >> >> > >> >> > >> >> On Wed, Dec 2, 2015 at 4:52 AM Shazron wrote: > >> >> > >> >>> Marked the two known failures as pending. Now everything is green > (and > >> >>> yellow) across the board for UIWebView and WKWebView. > >> >>> > >> >>> On Tue, Dec 1, 2015 at 11:49 PM, Jesse > >> wrote: > >> >>> >>> Or should I just let it fail still? > >> >>> > It depends how long it'll be until we fix them. The build will be > >> broken > >> >>> > in the CI until it is fixed so probably marking them as pending is > >> the > >> >>> > better option. > >> >>> > > >> >>> > > >> >>> > @purplecabbage > >> >>> > risingj.com > >> >>> > > >> >>> > On Tue, Dec 1, 2015 at 10:42 PM, Shazron > wrote: > >> >>> > > >> >>> >> Couldn't wait. All file-transfer specs now pass for uiwebview and > >> >>> >> wkwebview. > >> >>> >> > >> >>> >> For those two WKWebView tests that are failing, but are expected > to > >> >>> >> fail -- I'll try to modify the tests to mark the test as pending > if > >> >>> >> the platform is iOS and the WKWebView bridge is found. > >> >>> >> > >> >>> >> Or should I just let it fail still? > >> >>> >> > >> >>> >> On Tue, Dec 1, 2015 at 9:49 PM, Shazron > wrote: > >> >>> >> > Thanks! - yeah after I posted it, of course I realized it is > all > >> open > >> >>> >> > source (duh) and I can run a local server or throw it on a > >> >>> >> > digitalocean instance or something :) > >> >>> >> > I'll do that tomorrow... > >> >>> >> > > >> >>> >> > On Tue, Dec 1, 2015 at 9:24 PM, Carlos Santana < > >> csantan...@gmail.com> > >> >>> >> wrote: > >> >>> >> >> For a second I read "the bar is clear", but then I went to my > >> fridge > >> >>> and > >> >>> >> >> saw I still have some beer left :-) > >> >>> >> >> > >> >>> >> >> How long before the INFRA provides the VM for the file > transfer, > >> I > >> >>> >> looked > >> >>> >> >> the JIRA and it mentioned something like "complete" and "we > are > >> in > >> >>> >> holding > >> >>> >> >> because of capacity" in the same comm
Re: [DISCUSS] cordova-ios-4.x release (for real)
After working out some bridge improvements and fixing some Platform API bugs and testing, I believe it's ready. I'll start a [VOTE] thread soon. On Thu, Dec 3, 2015 at 5:19 PM, Carlos Santana wrote: > +1 let's move forward this items with WKWebview I don't see holding up the > platform. > > Don't see any changes going on the platform, if any they will go into the > pluggable webview plugin or creating new plugin to handle. > On Wed, Dec 2, 2015 at 8:40 PM Shazron wrote: > >> Regarding Platform API, Vladimir Kotikov and Sergey Grebnov agree in >> the PR comments that the changes can go in to cordova-ios-4.x: >> https://github.com/apache/cordova-ios/pull/176 >> >> On Wed, Dec 2, 2015 at 5:38 PM, Shazron wrote: >> > Also, check footnote 3 above. >> > >> > Yes, WebKit defines window.openDatabase but it doesn't do anything. >> > Not sure why their tests didn't catch this... (see footnote for the >> > bug) >> > >> > With CSP off to rule things out: >> > XHR to yourself of course works, but doesn't really make sense for >> > real-world use. XHR to a sibling file, parent file, or any child file >> > results in the error ""Cross origin requests are only supported for >> > HTTP”. >> > >> > To illustrate: >> > >> > | >> > parent.xml >> > | >> > www >> > | index.html (file currently loaded) >> > | sibling.xml >> > | child-folder >> > | | child.xml >> > >> > index.html is the currently loaded file in the WebView. From it, you >> > can't load parent.xml, sibling.xml nor child.xml using XHR according >> > to my tests. >> > >> > Regarding *why* we have these storage tests, that is out of scope for >> > this discussion, but I agree. >> > >> > >> > On Wed, Dec 2, 2015 at 6:37 AM, Carlos Santana >> wrote: >> >> I'm guessing "pending" is the same as skipping the test. >> >> I'm guessing WKWebView doesn't support Web SQL, but window.openDatabase >> >> exist but it doesn't do anything? >> >> I ask because I only saw the pending for wkwebview spec.18 for using it, >> >> not for spec.9 where it checks that exists. >> >> Anyway after all questions, why the we are still testing for storage >> APIs? >> >> Cordova doesn't supported code to provide this storage APIs. >> >> I think we should remove the storage tests all together, this is >> >> webview/browser testing space. >> >> >> >> As for local xhr, is the problem only with specifying "../" relative >> path >> >> in the xhr url and not local resources? >> >> I see that doing xhr "index.html" that's a local resource and it works, >> and >> >> also "./" also passes. >> >> Aren't all this relative paths transform into full urls, and they will >> have >> >> file:// in the final path used? >> >> This means that xhr "folder1/data.json" works, but xhr >> >> "../someparent/data.json" doesn't? >> >> >> >> >> >> On Wed, Dec 2, 2015 at 4:52 AM Shazron wrote: >> >> >> >>> Marked the two known failures as pending. Now everything is green (and >> >>> yellow) across the board for UIWebView and WKWebView. >> >>> >> >>> On Tue, Dec 1, 2015 at 11:49 PM, Jesse >> wrote: >> >>> >>> Or should I just let it fail still? >> >>> > It depends how long it'll be until we fix them. The build will be >> broken >> >>> > in the CI until it is fixed so probably marking them as pending is >> the >> >>> > better option. >> >>> > >> >>> > >> >>> > @purplecabbage >> >>> > risingj.com >> >>> > >> >>> > On Tue, Dec 1, 2015 at 10:42 PM, Shazron wrote: >> >>> > >> >>> >> Couldn't wait. All file-transfer specs now pass for uiwebview and >> >>> >> wkwebview. >> >>> >> >> >>> >> For those two WKWebView tests that are failing, but are expected to >> >>> >> fail -- I'll try to modify the tests to mark the test as pending if >> >>> >> the platform is iOS and the WKWebView bridge is found. >> >>> >> >> >>> >> Or should I just let it fail still? >> >>> >> >> >>> >> On Tue, Dec 1, 2015 at 9:49 PM, Shazron wrote: >> >>> >> > Thanks! - yeah after I posted it, of course I realized it is all >> open >> >>> >> > source (duh) and I can run a local server or throw it on a >> >>> >> > digitalocean instance or something :) >> >>> >> > I'll do that tomorrow... >> >>> >> > >> >>> >> > On Tue, Dec 1, 2015 at 9:24 PM, Carlos Santana < >> csantan...@gmail.com> >> >>> >> wrote: >> >>> >> >> For a second I read "the bar is clear", but then I went to my >> fridge >> >>> and >> >>> >> >> saw I still have some beer left :-) >> >>> >> >> >> >>> >> >> How long before the INFRA provides the VM for the file transfer, >> I >> >>> >> looked >> >>> >> >> the JIRA and it mentioned something like "complete" and "we are >> in >> >>> >> holding >> >>> >> >> because of capacity" in the same comment, and I was like stupid >> >>> because >> >>> >> I >> >>> >> >> didn't understand :-( >> >>> >> >> >> >>> >> >> If it's going to take a long time, can we do the test with a >> local >> >>> >> machine >> >>> >> >> and vet that it works? >> >>> >> >> >> >>> >> >> For local xhr loading, I left a comment in the JIRA. I don't >>
Re: [DISCUSS] cordova-ios-4.x release (for real)
+1 let's move forward this items with WKWebview I don't see holding up the platform. Don't see any changes going on the platform, if any they will go into the pluggable webview plugin or creating new plugin to handle. On Wed, Dec 2, 2015 at 8:40 PM Shazron wrote: > Regarding Platform API, Vladimir Kotikov and Sergey Grebnov agree in > the PR comments that the changes can go in to cordova-ios-4.x: > https://github.com/apache/cordova-ios/pull/176 > > On Wed, Dec 2, 2015 at 5:38 PM, Shazron wrote: > > Also, check footnote 3 above. > > > > Yes, WebKit defines window.openDatabase but it doesn't do anything. > > Not sure why their tests didn't catch this... (see footnote for the > > bug) > > > > With CSP off to rule things out: > > XHR to yourself of course works, but doesn't really make sense for > > real-world use. XHR to a sibling file, parent file, or any child file > > results in the error ""Cross origin requests are only supported for > > HTTP”. > > > > To illustrate: > > > > | > > parent.xml > > | > > www > > | index.html (file currently loaded) > > | sibling.xml > > | child-folder > > | | child.xml > > > > index.html is the currently loaded file in the WebView. From it, you > > can't load parent.xml, sibling.xml nor child.xml using XHR according > > to my tests. > > > > Regarding *why* we have these storage tests, that is out of scope for > > this discussion, but I agree. > > > > > > On Wed, Dec 2, 2015 at 6:37 AM, Carlos Santana > wrote: > >> I'm guessing "pending" is the same as skipping the test. > >> I'm guessing WKWebView doesn't support Web SQL, but window.openDatabase > >> exist but it doesn't do anything? > >> I ask because I only saw the pending for wkwebview spec.18 for using it, > >> not for spec.9 where it checks that exists. > >> Anyway after all questions, why the we are still testing for storage > APIs? > >> Cordova doesn't supported code to provide this storage APIs. > >> I think we should remove the storage tests all together, this is > >> webview/browser testing space. > >> > >> As for local xhr, is the problem only with specifying "../" relative > path > >> in the xhr url and not local resources? > >> I see that doing xhr "index.html" that's a local resource and it works, > and > >> also "./" also passes. > >> Aren't all this relative paths transform into full urls, and they will > have > >> file:// in the final path used? > >> This means that xhr "folder1/data.json" works, but xhr > >> "../someparent/data.json" doesn't? > >> > >> > >> On Wed, Dec 2, 2015 at 4:52 AM Shazron wrote: > >> > >>> Marked the two known failures as pending. Now everything is green (and > >>> yellow) across the board for UIWebView and WKWebView. > >>> > >>> On Tue, Dec 1, 2015 at 11:49 PM, Jesse > wrote: > >>> >>> Or should I just let it fail still? > >>> > It depends how long it'll be until we fix them. The build will be > broken > >>> > in the CI until it is fixed so probably marking them as pending is > the > >>> > better option. > >>> > > >>> > > >>> > @purplecabbage > >>> > risingj.com > >>> > > >>> > On Tue, Dec 1, 2015 at 10:42 PM, Shazron wrote: > >>> > > >>> >> Couldn't wait. All file-transfer specs now pass for uiwebview and > >>> >> wkwebview. > >>> >> > >>> >> For those two WKWebView tests that are failing, but are expected to > >>> >> fail -- I'll try to modify the tests to mark the test as pending if > >>> >> the platform is iOS and the WKWebView bridge is found. > >>> >> > >>> >> Or should I just let it fail still? > >>> >> > >>> >> On Tue, Dec 1, 2015 at 9:49 PM, Shazron wrote: > >>> >> > Thanks! - yeah after I posted it, of course I realized it is all > open > >>> >> > source (duh) and I can run a local server or throw it on a > >>> >> > digitalocean instance or something :) > >>> >> > I'll do that tomorrow... > >>> >> > > >>> >> > On Tue, Dec 1, 2015 at 9:24 PM, Carlos Santana < > csantan...@gmail.com> > >>> >> wrote: > >>> >> >> For a second I read "the bar is clear", but then I went to my > fridge > >>> and > >>> >> >> saw I still have some beer left :-) > >>> >> >> > >>> >> >> How long before the INFRA provides the VM for the file transfer, > I > >>> >> looked > >>> >> >> the JIRA and it mentioned something like "complete" and "we are > in > >>> >> holding > >>> >> >> because of capacity" in the same comment, and I was like stupid > >>> because > >>> >> I > >>> >> >> didn't understand :-( > >>> >> >> > >>> >> >> If it's going to take a long time, can we do the test with a > local > >>> >> machine > >>> >> >> and vet that it works? > >>> >> >> > >>> >> >> For local xhr loading, I left a comment in the JIRA. I don't > think > >>> it's > >>> >> >> need it but I'm curios on how local xhr loading works when > fetching > >>> >> normal > >>> >> >> files on a web app, meaning dynamically loading js, css, html in > SPA > >>> >> using > >>> >> >> a typical js framework like angular, etc.. > >>> >> >> > >>> >> >> Platform API is [5], I think is nice to have
Re: [DISCUSS] cordova-ios-4.x release (for real)
Regarding Platform API, Vladimir Kotikov and Sergey Grebnov agree in the PR comments that the changes can go in to cordova-ios-4.x: https://github.com/apache/cordova-ios/pull/176 On Wed, Dec 2, 2015 at 5:38 PM, Shazron wrote: > Also, check footnote 3 above. > > Yes, WebKit defines window.openDatabase but it doesn't do anything. > Not sure why their tests didn't catch this... (see footnote for the > bug) > > With CSP off to rule things out: > XHR to yourself of course works, but doesn't really make sense for > real-world use. XHR to a sibling file, parent file, or any child file > results in the error ""Cross origin requests are only supported for > HTTP”. > > To illustrate: > > | > parent.xml > | > www > | index.html (file currently loaded) > | sibling.xml > | child-folder > | | child.xml > > index.html is the currently loaded file in the WebView. From it, you > can't load parent.xml, sibling.xml nor child.xml using XHR according > to my tests. > > Regarding *why* we have these storage tests, that is out of scope for > this discussion, but I agree. > > > On Wed, Dec 2, 2015 at 6:37 AM, Carlos Santana wrote: >> I'm guessing "pending" is the same as skipping the test. >> I'm guessing WKWebView doesn't support Web SQL, but window.openDatabase >> exist but it doesn't do anything? >> I ask because I only saw the pending for wkwebview spec.18 for using it, >> not for spec.9 where it checks that exists. >> Anyway after all questions, why the we are still testing for storage APIs? >> Cordova doesn't supported code to provide this storage APIs. >> I think we should remove the storage tests all together, this is >> webview/browser testing space. >> >> As for local xhr, is the problem only with specifying "../" relative path >> in the xhr url and not local resources? >> I see that doing xhr "index.html" that's a local resource and it works, and >> also "./" also passes. >> Aren't all this relative paths transform into full urls, and they will have >> file:// in the final path used? >> This means that xhr "folder1/data.json" works, but xhr >> "../someparent/data.json" doesn't? >> >> >> On Wed, Dec 2, 2015 at 4:52 AM Shazron wrote: >> >>> Marked the two known failures as pending. Now everything is green (and >>> yellow) across the board for UIWebView and WKWebView. >>> >>> On Tue, Dec 1, 2015 at 11:49 PM, Jesse wrote: >>> >>> Or should I just let it fail still? >>> > It depends how long it'll be until we fix them. The build will be broken >>> > in the CI until it is fixed so probably marking them as pending is the >>> > better option. >>> > >>> > >>> > @purplecabbage >>> > risingj.com >>> > >>> > On Tue, Dec 1, 2015 at 10:42 PM, Shazron wrote: >>> > >>> >> Couldn't wait. All file-transfer specs now pass for uiwebview and >>> >> wkwebview. >>> >> >>> >> For those two WKWebView tests that are failing, but are expected to >>> >> fail -- I'll try to modify the tests to mark the test as pending if >>> >> the platform is iOS and the WKWebView bridge is found. >>> >> >>> >> Or should I just let it fail still? >>> >> >>> >> On Tue, Dec 1, 2015 at 9:49 PM, Shazron wrote: >>> >> > Thanks! - yeah after I posted it, of course I realized it is all open >>> >> > source (duh) and I can run a local server or throw it on a >>> >> > digitalocean instance or something :) >>> >> > I'll do that tomorrow... >>> >> > >>> >> > On Tue, Dec 1, 2015 at 9:24 PM, Carlos Santana >>> >> wrote: >>> >> >> For a second I read "the bar is clear", but then I went to my fridge >>> and >>> >> >> saw I still have some beer left :-) >>> >> >> >>> >> >> How long before the INFRA provides the VM for the file transfer, I >>> >> looked >>> >> >> the JIRA and it mentioned something like "complete" and "we are in >>> >> holding >>> >> >> because of capacity" in the same comment, and I was like stupid >>> because >>> >> I >>> >> >> didn't understand :-( >>> >> >> >>> >> >> If it's going to take a long time, can we do the test with a local >>> >> machine >>> >> >> and vet that it works? >>> >> >> >>> >> >> For local xhr loading, I left a comment in the JIRA. I don't think >>> it's >>> >> >> need it but I'm curios on how local xhr loading works when fetching >>> >> normal >>> >> >> files on a web app, meaning dynamically loading js, css, html in SPA >>> >> using >>> >> >> a typical js framework like angular, etc.. >>> >> >> >>> >> >> Platform API is [5], I think is nice to have but not required for the >>> >> 4.0 >>> >> >> release. >>> >> >> >>> >> >> Oh by the way GREAT PROGRESS !!! and I cheers , I'm having a beer >>> now. >>> >> >> >>> >> >> >>> >> >> >>> >> >> On Tue, Dec 1, 2015 at 8:38 PM Shazron wrote: >>> >> >> >>> >> >>> The board is almost clear [1]. >>> >> >>> >>> >> >>> UIWebView mobile-spec passes, just waiting for INFRA-10831 [2] for >>> the >>> >> >>> file-transfer tests. >>> >> >>> Ditto for WKWebView, it essentially just fails two tests, which are >>> >> >>> expected [3] >>> >> >>> (filed a feature request
Re: [DISCUSS] cordova-ios-4.x release (for real)
Also, check footnote 3 above. Yes, WebKit defines window.openDatabase but it doesn't do anything. Not sure why their tests didn't catch this... (see footnote for the bug) With CSP off to rule things out: XHR to yourself of course works, but doesn't really make sense for real-world use. XHR to a sibling file, parent file, or any child file results in the error ""Cross origin requests are only supported for HTTP”. To illustrate: | parent.xml | www | index.html (file currently loaded) | sibling.xml | child-folder | | child.xml index.html is the currently loaded file in the WebView. From it, you can't load parent.xml, sibling.xml nor child.xml using XHR according to my tests. Regarding *why* we have these storage tests, that is out of scope for this discussion, but I agree. On Wed, Dec 2, 2015 at 6:37 AM, Carlos Santana wrote: > I'm guessing "pending" is the same as skipping the test. > I'm guessing WKWebView doesn't support Web SQL, but window.openDatabase > exist but it doesn't do anything? > I ask because I only saw the pending for wkwebview spec.18 for using it, > not for spec.9 where it checks that exists. > Anyway after all questions, why the we are still testing for storage APIs? > Cordova doesn't supported code to provide this storage APIs. > I think we should remove the storage tests all together, this is > webview/browser testing space. > > As for local xhr, is the problem only with specifying "../" relative path > in the xhr url and not local resources? > I see that doing xhr "index.html" that's a local resource and it works, and > also "./" also passes. > Aren't all this relative paths transform into full urls, and they will have > file:// in the final path used? > This means that xhr "folder1/data.json" works, but xhr > "../someparent/data.json" doesn't? > > > On Wed, Dec 2, 2015 at 4:52 AM Shazron wrote: > >> Marked the two known failures as pending. Now everything is green (and >> yellow) across the board for UIWebView and WKWebView. >> >> On Tue, Dec 1, 2015 at 11:49 PM, Jesse wrote: >> >>> Or should I just let it fail still? >> > It depends how long it'll be until we fix them. The build will be broken >> > in the CI until it is fixed so probably marking them as pending is the >> > better option. >> > >> > >> > @purplecabbage >> > risingj.com >> > >> > On Tue, Dec 1, 2015 at 10:42 PM, Shazron wrote: >> > >> >> Couldn't wait. All file-transfer specs now pass for uiwebview and >> >> wkwebview. >> >> >> >> For those two WKWebView tests that are failing, but are expected to >> >> fail -- I'll try to modify the tests to mark the test as pending if >> >> the platform is iOS and the WKWebView bridge is found. >> >> >> >> Or should I just let it fail still? >> >> >> >> On Tue, Dec 1, 2015 at 9:49 PM, Shazron wrote: >> >> > Thanks! - yeah after I posted it, of course I realized it is all open >> >> > source (duh) and I can run a local server or throw it on a >> >> > digitalocean instance or something :) >> >> > I'll do that tomorrow... >> >> > >> >> > On Tue, Dec 1, 2015 at 9:24 PM, Carlos Santana >> >> wrote: >> >> >> For a second I read "the bar is clear", but then I went to my fridge >> and >> >> >> saw I still have some beer left :-) >> >> >> >> >> >> How long before the INFRA provides the VM for the file transfer, I >> >> looked >> >> >> the JIRA and it mentioned something like "complete" and "we are in >> >> holding >> >> >> because of capacity" in the same comment, and I was like stupid >> because >> >> I >> >> >> didn't understand :-( >> >> >> >> >> >> If it's going to take a long time, can we do the test with a local >> >> machine >> >> >> and vet that it works? >> >> >> >> >> >> For local xhr loading, I left a comment in the JIRA. I don't think >> it's >> >> >> need it but I'm curios on how local xhr loading works when fetching >> >> normal >> >> >> files on a web app, meaning dynamically loading js, css, html in SPA >> >> using >> >> >> a typical js framework like angular, etc.. >> >> >> >> >> >> Platform API is [5], I think is nice to have but not required for the >> >> 4.0 >> >> >> release. >> >> >> >> >> >> Oh by the way GREAT PROGRESS !!! and I cheers , I'm having a beer >> now. >> >> >> >> >> >> >> >> >> >> >> >> On Tue, Dec 1, 2015 at 8:38 PM Shazron wrote: >> >> >> >> >> >>> The board is almost clear [1]. >> >> >>> >> >> >>> UIWebView mobile-spec passes, just waiting for INFRA-10831 [2] for >> the >> >> >>> file-transfer tests. >> >> >>> Ditto for WKWebView, it essentially just fails two tests, which are >> >> >>> expected [3] >> >> >>> (filed a feature request issue [4] for local xhr loading, if >> needed). >> >> >>> >> >> >>> Platform API [4] could go in this release as well, what do you >> think? >> >> >>> >> >> >>> --- >> >> >>> >> >> >>> [1] >> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=76 >> >> >>> [2] https://issues.apache.org/jira/browse/INFRA-10831 >> >> >>> [3] >> >> >>> >> >> >> https://issues.apache.org
Re: [DISCUSS] cordova-ios-4.x release (for real)
I'm guessing "pending" is the same as skipping the test. I'm guessing WKWebView doesn't support Web SQL, but window.openDatabase exist but it doesn't do anything? I ask because I only saw the pending for wkwebview spec.18 for using it, not for spec.9 where it checks that exists. Anyway after all questions, why the we are still testing for storage APIs? Cordova doesn't supported code to provide this storage APIs. I think we should remove the storage tests all together, this is webview/browser testing space. As for local xhr, is the problem only with specifying "../" relative path in the xhr url and not local resources? I see that doing xhr "index.html" that's a local resource and it works, and also "./" also passes. Aren't all this relative paths transform into full urls, and they will have file:// in the final path used? This means that xhr "folder1/data.json" works, but xhr "../someparent/data.json" doesn't? On Wed, Dec 2, 2015 at 4:52 AM Shazron wrote: > Marked the two known failures as pending. Now everything is green (and > yellow) across the board for UIWebView and WKWebView. > > On Tue, Dec 1, 2015 at 11:49 PM, Jesse wrote: > >>> Or should I just let it fail still? > > It depends how long it'll be until we fix them. The build will be broken > > in the CI until it is fixed so probably marking them as pending is the > > better option. > > > > > > @purplecabbage > > risingj.com > > > > On Tue, Dec 1, 2015 at 10:42 PM, Shazron wrote: > > > >> Couldn't wait. All file-transfer specs now pass for uiwebview and > >> wkwebview. > >> > >> For those two WKWebView tests that are failing, but are expected to > >> fail -- I'll try to modify the tests to mark the test as pending if > >> the platform is iOS and the WKWebView bridge is found. > >> > >> Or should I just let it fail still? > >> > >> On Tue, Dec 1, 2015 at 9:49 PM, Shazron wrote: > >> > Thanks! - yeah after I posted it, of course I realized it is all open > >> > source (duh) and I can run a local server or throw it on a > >> > digitalocean instance or something :) > >> > I'll do that tomorrow... > >> > > >> > On Tue, Dec 1, 2015 at 9:24 PM, Carlos Santana > >> wrote: > >> >> For a second I read "the bar is clear", but then I went to my fridge > and > >> >> saw I still have some beer left :-) > >> >> > >> >> How long before the INFRA provides the VM for the file transfer, I > >> looked > >> >> the JIRA and it mentioned something like "complete" and "we are in > >> holding > >> >> because of capacity" in the same comment, and I was like stupid > because > >> I > >> >> didn't understand :-( > >> >> > >> >> If it's going to take a long time, can we do the test with a local > >> machine > >> >> and vet that it works? > >> >> > >> >> For local xhr loading, I left a comment in the JIRA. I don't think > it's > >> >> need it but I'm curios on how local xhr loading works when fetching > >> normal > >> >> files on a web app, meaning dynamically loading js, css, html in SPA > >> using > >> >> a typical js framework like angular, etc.. > >> >> > >> >> Platform API is [5], I think is nice to have but not required for the > >> 4.0 > >> >> release. > >> >> > >> >> Oh by the way GREAT PROGRESS !!! and I cheers , I'm having a beer > now. > >> >> > >> >> > >> >> > >> >> On Tue, Dec 1, 2015 at 8:38 PM Shazron wrote: > >> >> > >> >>> The board is almost clear [1]. > >> >>> > >> >>> UIWebView mobile-spec passes, just waiting for INFRA-10831 [2] for > the > >> >>> file-transfer tests. > >> >>> Ditto for WKWebView, it essentially just fails two tests, which are > >> >>> expected [3] > >> >>> (filed a feature request issue [4] for local xhr loading, if > needed). > >> >>> > >> >>> Platform API [4] could go in this release as well, what do you > think? > >> >>> > >> >>> --- > >> >>> > >> >>> [1] > https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=76 > >> >>> [2] https://issues.apache.org/jira/browse/INFRA-10831 > >> >>> [3] > >> >>> > >> > https://issues.apache.org/jira/browse/CB-7287?focusedCommentId=15034831&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15034831 > >> >>> [4] https://issues.apache.org/jira/browse/CB-10109 > >> >>> [5] https://github.com/apache/cordova-ios/pull/176 > >> >>> > >> >>> > - > >> >>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > >> >>> For additional commands, e-mail: dev-h...@cordova.apache.org > >> >>> > >> >>> > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > >> For additional commands, e-mail: dev-h...@cordova.apache.org > >> > >> > > - > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > >
Re: [DISCUSS] cordova-ios-4.x release (for real)
Marked the two known failures as pending. Now everything is green (and yellow) across the board for UIWebView and WKWebView. On Tue, Dec 1, 2015 at 11:49 PM, Jesse wrote: >>> Or should I just let it fail still? > It depends how long it'll be until we fix them. The build will be broken > in the CI until it is fixed so probably marking them as pending is the > better option. > > > @purplecabbage > risingj.com > > On Tue, Dec 1, 2015 at 10:42 PM, Shazron wrote: > >> Couldn't wait. All file-transfer specs now pass for uiwebview and >> wkwebview. >> >> For those two WKWebView tests that are failing, but are expected to >> fail -- I'll try to modify the tests to mark the test as pending if >> the platform is iOS and the WKWebView bridge is found. >> >> Or should I just let it fail still? >> >> On Tue, Dec 1, 2015 at 9:49 PM, Shazron wrote: >> > Thanks! - yeah after I posted it, of course I realized it is all open >> > source (duh) and I can run a local server or throw it on a >> > digitalocean instance or something :) >> > I'll do that tomorrow... >> > >> > On Tue, Dec 1, 2015 at 9:24 PM, Carlos Santana >> wrote: >> >> For a second I read "the bar is clear", but then I went to my fridge and >> >> saw I still have some beer left :-) >> >> >> >> How long before the INFRA provides the VM for the file transfer, I >> looked >> >> the JIRA and it mentioned something like "complete" and "we are in >> holding >> >> because of capacity" in the same comment, and I was like stupid because >> I >> >> didn't understand :-( >> >> >> >> If it's going to take a long time, can we do the test with a local >> machine >> >> and vet that it works? >> >> >> >> For local xhr loading, I left a comment in the JIRA. I don't think it's >> >> need it but I'm curios on how local xhr loading works when fetching >> normal >> >> files on a web app, meaning dynamically loading js, css, html in SPA >> using >> >> a typical js framework like angular, etc.. >> >> >> >> Platform API is [5], I think is nice to have but not required for the >> 4.0 >> >> release. >> >> >> >> Oh by the way GREAT PROGRESS !!! and I cheers , I'm having a beer now. >> >> >> >> >> >> >> >> On Tue, Dec 1, 2015 at 8:38 PM Shazron wrote: >> >> >> >>> The board is almost clear [1]. >> >>> >> >>> UIWebView mobile-spec passes, just waiting for INFRA-10831 [2] for the >> >>> file-transfer tests. >> >>> Ditto for WKWebView, it essentially just fails two tests, which are >> >>> expected [3] >> >>> (filed a feature request issue [4] for local xhr loading, if needed). >> >>> >> >>> Platform API [4] could go in this release as well, what do you think? >> >>> >> >>> --- >> >>> >> >>> [1] https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=76 >> >>> [2] https://issues.apache.org/jira/browse/INFRA-10831 >> >>> [3] >> >>> >> https://issues.apache.org/jira/browse/CB-7287?focusedCommentId=15034831&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15034831 >> >>> [4] https://issues.apache.org/jira/browse/CB-10109 >> >>> [5] https://github.com/apache/cordova-ios/pull/176 >> >>> >> >>> - >> >>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >> >>> For additional commands, e-mail: dev-h...@cordova.apache.org >> >>> >> >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >> For additional commands, e-mail: dev-h...@cordova.apache.org >> >> - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: [DISCUSS] cordova-ios-4.x release (for real)
>> Or should I just let it fail still? It depends how long it'll be until we fix them. The build will be broken in the CI until it is fixed so probably marking them as pending is the better option. @purplecabbage risingj.com On Tue, Dec 1, 2015 at 10:42 PM, Shazron wrote: > Couldn't wait. All file-transfer specs now pass for uiwebview and > wkwebview. > > For those two WKWebView tests that are failing, but are expected to > fail -- I'll try to modify the tests to mark the test as pending if > the platform is iOS and the WKWebView bridge is found. > > Or should I just let it fail still? > > On Tue, Dec 1, 2015 at 9:49 PM, Shazron wrote: > > Thanks! - yeah after I posted it, of course I realized it is all open > > source (duh) and I can run a local server or throw it on a > > digitalocean instance or something :) > > I'll do that tomorrow... > > > > On Tue, Dec 1, 2015 at 9:24 PM, Carlos Santana > wrote: > >> For a second I read "the bar is clear", but then I went to my fridge and > >> saw I still have some beer left :-) > >> > >> How long before the INFRA provides the VM for the file transfer, I > looked > >> the JIRA and it mentioned something like "complete" and "we are in > holding > >> because of capacity" in the same comment, and I was like stupid because > I > >> didn't understand :-( > >> > >> If it's going to take a long time, can we do the test with a local > machine > >> and vet that it works? > >> > >> For local xhr loading, I left a comment in the JIRA. I don't think it's > >> need it but I'm curios on how local xhr loading works when fetching > normal > >> files on a web app, meaning dynamically loading js, css, html in SPA > using > >> a typical js framework like angular, etc.. > >> > >> Platform API is [5], I think is nice to have but not required for the > 4.0 > >> release. > >> > >> Oh by the way GREAT PROGRESS !!! and I cheers , I'm having a beer now. > >> > >> > >> > >> On Tue, Dec 1, 2015 at 8:38 PM Shazron wrote: > >> > >>> The board is almost clear [1]. > >>> > >>> UIWebView mobile-spec passes, just waiting for INFRA-10831 [2] for the > >>> file-transfer tests. > >>> Ditto for WKWebView, it essentially just fails two tests, which are > >>> expected [3] > >>> (filed a feature request issue [4] for local xhr loading, if needed). > >>> > >>> Platform API [4] could go in this release as well, what do you think? > >>> > >>> --- > >>> > >>> [1] https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=76 > >>> [2] https://issues.apache.org/jira/browse/INFRA-10831 > >>> [3] > >>> > https://issues.apache.org/jira/browse/CB-7287?focusedCommentId=15034831&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15034831 > >>> [4] https://issues.apache.org/jira/browse/CB-10109 > >>> [5] https://github.com/apache/cordova-ios/pull/176 > >>> > >>> - > >>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > >>> For additional commands, e-mail: dev-h...@cordova.apache.org > >>> > >>> > > - > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > >
Re: [DISCUSS] cordova-ios-4.x release (for real)
Couldn't wait. All file-transfer specs now pass for uiwebview and wkwebview. For those two WKWebView tests that are failing, but are expected to fail -- I'll try to modify the tests to mark the test as pending if the platform is iOS and the WKWebView bridge is found. Or should I just let it fail still? On Tue, Dec 1, 2015 at 9:49 PM, Shazron wrote: > Thanks! - yeah after I posted it, of course I realized it is all open > source (duh) and I can run a local server or throw it on a > digitalocean instance or something :) > I'll do that tomorrow... > > On Tue, Dec 1, 2015 at 9:24 PM, Carlos Santana wrote: >> For a second I read "the bar is clear", but then I went to my fridge and >> saw I still have some beer left :-) >> >> How long before the INFRA provides the VM for the file transfer, I looked >> the JIRA and it mentioned something like "complete" and "we are in holding >> because of capacity" in the same comment, and I was like stupid because I >> didn't understand :-( >> >> If it's going to take a long time, can we do the test with a local machine >> and vet that it works? >> >> For local xhr loading, I left a comment in the JIRA. I don't think it's >> need it but I'm curios on how local xhr loading works when fetching normal >> files on a web app, meaning dynamically loading js, css, html in SPA using >> a typical js framework like angular, etc.. >> >> Platform API is [5], I think is nice to have but not required for the 4.0 >> release. >> >> Oh by the way GREAT PROGRESS !!! and I cheers , I'm having a beer now. >> >> >> >> On Tue, Dec 1, 2015 at 8:38 PM Shazron wrote: >> >>> The board is almost clear [1]. >>> >>> UIWebView mobile-spec passes, just waiting for INFRA-10831 [2] for the >>> file-transfer tests. >>> Ditto for WKWebView, it essentially just fails two tests, which are >>> expected [3] >>> (filed a feature request issue [4] for local xhr loading, if needed). >>> >>> Platform API [4] could go in this release as well, what do you think? >>> >>> --- >>> >>> [1] https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=76 >>> [2] https://issues.apache.org/jira/browse/INFRA-10831 >>> [3] >>> https://issues.apache.org/jira/browse/CB-7287?focusedCommentId=15034831&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15034831 >>> [4] https://issues.apache.org/jira/browse/CB-10109 >>> [5] https://github.com/apache/cordova-ios/pull/176 >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >>> For additional commands, e-mail: dev-h...@cordova.apache.org >>> >>> - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: [DISCUSS] cordova-ios-4.x release (for real)
Thanks! - yeah after I posted it, of course I realized it is all open source (duh) and I can run a local server or throw it on a digitalocean instance or something :) I'll do that tomorrow... On Tue, Dec 1, 2015 at 9:24 PM, Carlos Santana wrote: > For a second I read "the bar is clear", but then I went to my fridge and > saw I still have some beer left :-) > > How long before the INFRA provides the VM for the file transfer, I looked > the JIRA and it mentioned something like "complete" and "we are in holding > because of capacity" in the same comment, and I was like stupid because I > didn't understand :-( > > If it's going to take a long time, can we do the test with a local machine > and vet that it works? > > For local xhr loading, I left a comment in the JIRA. I don't think it's > need it but I'm curios on how local xhr loading works when fetching normal > files on a web app, meaning dynamically loading js, css, html in SPA using > a typical js framework like angular, etc.. > > Platform API is [5], I think is nice to have but not required for the 4.0 > release. > > Oh by the way GREAT PROGRESS !!! and I cheers , I'm having a beer now. > > > > On Tue, Dec 1, 2015 at 8:38 PM Shazron wrote: > >> The board is almost clear [1]. >> >> UIWebView mobile-spec passes, just waiting for INFRA-10831 [2] for the >> file-transfer tests. >> Ditto for WKWebView, it essentially just fails two tests, which are >> expected [3] >> (filed a feature request issue [4] for local xhr loading, if needed). >> >> Platform API [4] could go in this release as well, what do you think? >> >> --- >> >> [1] https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=76 >> [2] https://issues.apache.org/jira/browse/INFRA-10831 >> [3] >> https://issues.apache.org/jira/browse/CB-7287?focusedCommentId=15034831&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15034831 >> [4] https://issues.apache.org/jira/browse/CB-10109 >> [5] https://github.com/apache/cordova-ios/pull/176 >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >> For additional commands, e-mail: dev-h...@cordova.apache.org >> >> - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: [DISCUSS] cordova-ios-4.x release (for real)
For a second I read "the bar is clear", but then I went to my fridge and saw I still have some beer left :-) How long before the INFRA provides the VM for the file transfer, I looked the JIRA and it mentioned something like "complete" and "we are in holding because of capacity" in the same comment, and I was like stupid because I didn't understand :-( If it's going to take a long time, can we do the test with a local machine and vet that it works? For local xhr loading, I left a comment in the JIRA. I don't think it's need it but I'm curios on how local xhr loading works when fetching normal files on a web app, meaning dynamically loading js, css, html in SPA using a typical js framework like angular, etc.. Platform API is [5], I think is nice to have but not required for the 4.0 release. Oh by the way GREAT PROGRESS !!! and I cheers , I'm having a beer now. On Tue, Dec 1, 2015 at 8:38 PM Shazron wrote: > The board is almost clear [1]. > > UIWebView mobile-spec passes, just waiting for INFRA-10831 [2] for the > file-transfer tests. > Ditto for WKWebView, it essentially just fails two tests, which are > expected [3] > (filed a feature request issue [4] for local xhr loading, if needed). > > Platform API [4] could go in this release as well, what do you think? > > --- > > [1] https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=76 > [2] https://issues.apache.org/jira/browse/INFRA-10831 > [3] > https://issues.apache.org/jira/browse/CB-7287?focusedCommentId=15034831&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15034831 > [4] https://issues.apache.org/jira/browse/CB-10109 > [5] https://github.com/apache/cordova-ios/pull/176 > > - > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > >
