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 <agri...@chromium.org> wrote: > >> 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 >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
