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 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
