Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: callback-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of braden@google.com designates
 209.85.210.175 as permitted sender)
MIME-Version: 1.0
Sender: braden@google.com
In-Reply-To: 
 <CABiQX1XCkZRzo9mV+AxNGjw8DBQ27eUfhzv6Zup5p+PqM+UwoQ@mail.gmail.com>
References: 
 <CAMk5LLny7mkUhkDbwcMC1RyNFDCuHfwmFMnjgYCr7yJ+2j61+Q@mail.gmail.com>
	<CADVgkyPZQN8S5CTdJirM2Veye=jE0FPW-MCjB2J3Jz-Y2+WhwQ@mail.gmail.com>
	<CAMk5LLn35DYmBf27H9bceN142LdTxkBfrFofVhDzY6Hx1Z2o1g@mail.gmail.com>
	<CAMT1KGPNS0wwgr9Ot=yxbZU-NGq+sfQ_x7miaGW=RTDELR70QQ@mail.gmail.com>
	<CAKP6k2tvCZk04avmwPPS28OmngjyaAPyJG-ig+tEprUMLUoseA@mail.gmail.com>
	<CADVgkyP+dUQMNRaoz0LHkpRuOCmAAOF7XMe0U+fW0o+UX2V0bQ@mail.gmail.com>
	<CABiQX1XCkZRzo9mV+AxNGjw8DBQ27eUfhzv6Zup5p+PqM+UwoQ@mail.gmail.com>
Date: Thu, 6 Sep 2012 11:27:42 -0400
Message-ID: 
 <CAMk5LL=6grR7neYEErvY9rJiQdoP2ZuhiHjj3HHsr85ovtuPZw@mail.gmail.com>
Subject: Re: Wiping plugins on navigation
From: Braden Shepherdson <braden@chromium.org>
To: callback-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=bcaec517ce76e845ca04c90a2137

--bcaec517ce76e845ca04c90a2137
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Repeating here a comment on the bug:

Jimmy Jarvis<https://issues.apache.org/jira/secure/ViewProfile.jspa?name=3D=
jiminyjarvis>
added
a comment - 05/Sep/12 23:02 - edited

JSON-P uses a unique callback identifier, similar to the proposed fix
above, and is far more reliable and easier to debug than reset with
repeating IDs. It would be unfortunate overhead to have to reinitialize our
native logic every time a page reloads. The app would become far less
responsive, at least for us. If a plugin is a bunch of stubs, it's not an
big deal as you say =96 however, if it is a longer running setup process --=
--
I'd prefer ignoring unmatched callbacks. I agree sending the plugin a Reset
or Terminate message would enable the plugin authors an opportunity to do
proper cleanup on pending requests, but even if they do not, unique ID's
(like JSON-P) are a better solution than repeating IDs.


On Wed, Sep 5, 2012 at 9:33 PM, Andrew Grieve <agrieve@chromium.org> wrote:

