On Fri, Dec 12, 2014 at 11:10 AM, Shazron <shaz...@gmail.com> wrote: > Yup, WKWebView has an option to add a script at > WKUserScriptInjectionTimeAtDocumentStart. > > On Fri, Dec 12, 2014 at 7:21 AM, Andrew Grieve <agri...@chromium.org> > 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. > > > > On Thu, Dec 11, 2014 at 3:23 PM, Jesse <purplecabb...@gmail.com> 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 <agri...@chromium.org> > >> 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 <b...@brian.io> 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 <agri...@chromium.org > > > >> >> 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 <mmo...@chromium.org > > > >> >>> wrote: > >> >>> > >> >>>> We haven't worked on it, also curious. Anis, perhaps? > >> >>>> > >> >>>>> On Wed, Dec 10, 2014 at 4:08 PM, Brian LeRoux <b...@brian.io> 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 < > mmo...@chromium.org> > >> >>>>> 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 <purplecabb...@gmail.com> > >> >>>> 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 <b...@brian.io> > >> >> 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 < > >> >>>> agri...@chromium.org > >> >>>>>> > >> >>>>>>>> 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 < > >> >>>>>> iclell...@chromium.org > >> >>>>>>>> > >> >>>>>>>>> wrote: > >> >>>>>>>>> > >> >>>>>>>>>> On Wed Dec 10 2014 at 10:17:38 AM Andrew Grieve < > >> >>>>>>> agri...@chromium.org> > >> >>>>>>>>>> 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 < > >> >>>> bows...@gmail.com> > >> >>>>>>>> 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: 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 > >
