You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Dan Mullins <dm...@gmail.com> on 2013/01/29 13:35:22 UTC
Global Javascript in InAppBrowser
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
Re: Global Javascript in InAppBrowser
Posted by Shazron <sh...@gmail.com>.
Another request (on my blog post comments) is for the InAppBrowser to
*follow* the whitelist:
http://shazronatadobe.wordpress.com/2012/12/10/whats-new-in-cordova-ios-2-3-0/#comment-4706
On Tue, Jan 29, 2013 at 2:40 PM, Andrew Grieve <ag...@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 <ag...@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 <dm...@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
> > >>
> >
>
Re: Global Javascript in InAppBrowser
Posted by Filip Maj <fi...@adobe.com>.
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" <sh...@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 <pu...@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 <ag...@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
>><ag...@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
>><dm...@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
>>
Re: Global Javascript in InAppBrowser
Posted by Shazron <sh...@gmail.com>.
"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 <pu...@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 <ag...@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 <ag...@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 <dm...@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
>
Re: Global Javascript in InAppBrowser
Posted by Jesse <pu...@gmail.com>.
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 <ag...@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 <ag...@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 <dm...@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
Re: Global Javascript in InAppBrowser
Posted by Andrew Grieve <ag...@chromium.org>.
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 <ag...@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 <dm...@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
> >>
>
Re: Global Javascript in InAppBrowser
Posted by Brian LeRoux <b...@brian.io>.
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 <ag...@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 <dm...@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
>>
Re: Global Javascript in InAppBrowser
Posted by Andrew Grieve <ag...@chromium.org>.
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 <dm...@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
>