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 <[email protected]> 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-iOS is a blocker. > > > > > On Dec 12, 2014, at 11:55 AM, Andrew Grieve <[email protected]> > wrote: > > > >> On Fri, Dec 12, 2014 at 2:28 PM, Jesse <[email protected]> wrote: > >> > >>> On Fri, Dec 12, 2014 at 11:10 AM, Shazron <[email protected]> wrote: > >>> > >>> Yup, WKWebView has an option to add a script at > >>> WKUserScriptInjectionTimeAtDocumentStart. > >>> > >>> On Fri, Dec 12, 2014 at 7:21 AM, Andrew Grieve <[email protected]> > >>> wrote: > >>>> I believe there's not API to insert this early for Android / iOS other > >>> than > >>>> in the new WKWebView. > >> > >> On iOS you can inject js code in webViewDidStartLoad, which is evaluated > >> and available before any other js loads/runs. Science before belief. > >> I will run a similar test on Android. > > This is sadly not the case. You're still in the context of the previous > > page when this is fired. > > > > > > > >> > >> > >> > >>>> > >>>> On Thu, Dec 11, 2014 at 3:23 PM, Jesse <[email protected]> > >> 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 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 not be able to catch the browser load events early enough to be > >>>>> effective though. Anyone know the native side event flow for > >>>>> iOS+Android? > >>>>> > >>>>>>> On Dec 11, 2014, at 10:54 AM, Andrew Grieve <[email protected]> > >>>>>> wrote: > >>>>>> > >>>>>> 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 it. > >>>>>> > >>>>>> Whether the injection occurs via the native side shoving it in, or > >> by > >>>>>> cordova.js require()'ing a module is a matter of whether we check in > >>>>>> es6-promise.js into each platform separately, or into cordova-js. > >>>>>> > >>>>>> > >>>>>>> On Wed, Dec 10, 2014 at 8:35 PM, Brian LeRoux <[email protected]> wrote: > >>>>>>> > >>>>>>> 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 < > >> [email protected] > >>>> > >>>>>>> wrote: > >>>>>>> > >>>>>>>> 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 > >>>>> someone > >>>>>>> is > >>>>>>>> going to resume work on it, would love to hear a summary of what > >>>>> problems > >>>>>>>> it's solving (if more than concatenation), and why something more > >>>>>>>> light-weight wouldn't be better. > >>>>>>>> > >>>>>>>>> On Wed, Dec 10, 2014 at 4:22 PM, Michal Mocny < > >> [email protected] > >>>> > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>>> We haven't worked on it, also curious. Anis, perhaps? > >>>>>>>>> > >>>>>>>>>> On Wed, Dec 10, 2014 at 4:08 PM, Brian LeRoux <[email protected]> > >> 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 > >>>>>>> plugin > >>>>>>>>>> loader load order …but also sort of scary… reminds me of script > >>> tags > >>>>>>>> hell > >>>>>>>>>> > >>>>>>>>>> on that note: we need to make browserify thing first class. > >> whats > >>> the > >>>>>>>>> hold > >>>>>>>>>> up on that front? > >>>>>>>>>> > >>>>>>>>>> On Wed, Dec 10, 2014 at 12:47 PM, Michal Mocny < > >>> [email protected]> > >>>>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>>> 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 in the camp of preferring to match, and was under > >> the > >>>>>>>>>> assumption > >>>>>>>>>>> others here were too. > >>>>>>>>>>> > >>>>>>>>>>> Given the upcoming specs mentioned earlier (sockets, file, > >>>>>>>> filesystem, > >>>>>>>>>>> permissions, service worker, fetch), seems that fighting the > >>>>>>> adoption > >>>>>>>>> of > >>>>>>>>>>> promises in core apis implies opposing the adoption of modern > >> web > >>>>>>>>> specs. > >>>>>>>>>>> e.g. I'm assuming Andrew was referring to > >>>>>>>>>>> http://www.w3.org/TR/battery-status/, since matching that spec > >>>>>>>> *would* > >>>>>>>>>>> require promises. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Now, as I understand, you are not saying you are opposed to > >>>>>>> adoption > >>>>>>>> of > >>>>>>>>>>> promises in Cordova, but that you are simply against the > >>> inclusion > >>>>>>>> of a > >>>>>>>>>>> polyfill directly inside cordova-js. I think that a > >>>>>>>> promises-polyfill > >>>>>>>>>>> plugin alternative has some technical downsides [1], but they > >>> seem > >>>>>>>> not > >>>>>>>>> so > >>>>>>>>>>> insurmountable that we shouldn't just get passed this debate > >> and > >>> do > >>>>>>>>> that. > >>>>>>>>>>> > >>>>>>>>>>> In my opinion, we should prefer to create a common plugin (at > >>> least > >>>>>>>>> until > >>>>>>>>>>> browserify), since I really hope we don't tell devs to just > >>> include > >>>>>>>>> their > >>>>>>>>>>> own polyfill with each plugin. > >>>>>>>>>>> > >>>>>>>>>>> [1]: > >>>>>>>>>>> - Can't rely on a polyfill plugin for cordova-js itself. There > >>>>>>> are a > >>>>>>>>> few > >>>>>>>>>>> places where that may have been useful. > >>>>>>>>>>> - We don't currently load plugins in an order that respects > >>> plugin > >>>>>>>>>>> dependencies, so every plugin relying on promises-polyfill will > >>>>>>> have > >>>>>>>> to > >>>>>>>>>>> require() it at runtime before using and forgetting to do so > >>>>>>>>>>> may-or-may-not lead to an error. Maybe we just fix this in our > >>>>>>>> plugin > >>>>>>>>>>> loader. > >>>>>>>>>>> - It seems odd that window.Promise will exist depending on > >> which > >>>>>>>>> plugins > >>>>>>>>>>> you have installed. While this technically isn't different > >> than > >>>>>>> with > >>>>>>>>> any > >>>>>>>>>>> plugin modifying global symbols, it seems odd-er when applied > >> to > >>> a > >>>>>>>>>>> dependant platform feature. > >>>>>>>>>>> > >>>>>>>>>>> -Michal > >>>>>>>>>>> > >>>>>>>>>>> On Wed, Dec 10, 2014 at 1:56 PM, Jesse < > >> [email protected]> > >>>>>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>>> 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 this has zero > >> impact > >>>>>>> on > >>>>>>>>> what > >>>>>>>>>>> our > >>>>>>>>>>>> core-api looks like to a user. The same should apply to any > >>>>>>> plugin > >>>>>>>>> that > >>>>>>>>>>>> wants to depend on promises, just depend on a promise plugin, > >>>>>>> which > >>>>>>>>> may > >>>>>>>>>>> or > >>>>>>>>>>>> may not add polyfil code to the dom. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> @purplecabbage > >>>>>>>>>>>> risingj.com > >>>>>>>>>>>> > >>>>>>>>>>>> On Wed, Dec 10, 2014 at 9:41 AM, Brian LeRoux <[email protected]> > >>>>>>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> - 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 < > >>>>>>>>> [email protected] > >>>>>>>>>>> > >>>>>>>>>>>>> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>>> 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, 2014 at 10:35 AM, Ian Clelland < > >>>>>>>>>>> [email protected] > >>>>>>>>>>>>> > >>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On Wed Dec 10 2014 at 10:17:38 AM Andrew Grieve < > >>>>>>>>>>>> [email protected]> > >>>>>>>>>>>>>>> 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-status include the > >>>>>>>>> polyfill > >>>>>>>>>>>> within > >>>>>>>>>>>>>>> it? I > >>>>>>>>>>>>>>>> hope not. I'd hate to get to where several plugins in my > >>>>>>>> app > >>>>>>>>>> all > >>>>>>>>>>>>> bundle > >>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>> same polyfill. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I believe that Mozilla's new File API, which I think we're > >>>>>>>>>> planning > >>>>>>>>>>>> to > >>>>>>>>>>>>>>> implement, and which should be as core as File is now, is > >>>>>>>> also > >>>>>>>>>>>> heavily > >>>>>>>>>>>>>>> promises-based. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> If we move to having the entire cordova.js built using > >>>>>>>>>> browserify > >>>>>>>>>>>>> where > >>>>>>>>>>>>>>>> every plugin gets to contribute to the JS that goes into > >>>>>>>> it - > >>>>>>>>>>> yes I > >>>>>>>>>>>>> can > >>>>>>>>>>>>>>> see > >>>>>>>>>>>>>>>> this solving this use-case as well. But that also seems > >>>>>>> to > >>>>>>>> me > >>>>>>>>>>> like > >>>>>>>>>>>> a > >>>>>>>>>>>>>> much > >>>>>>>>>>>>>>>> larger and much more controversial change. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Whether you are for or against promises - they are > >>>>>>> already > >>>>>>>>>> here. > >>>>>>>>>>>> They > >>>>>>>>>>>>>>>> exists natively on most latest mobile webviews, and every > >>>>>>>>>> vendor > >>>>>>>>>>>> has > >>>>>>>>>>>>>>>> committed to adding them. And they are being used in > >>>>>>> *most* > >>>>>>>>> new > >>>>>>>>>>>> specs > >>>>>>>>>>>>>>> that > >>>>>>>>>>>>>>>> I've seen (sockets, filesystem, permissions, service > >>>>>>>> worker, > >>>>>>>>>>> fetch) > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Are there any concrete downsides to putting Promises > >>>>>>>> polyfill > >>>>>>>>>>> right > >>>>>>>>>>>>> in > >>>>>>>>>>>>>>>> cordova-js? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> As long as the promise doesn't clobber the native > >>>>>>>>> implementation, > >>>>>>>>>>> if > >>>>>>>>>>>> it > >>>>>>>>>>>>>>> exists, and we can remove it completely from platforms when > >>>>>>>>> they > >>>>>>>>>>>> don't > >>>>>>>>>>>>>> need > >>>>>>>>>>>>>>> it anymore, it seems to me like a small price for having > >>>>>>> this > >>>>>>>>>>>> available > >>>>>>>>>>>>>> to > >>>>>>>>>>>>>>> all platforms. (Other opinions vary, I'm sure, though) > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On Fri, Dec 5, 2014 at 4:39 PM, Joe Bowser < > >>>>>>>>> [email protected]> > >>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> +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 really wish specs wouldn't rely on code that > >>>>>>> only > >>>>>>>>>> exists > >>>>>>>>>>>> on > >>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>> very > >>>>>>>>>>>>>>>>> latest browsers. It just makes life harder on people > >>>>>>> who > >>>>>>>>> have > >>>>>>>>>>> to > >>>>>>>>>>>>>>>> implement > >>>>>>>>>>>>>>>>> stuff. > >>>>> > >>>>> --------------------------------------------------------------------- > >>>>> To unsubscribe, e-mail: [email protected] > >>>>> For additional commands, e-mail: [email protected] > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [email protected] > >>> For additional commands, e-mail: [email protected] > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
