Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (athena.apache.org: domain of braden@google.com designates
 209.85.214.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <71D9CE88E9AC0C4F8C91CE1D3D4DC99301FAF299@DEWDFEMB18A.global.corp.sap>
References: 
 <CAM2q_Uzc_UxQhPTBqZKeCm8P1rPzwNDjmP4oLnTFbCmqWNZCZQ@mail.gmail.com>
	<CDCA3A45.7B3E%jonathan.li@sap.com>
	<CAMk5LLk-YJM0eOSWyy8pPQrEhnduRTJypAfNGf9UxOkM=qjMzA@mail.gmail.com>
	<71D9CE88E9AC0C4F8C91CE1D3D4DC99301FAF299@DEWDFEMB18A.global.corp.sap>
Date: Tue, 28 May 2013 12:08:04 -0400
Message-ID: 
 <CAMk5LL=BSAycpbhL1c_sioe-1-_shfHz6xAxD71=K2Z6MMqecQ@mail.gmail.com>
Subject: Re: inAppBrowser API issue
From: Braden Shepherdson <braden@google.com>
To: "Li, Jonathan" <jonathan.li@sap.com>
Cc: "dev@cordova.apache.org" <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=20cf303346d75c126f04ddc9783d

--20cf303346d75c126f04ddc9783d
Content-Type: text/plain; charset=ISO-8859-1

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.li@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 <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
> >
> >
>

--20cf303346d75c126f04ddc9783d--