Is there any way we can formalize this behavior in a native (or native +
JS) test (for any platform)?
On 1/30/13 10:11 AM, "Shazron" <shaz...@gmail.com> wrote:
>"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
>>
