Re: WebView Promise and W3C standards

you could do sneakier haicker things …at any rate -1 on promises remains the case On Fri, Dec 12, 2014 at 12:25 PM, Jesse wrote: > Oops, I was wrong. My test works on the first page loaded, but any page > after that it does not. Your faith was well placed. I won't bother trying > Android, as no

Re: WebView Promise and W3C standards

Oops, I was wrong. My test works on the first page loaded, but any page after that it does not. Your faith was well placed. I won't bother trying Android, as no-iOS is a blocker. > On Dec 12, 2014, at 11:55 AM, Andrew Grieve wrote: > >> On Fri, Dec 12, 2014 at 2:28 PM, Jesse wrote: >> >>

Re: WebView Promise and W3C standards

On Fri, Dec 12, 2014 at 2:28 PM, Jesse wrote: > On Fri, Dec 12, 2014 at 11:10 AM, Shazron wrote: > > > Yup, WKWebView has an option to add a script at > > WKUserScriptInjectionTimeAtDocumentStart. > > > > On Fri, Dec 12, 2014 at 7:21 AM, Andrew Grieve > > wrote: > > > I believe there's not API

Re: WebView Promise and W3C standards

On Fri, Dec 12, 2014 at 11:10 AM, Shazron wrote: > Yup, WKWebView has an option to add a script at > WKUserScriptInjectionTimeAtDocumentStart. > > On Fri, Dec 12, 2014 at 7:21 AM, Andrew Grieve > wrote: > > I believe there's not API to insert this early for Android / iOS other > than > > in the

Re: WebView Promise and W3C standards

Yup, WKWebView has an option to add a script at WKUserScriptInjectionTimeAtDocumentStart. On Fri, Dec 12, 2014 at 7:21 AM, Andrew Grieve wrote: > I believe there's not API to insert this early for Android / iOS other than > in the new WKWebView. > > On Thu, Dec 11, 2014 at 3:23 PM, Jesse wrote:

Re: WebView Promise and W3C standards

I believe there's not API to insert this early for Android / iOS other than in the new WKWebView. On Thu, Dec 11, 2014 at 3:23 PM, Jesse wrote: > The native side knows the browser capabilities long before it's > loaded, or even created, compile time even. They will never change > after the app i

Re: WebView Promise and W3C standards

The native side knows the browser capabilities long before it's loaded, or even created, compile time even. They will never change after the app is built. On WP8 the scripts are injected right before DOMContentLoaded fires, and before any js code in the page is run. I realize other platforms may n

Re: WebView Promise and W3C standards

Let's start a new thread for browserify. Jesse - def. like the idea of injecting polyfills when they are not there but are required. In practice though, I think it ends up pretty much the same anyways: - On start-up you need to feature-detect Promise via JS - If it's not there, you need to inject

Re: WebView Promise and W3C standards

Just to let you know we have been using a promises polyfill plugin for some time now : https://github.com/vstirbu/PromisesPlugin On Thu, Dec 11, 2014 at 3:38 AM, Michal Mocny wrote: > Jesse: yes, that could work. By setting your polyfill to you'll be > sure it is available after pluginsready

Re: WebView Promise and W3C standards

Jesse: yes, that could work. By setting your polyfill to you'll be sure it is available after pluginsready (and thus deviceready). For plugins that use Promises during bootstrap, which is unlikely to be common, the explicit require() on the polyfill is still an option. Regarding your Native inj

Re: WebView Promise and W3C standards

we should move browserify to main and drop that insane concat code its not heavyweight at all. it creates a hash in iife with deps mapped in…as to why dep mgmt is better than concatenating…I don't think we need to waste our time talking about that! On Wed, Dec 10, 2014 at 5:00 PM, Andrew Grieve

Re: WebView Promise and W3C standards

There's something implemented behind a --browserify flag, but not sure what it does. Totally in favour of having CLI / plugman concatenate plugin JS with cordova.js, but not convinced that browserify is the right tool for this, as it seems quite heavy-weight for just concatenating things. If someo

Re: WebView Promise and W3C standards

So far I have approached browser polyfils with an outside-in approach. For example, there are issues in the C# + WP8 browser implementation of XMLHttpRequest which prevent xhr calls to the local filesystem. This could have been resolved by adding platform specific code to cordova-js, but my solut

