cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse <purplecabb...@gmail.com>
Subject Re: WebView Promise and W3C standards
Date Fri, 12 Dec 2014 19:28:08 GMT
On Fri, Dec 12, 2014 at 11:10 AM, Shazron <shazron@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 <agrieve@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.



> >
> > 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message