Return-Path: X-Original-To: apmail-cordova-dev-archive@www.apache.org Delivered-To: apmail-cordova-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 368A210699 for ; Fri, 12 Dec 2014 20:26:03 +0000 (UTC) Received: (qmail 57000 invoked by uid 500); 12 Dec 2014 20:26:02 -0000 Delivered-To: apmail-cordova-dev-archive@cordova.apache.org Received: (qmail 56958 invoked by uid 500); 12 Dec 2014 20:26:02 -0000 Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cordova.apache.org Delivered-To: mailing list dev@cordova.apache.org Received: (qmail 56934 invoked by uid 99); 12 Dec 2014 20:26:01 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Dec 2014 20:26:01 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of purplecabbage@gmail.com designates 209.85.192.169 as permitted sender) Received: from [209.85.192.169] (HELO mail-pd0-f169.google.com) (209.85.192.169) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Dec 2014 20:25:57 +0000 Received: by mail-pd0-f169.google.com with SMTP id z10so7829546pdj.28 for ; Fri, 12 Dec 2014 12:25:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:mime-version:subject :message-id:date:references:in-reply-to:to; bh=eBeVtySYLaWvd8FPlGWPIKPML8CYarT6R4pUmhftAxQ=; b=FopQvruQ1ph+2HZez8xre0ZE6/Qp4lYdodBcOPJcTu7wr//1FSCcQLB2HFPIJm8iBq r5zIYTXVbeBWtDCuXpOYAfJzjiMqn34serPtnf8IF9bV9HUoqKw6PzueKgeMqM8ml8ol Xu8/vtBdtFll9P0HvYHZRwEvUFpyR+nN1+82a+m+v9WQ51pO8MlQhYhd6gohBSehQZLq tuD05NdjlsD6pjtPLGXayOfPfqQCdd9BJNKVDbmz00xJalbZnLgGB9P9LkPWlUelB+le fCaQxQVR+dwZtyOg5C8wy0zoVqYRevpRn2BBmpZm+Pr8+i++1ff4kdPUi5mjGST3V35g adZQ== X-Received: by 10.70.96.145 with SMTP id ds17mr29893832pdb.88.1418415936910; Fri, 12 Dec 2014 12:25:36 -0800 (PST) Received: from [10.24.102.57] ([166.170.39.105]) by mx.google.com with ESMTPSA id ou9sm2295846pbb.26.2014.12.12.12.25.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Dec 2014 12:25:35 -0800 (PST) From: Jesse Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Subject: Re: WebView Promise and W3C standards Message-Id: <1F046AB5-C24F-44BB-A2DF-C15EB56E0635@gmail.com> Date: Fri, 12 Dec 2014 12:25:34 -0800 References: In-Reply-To: To: "dev@cordova.apache.org" X-Mailer: iPhone Mail (12B436) X-Virus-Checked: Checked by ClamAV on apache.org Oops, I was wrong. My test works on the first page loaded, but any page aft= er that it does not. Your faith was well placed. I won't bother trying Andro= id, as no-iOS is a blocker.=20 > On Dec 12, 2014, at 11:55 AM, Andrew Grieve wrote: >=20 >> On Fri, Dec 12, 2014 at 2:28 PM, Jesse wrote: >>=20 >>> On Fri, Dec 12, 2014 at 11:10 AM, Shazron wrote: >>>=20 >>> Yup, WKWebView has an option to add a script at >>> WKUserScriptInjectionTimeAtDocumentStart. >>>=20 >>> On Fri, Dec 12, 2014 at 7:21 AM, Andrew Grieve >>> wrote: >>>> I believe there's not API to insert this early for Android / iOS other >>> than >>>> in the new WKWebView. >>=20 >> 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. >=20 >=20 >=20 >>=20 >>=20 >>=20 >>>>=20 >>>> On Thu, Dec 11, 2014 at 3:23 PM, Jesse >> wrote: >>>>=20 >>>>> 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? >>>>>=20 >>>>>>> On Dec 11, 2014, at 10:54 AM, Andrew Grieve >>>>>> wrote: >>>>>>=20 >>>>>> Let's start a new thread for browserify. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>>=20 >>>>>>> On Wed, Dec 10, 2014 at 8:35 PM, Brian LeRoux wrote: >>>>>>>=20 >>>>>>> we should move browserify to main and drop that insane concat code >>>>>>>=20 >>>>>>> its not heavyweight at all. it creates a hash in iife with deps >>> mapped >>>>>>> in=E2=80=A6as to why dep mgmt is better than concatenating=E2=80=A6I= don't think we >>>>> need to >>>>>>> waste our time talking about that! >>>>>>>=20 >>>>>>> On Wed, Dec 10, 2014 at 5:00 PM, Andrew Grieve < >> agrieve@chromium.org >>>>=20 >>>>>>> wrote: >>>>>>>=20 >>>>>>>> There's something implemented behind a --browserify flag, but not >>> sure >>>>>>> what >>>>>>>> it does. >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>>> On Wed, Dec 10, 2014 at 4:22 PM, Michal Mocny < >> mmocny@chromium.org >>>>=20 >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>> We haven't worked on it, also curious. Anis, perhaps? >>>>>>>>>=20 >>>>>>>>>> On Wed, Dec 10, 2014 at 4:08 PM, Brian LeRoux >> wrote: >>>>>>>>>>=20 >>>>>>>>>> def think we should support those specs in our great and fabled >>> api >>>>>>>>>> audit=E2=80=A6had not considered the load order issue >>>>>>>>>>=20 >>>>>>>>>> not insurmountable and probably should be a feature/fix for the >>>>>>> plugin >>>>>>>>>> loader load order =E2=80=A6but also sort of scary=E2=80=A6 remind= s me of script >>> tags >>>>>>>> hell >>>>>>>>>>=20 >>>>>>>>>> on that note: we need to make browserify thing first class. >> whats >>> the >>>>>>>>> hold >>>>>>>>>> up on that front? >>>>>>>>>>=20 >>>>>>>>>> On Wed, Dec 10, 2014 at 12:47 PM, Michal Mocny < >>> mmocny@chromium.org> >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> 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. >>>>>>>>>>>=20 >>>>>>>>>>> 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. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> 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. >>>>>>>>>>>=20 >>>>>>>>>>> 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. >>>>>>>>>>>=20 >>>>>>>>>>> [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. >>>>>>>>>>>=20 >>>>>>>>>>> -Michal >>>>>>>>>>>=20 >>>>>>>>>>> On Wed, Dec 10, 2014 at 1:56 PM, Jesse < >> purplecabbage@gmail.com> >>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> Why does battery-status 'require' promises? >>>>>>>>>>>>=20 >>>>>>>>>>>> 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? >>>>>>>>>>>>=20 >>>>>>>>>>>> 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. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> @purplecabbage >>>>>>>>>>>> risingj.com >>>>>>>>>>>>=20 >>>>>>>>>>>> On Wed, Dec 10, 2014 at 9:41 AM, Brian LeRoux >>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> - no technical benefit (but aesthetics, sure) >>>>>>>>>>>>> - adds weight (payload and runtime) >>>>>>>>>>>>> - might interfere with userland polly >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -1 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Wed, Dec 10, 2014 at 7:48 AM, Andrew Grieve < >>>>>>>>> agrieve@chromium.org >>>>>>>>>>>=20 >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> 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= >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> The actual need is for a setImmediate polyfill, but Promise >>>>>>>> does >>>>>>>>>> the >>>>>>>>>>>> same >>>>>>>>>>>>>> thing (with an extra object creation). >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On Wed, Dec 10, 2014 at 10:35 AM, Ian Clelland < >>>>>>>>>>> iclelland@chromium.org >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On Wed Dec 10 2014 at 10:17:38 AM Andrew Grieve < >>>>>>>>>>>> agrieve@chromium.org> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> userland means that plugins won't be able to use them >>>>>>>> unless >>>>>>>>>>> every >>>>>>>>>>>>>> plugin >>>>>>>>>>>>>>>> also includes a copy of the polyfill within it. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> 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) >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Are there any concrete downsides to putting Promises >>>>>>>> polyfill >>>>>>>>>>> right >>>>>>>>>>>>> in >>>>>>>>>>>>>>>> cordova-js? >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> 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) >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On Fri, Dec 5, 2014 at 4:39 PM, Joe Bowser < >>>>>>>>> bowserj@gmail.com> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> +1 to userland. I see other approaches causing more >>>>>>>>> problems. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> 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. >>>>>=20 >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org >>>>> For additional commands, e-mail: dev-help@cordova.apache.org >>>=20 >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org >>> For additional commands, e-mail: dev-help@cordova.apache.org >>=20 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org For additional commands, e-mail: dev-help@cordova.apache.org