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 <bra...@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 <jonathan...@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: bra...@google.com [mailto:bra...@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 <jonathan...@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
> > >
> > >
> >
>
