cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: WebView Promise and W3C standards
Date Fri, 12 Dec 2014 19:55:05 GMT
On Fri, Dec 12, 2014 at 2:28 PM, Jesse <purplecabbage@gmail.com> wrote:

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