On Fri, Dec 12, 2014 at 2:28 PM, Jesse <purplecabb...@gmail.com> wrote:
> 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. > 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 <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 > > > > >
