cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: WebView Promise and W3C standards
Date Fri, 12 Dec 2014 19:10:27 GMT
Yup, WKWebView has an option to add a script at
WKUserScriptInjectionTimeAtDocumentStart.

On Fri, Dec 12, 2014 at 7:21 AM, Andrew Grieve <agrieve@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 <purplecabbage@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 <agrieve@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 <agrieve@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 <mmocny@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 <mmocny@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 <purplecabbage@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 <
>> >>>> agrieve@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
<
>> >>>>>> iclelland@chromium.org
>> >>>>>>>>
>> >>>>>>>>> wrote:
>> >>>>>>>>>
>> >>>>>>>>>> On Wed Dec 10 2014 at 10:17:38 AM Andrew
Grieve <
>> >>>>>>> agrieve@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 <
>> >>>> bowserj@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-unsubscribe@cordova.apache.org
>> For additional commands, e-mail: dev-help@cordova.apache.org
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org


Mime
View raw message