Re: WebView Promise and W3C standards

We haven't worked on it, also curious. Anis, perhaps? On Wed, Dec 10, 2014 at 4:08 PM, Brian LeRoux wrote: > def think we should support those specs in our great and fabled api > audit…had not considered the load order issue > > not insurmountable and probably should be a feature/fix for the pl

Re: WebView Promise and W3C standards

def think we should support those specs in our great and fabled api audit…had not considered the load order issue not insurmountable and probably should be a feature/fix for the plugin loader load order …but also sort of scary… reminds me of script tags hell on that note: we need to make browseri

Re: WebView Promise and W3C standards

Do we prefer to invent new cordova-specific apis, or prefer to match standard browser apis? When there is no browser spec to match then design comes down to aesthetics and personal preference (as you say). But often there is an existing browser spec, and then it comes down to match or fork. I'm

Re: WebView Promise and W3C standards

Why does battery-status 'require' promises? I agree that promises are here to stay, but I am unclear why it would be a good idea to go and change/rewrite/break our apis to use them? Most of the windows plugins use promises all over the place, the entire async windows js api is promise based, but

Re: WebView Promise and W3C standards

- no technical benefit (but aesthetics, sure) - adds weight (payload and runtime) - might interfere with userland polly -1 On Wed, Dec 10, 2014 at 7:48 AM, Andrew Grieve wrote: > One specific spot in core I'd like to use it is to address this TODO in > Android's exec bridge: > > https://github.

Re: WebView Promise and W3C standards

One specific spot in core I'd like to use it is to address this TODO in Android's exec bridge: https://github.com/apache/cordova-js/blob/master/src/android/exec.js#L263 The actual need is for a setImmediate polyfill, but Promise does the same thing (with an extra object creation). On Wed, Dec 10

Re: WebView Promise and W3C standards

On Wed Dec 10 2014 at 10:17:38 AM Andrew Grieve wrote: > userland means that plugins won't be able to use them unless every plugin > also includes a copy of the polyfill within it. > > Looking at our core APIs, seems maybe it's just battery-status that will > require it. Should we have battery-st

Re: WebView Promise and W3C standards

userland means that plugins won't be able to use them unless every plugin also includes a copy of the polyfill within it. Looking at our core APIs, seems maybe it's just battery-status that will require it. Should we have battery-status include the polyfill within it? I hope not. I'd hate to get t

Re: WebView Promise and W3C standards

+1 to userland. I see other approaches causing more problems. BTW: The only time I use promises is when the platform explicitly requires it, and right now that's just MozillaView. While I think it looks awesome, I view Promises as a luxury right now and not a standard feature as of yet. I also r

Re: WebView Promise and W3C standards

