You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by "Li, Jonathan" <jo...@sap.com> on 2013/05/28 16:47:40 UTC
inAppBrowser API issue
Not sure whether this is a right place for this issue, but the javascript
interface for InAppBrowser does not make much sense. The below code is
from cordova document:
var ref = window.open('http://apache.org', '_blank', 'location=yes');
ref.addEventListener('loadstart', function() { alert(event.url); });
The event handler is added after the open method is returned, so it is
possible the event gets fired before developer has a chance to add the
event handler for the open operation. Although it is async operation, it
is still a good design, and may cause timing or other issues depending on
native side implementation.
Just wonder whether this is a known issue, or could it be changed to a
better interface design?
Thanks
Jonathan
Re: inAppBrowser API issue
Posted by Andrew Grieve <ag...@chromium.org>.
I'd be open to discussing a different API.
I like using window.open() for the simple case, but as we add more
non-standard APIs to it (e.g. insertCSS, evaluateJavascript, and upcoming:
.show()), then I think it would make more sense to just have a custom API
instead of using window.open.
On Tue, May 28, 2013 at 12:08 PM, Braden Shepherdson <br...@google.com>wrote:
> This is not an accident of Javascript implementations that we're relying
> on. It is absolutely essential and fully specified that Javascript engines
> have this async behavior. One task completes before any others run.
>
> The handling of onError is our responsibility; I assume that our code uses
> setTimeout(..., 0); to enqueue the error in a new task, and give the user
> code a chance to add handlers. Take a look at the (standard) IndexedDB API;
> it is packed with this style.
>
> Braden
>
>
> On Tue, May 28, 2013 at 12:04 PM, Li, Jonathan <jo...@sap.com>
> wrote:
>
> > It is a little bit different from window.open defined by w3c. As
> > window.open, the onload, onerror events can be embedded in the html page,
> > they will be automatically attached to DOM when parsing the page, there
> is
> > no need to add the event handler by separate calls, so no event will be
> > missed.
> >
> > In fact, if calling the similar code shown below on a regular page, the
> > onload method will not be called.
> >
> > var ref = window.open('http://apache.org');
> > ref.addEventListener('loadstart', function() { alert(event.url); });
> >
> >
> > The design should not heavily depend on the current browser's javascript
> > thread implementation. Besides it is not safe to always assume the event
> > will only be fired asynchronously from native code. For example, if
> invalid
> > parameters are passed to open method, the validator may need to call
> > onError to report the error, it will not work if onError event handler
> > cannot be added before the operation.
> >
> > Jonathan
> >
> >
> > -----Original Message-----
> > From: braden@google.com [mailto:braden@google.com] On Behalf Of Braden
> > Shepherdson
> > Sent: Tuesday, May 28, 2013 11:10 AM
> > To: dev@cordova.apache.org
> > Subject: Re: inAppBrowser API issue
> >
> > If the event really did fire before the event listener was added, the
> > Javascript engine is broken. When the event is triggered (which may
> happen
> > in another browser thread or something) it will be added to the event
> queue
> > in the Javascript engine. That event will not be processed until the
> > currently executing Javascript chunk is done - the next time the
> Javascript
> > cedes control (setTimeout, returning from all functions, etc.). That
> won't
> > happen until after the event handler is attached in the second line.
> >
> > We didn't design this API, it's the same window.open API is is used
> > elsewhere. Cordova tends to use existing W3C specs where appropriate.
> >
> > Braden
> >
> >
> > On Tue, May 28, 2013 at 10:47 AM, Li, Jonathan <jo...@sap.com>
> > wrote:
> >
> > > Not sure whether this is a right place for this issue, but the
> javascript
> > > interface for InAppBrowser does not make much sense. The below code is
> > > from cordova document:
> > >
> > > var ref = window.open('http://apache.org', '_blank', 'location=yes');
> > > ref.addEventListener('loadstart', function() { alert(event.url); });
> > >
> > > The event handler is added after the open method is returned, so it is
> > > possible the event gets fired before developer has a chance to add the
> > > event handler for the open operation. Although it is async operation,
> it
> > > is still a good design, and may cause timing or other issues depending
> on
> > > native side implementation.
> > >
> > > Just wonder whether this is a known issue, or could it be changed to a
> > > better interface design?
> > >
> > > Thanks
> > > Jonathan
> > >
> > >
> >
>
Re: inAppBrowser API issue
Posted by Braden Shepherdson <br...@google.com>.
This is not an accident of Javascript implementations that we're relying
on. It is absolutely essential and fully specified that Javascript engines
have this async behavior. One task completes before any others run.
The handling of onError is our responsibility; I assume that our code uses
setTimeout(..., 0); to enqueue the error in a new task, and give the user
code a chance to add handlers. Take a look at the (standard) IndexedDB API;
it is packed with this style.
Braden
On Tue, May 28, 2013 at 12:04 PM, Li, Jonathan <jo...@sap.com> wrote:
> It is a little bit different from window.open defined by w3c. As
> window.open, the onload, onerror events can be embedded in the html page,
> they will be automatically attached to DOM when parsing the page, there is
> no need to add the event handler by separate calls, so no event will be
> missed.
>
> In fact, if calling the similar code shown below on a regular page, the
> onload method will not be called.
>
> var ref = window.open('http://apache.org');
> ref.addEventListener('loadstart', function() { alert(event.url); });
>
>
> The design should not heavily depend on the current browser's javascript
> thread implementation. Besides it is not safe to always assume the event
> will only be fired asynchronously from native code. For example, if invalid
> parameters are passed to open method, the validator may need to call
> onError to report the error, it will not work if onError event handler
> cannot be added before the operation.
>
> Jonathan
>
>
> -----Original Message-----
> From: braden@google.com [mailto:braden@google.com] On Behalf Of Braden
> Shepherdson
> Sent: Tuesday, May 28, 2013 11:10 AM
> To: dev@cordova.apache.org
> Subject: Re: inAppBrowser API issue
>
> If the event really did fire before the event listener was added, the
> Javascript engine is broken. When the event is triggered (which may happen
> in another browser thread or something) it will be added to the event queue
> in the Javascript engine. That event will not be processed until the
> currently executing Javascript chunk is done - the next time the Javascript
> cedes control (setTimeout, returning from all functions, etc.). That won't
> happen until after the event handler is attached in the second line.
>
> We didn't design this API, it's the same window.open API is is used
> elsewhere. Cordova tends to use existing W3C specs where appropriate.
>
> Braden
>
>
> On Tue, May 28, 2013 at 10:47 AM, Li, Jonathan <jo...@sap.com>
> wrote:
>
> > Not sure whether this is a right place for this issue, but the javascript
> > interface for InAppBrowser does not make much sense. The below code is
> > from cordova document:
> >
> > var ref = window.open('http://apache.org', '_blank', 'location=yes');
> > ref.addEventListener('loadstart', function() { alert(event.url); });
> >
> > The event handler is added after the open method is returned, so it is
> > possible the event gets fired before developer has a chance to add the
> > event handler for the open operation. Although it is async operation, it
> > is still a good design, and may cause timing or other issues depending on
> > native side implementation.
> >
> > Just wonder whether this is a known issue, or could it be changed to a
> > better interface design?
> >
> > Thanks
> > Jonathan
> >
> >
>
RE: inAppBrowser API issue
Posted by "Li, Jonathan" <jo...@sap.com>.
It is a little bit different from window.open defined by w3c. As window.open, the onload, onerror events can be embedded in the html page, they will be automatically attached to DOM when parsing the page, there is no need to add the event handler by separate calls, so no event will be missed.
In fact, if calling the similar code shown below on a regular page, the onload method will not be called.
var ref = window.open('http://apache.org');
ref.addEventListener('loadstart', function() { alert(event.url); });
The design should not heavily depend on the current browser's javascript thread implementation. Besides it is not safe to always assume the event will only be fired asynchronously from native code. For example, if invalid parameters are passed to open method, the validator may need to call onError to report the error, it will not work if onError event handler cannot be added before the operation.
Jonathan
-----Original Message-----
From: braden@google.com [mailto:braden@google.com] On Behalf Of Braden Shepherdson
Sent: Tuesday, May 28, 2013 11:10 AM
To: dev@cordova.apache.org
Subject: Re: inAppBrowser API issue
If the event really did fire before the event listener was added, the
Javascript engine is broken. When the event is triggered (which may happen
in another browser thread or something) it will be added to the event queue
in the Javascript engine. That event will not be processed until the
currently executing Javascript chunk is done - the next time the Javascript
cedes control (setTimeout, returning from all functions, etc.). That won't
happen until after the event handler is attached in the second line.
We didn't design this API, it's the same window.open API is is used
elsewhere. Cordova tends to use existing W3C specs where appropriate.
Braden
On Tue, May 28, 2013 at 10:47 AM, Li, Jonathan <jo...@sap.com> wrote:
> Not sure whether this is a right place for this issue, but the javascript
> interface for InAppBrowser does not make much sense. The below code is
> from cordova document:
>
> var ref = window.open('http://apache.org', '_blank', 'location=yes');
> ref.addEventListener('loadstart', function() { alert(event.url); });
>
> The event handler is added after the open method is returned, so it is
> possible the event gets fired before developer has a chance to add the
> event handler for the open operation. Although it is async operation, it
> is still a good design, and may cause timing or other issues depending on
> native side implementation.
>
> Just wonder whether this is a known issue, or could it be changed to a
> better interface design?
>
> Thanks
> Jonathan
>
>
Re: inAppBrowser API issue
Posted by Braden Shepherdson <br...@chromium.org>.
If the event really did fire before the event listener was added, the
Javascript engine is broken. When the event is triggered (which may happen
in another browser thread or something) it will be added to the event queue
in the Javascript engine. That event will not be processed until the
currently executing Javascript chunk is done - the next time the Javascript
cedes control (setTimeout, returning from all functions, etc.). That won't
happen until after the event handler is attached in the second line.
We didn't design this API, it's the same window.open API is is used
elsewhere. Cordova tends to use existing W3C specs where appropriate.
Braden
On Tue, May 28, 2013 at 10:47 AM, Li, Jonathan <jo...@sap.com> wrote:
> Not sure whether this is a right place for this issue, but the javascript
> interface for InAppBrowser does not make much sense. The below code is
> from cordova document:
>
> var ref = window.open('http://apache.org', '_blank', 'location=yes');
> ref.addEventListener('loadstart', function() { alert(event.url); });
>
> The event handler is added after the open method is returned, so it is
> possible the event gets fired before developer has a chance to add the
> event handler for the open operation. Although it is async operation, it
> is still a good design, and may cause timing or other issues depending on
> native side implementation.
>
> Just wonder whether this is a known issue, or could it be changed to a
> better interface design?
>
> Thanks
> Jonathan
>
>