cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Braden Shepherdson <bra...@chromium.org>
Subject Re: inAppBrowser API issue
Date Tue, 28 May 2013 15:09:58 GMT
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.li@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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message