This has me more convinced it should be a userland library and not even a plugin. Problem solved! ;) On Fri, Dec 5, 2014, 12:28 PM Ian Clelland wrote: > I have two reasons for not wanting this as a plugin (both of which, I'm > sure, are entirely subjective) > > The biggest one is just that nativ

Re: WebView Promise and W3C standards

I have two reasons for not wanting this as a plugin (both of which, I'm sure, are entirely subjective) The biggest one is just that native support for this really is coming quickly, and one day, we'll be able to remove it, because just about every platform that we care about will have support buil

Re: WebView Promise and W3C standards

Thanks Max, Yeah, I saw my earlier comment, but given more time to think about it, I feel that plugin-ization of all things is a better approach. ( my dislike of promises aside ) Ultimately these apis will make their way into the browser controls themselves, then plugin authors could drop their dep

Re: WebView Promise and W3C standards

I can easily change to expanded (non-minified) code; I went with smaller size, expecting that people wouldn't be wanting to inspect the promise polyfill code. No big deal. Earlier in this very thread, people (Jesse included) asserted that it should be in core, and Andrew outlined rationale. I wa

Re: WebView Promise and W3C standards

Minified code is a flat out bad idea and needs to be reverted immediately. Jesse is right about promises too. Given that native support is immediately inbound it most certainly should be a plugin. Not core. I'll reserve debate about it as a lang feature for the drama queens on hacker news and twit

Re: WebView Promise and W3C standards

We would be mandating its support, we have plenty of issues in Jira, and this solves none of them. ... and minified code? Why? How can I evaluate it? My mantra is and will remain "Plugins are everything, and everything is a plugin" What is the inconvenience in having a dependency on a promise plug

Re: WebView Promise and W3C standards

I think it's nice to remove that obstacle from in front of plugin developers who want to use promises. If we're going to suggest that people drop the polyfill in themselves, I don't see the harm in just having it there, especially if we don't mandate its use. Going forward, many/most APIs will us

Re: WebView Promise and W3C standards

Nice, but please don't add this. Anyone who wants or needs this can do what you did, and if I start seeing promise code throughout Cordova.js I may run. We should be looking to get rid of Cordova.js entirely, not add more deps. Why not a promise plugin? Fyi: promises invoke my fight or fligh

Re: WebView Promise and W3C standards

I've created a topic branch called "promise" to cordova-js. It has a commit that adds this ES6 promise polyfill (minified) to cordova.js and a simple test to en

Re: WebView Promise and W3C standards

BB10 does have a native secure element API. I may be able to dig up some code which bridges this to JavaScript. On Thu, Aug 14, 2014 at 7:41 AM, Axel Nennker wrote: > I created https://issues.apache.org/jira/browse/CB-7310 to track this. > > > 2014-08-13 22:57 GMT+02:00 Axel Nennker : > > > Goo

Re: WebView Promise and W3C standards

I created https://issues.apache.org/jira/browse/CB-7310 to track this. 2014-08-13 22:57 GMT+02:00 Axel Nennker : > Good to know. Thanks. > Am 13.08.2014 20:56 schrieb "Josh Soref" : > > Axel Nennker wrote: >> >I am interested to implement the secure element API. >> >Mozilla is currently impleme

Re: WebView Promise and W3C standards

Good to know. Thanks. Am 13.08.2014 20:56 schrieb "Josh Soref" : > Axel Nennker wrote: > >I am interested to implement the secure element API. > >Mozilla is currently implementing it with our help for FFOS but I want it > >for Android too. Blackberry shouldn't be that difficult using JSR177. > >

Re: WebView Promise and W3C standards

Axel Nennker wrote: >I am interested to implement the secure element API. >Mozilla is currently implementing it with our help for FFOS but I want it >for Android too. Blackberry shouldn't be that difficult using JSR177. BlackBerry classic (which is built around Java) isn't supported by Cordova and

Re: WebView Promise and W3C standards

I am interested to implement the secure element API. Mozilla is currently implementing it with our help for FFOS but I want it for Android too. Blackberry shouldn't be that difficult using JSR177. https://bugzilla.mozilla.org/show_bug.cgi?id=879861 That API uses Promises. Would be cool to have Pr

Re: WebView Promise and W3C standards

+1 on promises leading to worse JS code. I really wish that the Battery Spec and others wouldn't use promises, since they're absolutely terrible and events accomplish the same thing in that case. On Wed, Aug 13, 2014 at 11:05 AM, Jesse wrote: > I agree the polyfil should exist, and it should pr

Re: WebView Promise and W3C standards

I agree the polyfil should exist, and it should probably be in core. However, I do not agree with the sentiment that 'we' should encourage their use, 'you' may. Personally, I see more ugly code written because of Promises than the ugly code it tries to fix. Windows8 and Windows Phone 8 already sup

Re: WebView Promise and W3C standards

I'm be in favour of adding the polyfill right to cordova.js. - I'd like to use setImmediate within the Android bridge code, and setImmediate make up about half of the Promise polyfill code. - The polyfill is quite small - Promises are a part of ECMAScript, have been adopted by multiple browsers, a

Re: WebView Promise and W3C standards

Libs like modernizr will polyfill Promises, but that seems heavy handed for just this small library. My advice: when we want to write our first api that requires promises, we create a separate plugin just for the Promise polyfill. Then, any api that requires Promises can depend on the polyfill pl

WebView Promise and W3C standards

Hi, newer W3C standards use Promises but I think that Promises are not implemented in the WebViews Cordova currently uses. Any advise on this? How should I implement a new W3C standard in Cordova? Are there examples already? kind regards Axel