> Plugins could probably use static fields if they wanted to maintain some
> state between page changes. I think it should be extremely rare to do so
> though. e.g. For the platforms that implement their plugins in JS, is it
> even possible to maintain state between page changes?
>
> One nice outcome of this is that it will make our mobile-spec pages less
> likely to affect each other.
>
>
> On Wed, Sep 5, 2012 at 6:59 PM, Brian LeRoux <b@brian.io> wrote:
>
> > Yes I do not refuting Cordova needs to work for both single page and
> > multipage apps. Just saying there is a solution to this problem. ;P
> >
> >
> > On Wed, Sep 5, 2012 at 3:49 PM, Jesse <purplecabbage@gmail.com> wrote:
> > > Whether it is an edge case, or a common case, multi-page apps are a
> > > reality, so we definitely need to notify plugins when the page is
> > > changing.
> > > I don't necessarily agree that the plugin should be destroyed and
> > > recreated though, I can think of several cases where persistence woul=
d
> > > be nice to have.
> > >
> > > I also do not see this as a security issue.  Security is already
> > > governed by the white-list, so non-trusted pages cannot access device
> > > functions.  If a plugin needs additional security, then it should be
> > > built into the plugin, and not the responsibility of the framework.
> > > ... Thinking of a SuperCookie plugin which uses the domain of the
> > > currently loaded page before deciding what to return, or something
> > > similar.
> > >
> > > My 2 sense,
> > >   Jesse
> > >
> > >
> > > On Wed, Sep 5, 2012 at 3:30 PM, Bryce Curtis <curtis.bryce@gmail.com>
> > wrote:
> > >> Sometimes multi-page apps are needed or you navigate from your app t=
o
> > >> another page.  One bug we ran into was that callback ids are reused
> > >> when loading a new page.  So, a plugin trying to send data back to t=
he
> > >> original page could be calling a recycled plugin with erroneous data=
.
> > >> In addition to the bugs, there is also a security issue with a
> > >> subsequent page being able to access a plugin that was used in a
> > >> previous page.
> > >>
> > >> The app/page lifecycle events are propagated to the plugins, and the
> > >> plugins are destroyed when loading a new page.  However, looking at
> > >> the code, it appears this may be broken now.  (At least for Android)=
.
> > >>
> > >> On Wed, Sep 5, 2012 at 3:40 PM, Braden Shepherdson <
> braden@chromium.org>
> > wrote:
> > >>> Sure, and I'm a fan of single-page apps (I do work for Google, afte=
r
> > >>> all...), but this causes very chaotic, hard-to-track bugs, so it
> makes
> > >>> sense to be robust over a refresh/navigation.
> > >>>
> > >>>
> > >>> On Wed, Sep 5, 2012 at 5:25 PM, Brian LeRoux <b@brian.io> wrote:
> > >>>
> > >>>> One thing to note, we tend to advise ppl author single page web ap=
ps
> > >>>> which makes state visibility change an app logic concern (and avoi=
d
> > >>>> this issue from manifesting). Generally, we can say a page refresh
> is
> > >>>> not a great user experience in apps.
> > >>>>
> > >>>> On Wed, Sep 5, 2012 at 1:15 PM, Braden Shepherdson <
> > braden@chromium.org>
> > >>>> wrote:
> > >>>> > This is intended as a continuation of the discussion started in
> > >>>> > https://issues.apache.org/jira/browse/CB-1318 .
> > >>>> >
> > >>>> > The bug in question is one where one page starts a long native
> side
> > >>>> action
> > >>>> > such as a network call. Then the user navigates the app to anoth=
er
> > page.
> > >>>> > When the long action completes, the call returns and the
> appropriate
> > >>>> > Javascript callback is looked up and called.
> > >>>> >
> > >>>> > However when the page is navigated, the counter that provides
> > supposedly
> > >>>> > unique names for callbacks is reset, allowing a callback on the
> new
> > page
> > >>>> to
> > >>>> > have the same name as the callback from the old page. It then ge=
ts
> > called
> > >>>> > incorrectly, potentially introducing weird and transient bugs.
> > >>>> >
> > >>>> > The proposed solution is to do the following on navigation:
> > >>>> > - Call a destroy() call on all plugins, which by default does
> > nothing.
> > >>>> This
> > >>>> > allows the plugins a chance to cancel any outstanding network
> > requests or
> > >>>> > do any other cleanup work.
> > >>>> > - Delete the plugin instance and recreate it.
> > >>>> >
> > >>>> > In the bug I also said one step would be to wipe the callback
> table
> > in
> > >>>> the
> > >>>> > Javascript, but that isn't necessary since it would have been
> wiped
> > by
> > >>>> the
> > >>>> > navigation anyway.
> > >>>> >
> > >>>> > This issue is cross-platform-ish. It (probably) doesn't apply to
> > >>>> web-based
> > >>>> > platforms like WebOS or Bada, because the plugins are Javascript
> > shims
> > >>>> > rather than native code, and are wiped on navigation like any
> other
> > >>>> > Javascript. However this issue does exist on at least Android an=
d
> > iOS,
> > >>>> and
> > >>>> > probably a few others as well.
> > >>>> >
> > >>>> > I'm proposing to implement the solution outlined above on Androi=
d
> > and
> > >>>> iOS.
> > >>>> > I don't have the devices or environment to do any other platform=
s,
> > nor
> > >>>> am I
> > >>>> > sure which are necessary. The maintainers of other platforms wil=
l
> > have to
> > >>>> > consider this problem for their platform. I would also update th=
e
> > core
> > >>>> > plugins to define a destroy() method if they have relevant
> cleanups
> > to
> > >>>> make.
> > >>>> >
> > >>>> > Thoughts on the approach, things I'm missing?
> > >>>> >
> > >>>> > Braden
> > >>>>
> > >
> > >
> > >
> > > --
> > > @purplecabbage
> > > risingj.com
> >
>

--bcaec517ce76e845ca04c90a2137--