"Right now it seems every call to window.open is going to give you a new
instance" --> on iOS it is re-used.
I suppose we could handle those implied handlers, those are just JavaScript
changes I believe
On Tue, Jan 29, 2013 at 10:40 PM, Jesse <purplecabb...@gmail.com> wrote:
> The original interface was simply to allow the host code to monitor
> location changes. This allows for oauth workflows.
> Data can(?) be passed back and forth via a query string param *afaik*.
> Supporting window.opener is full of blockers, not just async issues, but
> also security.
>
> I think the inappbrowser instance 'should' support having it's location
> changed by the host app, this was there in the original ChildBrowser.
> Right now it seems every call to window.open is going to give you a new
> instance, when what you probably want to do in some cases is to re-use it.
>
> If we are evaluating this API, I also think we need to support the
> 'implied' apis
> ex. var ref = window.open(...)
>
> Currently we support ref.addEventListener, ref.removeEventListener,
> (loadstart, loadstop, exit)
> but not the implied:
> ref.onloadstart, ref.onloadstop, ref.onexit
> and also, we should possibly support
> ref.addEventListener("loadstart",{ handleEvent:function(evt) { } } ); //
> which is part of the addEventListener intrinsic api
>
>
>
> On Tue, Jan 29, 2013 at 2:40 PM, Andrew Grieve <agri...@chromium.org>
> wrote:
>
> > Pretty much the only API we could support on window.opener is
> > postMessage().
> >
> > We might want to consider exposing a separate interface from
> window.open()
> > for activating an InAppBrowser that you want to do more with (e.g. listen
> > to events, inject JS/CSS).
> >
> >
> > On Tue, Jan 29, 2013 at 5:24 PM, Brian LeRoux <b...@brian.io> wrote:
> >
> > > Would it be possible to implement window.opener ??
> > >
> > > I'm thinking no, due to the async nature of stuff, but allergic to
> > > introducing more non-standard API surface. It might be time to start
> > > documenting where Cordova MUST diverge so we can socialize this w/ the
> > > various standards groups we interact with.
> > >
> > > On Tue, Jan 29, 2013 at 9:15 AM, Andrew Grieve <agri...@chromium.org>
> > > wrote:
> > > > No.
> > > >
> > > > We do plan to support asynchronous JS communication in the future
> > though.
> > > > We didn't have a bug for it, so I've now created one:
> > > > https://issues.apache.org/jira/browse/CB-2305
> > > >
> > > > On Tue, Jan 29, 2013 at 7:35 AM, Dan Mullins <dmullin...@gmail.com>
> > > wrote:
> > > >
> > > >> If I open a local file in the InAppBrowser, can it communicate via
> > > >> javascript to the main application?
> > > >>
> > > >> For instance, if index.html defines the global function doSomething
> > > >> and opens local.html:
> > > >>
> > > >> function doSomething(input) {
> > > >> alert('hello ' + input)
> > > >> }
> > > >>
> > > >> document.addEventListener("deviceready", onDeviceReady, false);
> > > >>
> > > >> function onDeviceReady() {
> > > >> iabRef = window.open('local.html', '_blank',
> 'location=yes');
> > > >> }
> > > >>
> > > >> Can local.html call doSomething?
> > > >> function init() {
> > > >> doSomething('child view');
> > > >> }
> > > >>
> > > >> I'm not having any success and want to make sure I'm not missing
> > > something.
> > > >>
> > > >> Dan
> > > >>
> > >
> >
>
>
>
> --
> @purplecabbage
> risingj.com
>
