incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryce Curtis <>
Subject Re: Wiping plugins on navigation
Date Wed, 05 Sep 2012 22:30:58 GMT
Sometimes multi-page apps are needed or you navigate from your app to
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 the
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 <> wrote:
> Sure, and I'm a fan of single-page apps (I do work for Google, after
> 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 <> wrote:
>> One thing to note, we tend to advise ppl author single page web apps
>> which makes state visibility change an app logic concern (and avoid
>> 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 <>
>> wrote:
>> > This is intended as a continuation of the discussion started in
>> > .
>> >
>> > 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 another 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 gets 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 and iOS,
>> and
>> > probably a few others as well.
>> >
>> > I'm proposing to implement the solution outlined above on Android and
>> iOS.
>> > I don't have the devices or environment to do any other platforms, nor
>> am I
>> > sure which are necessary. The maintainers of other platforms will have to
>> > consider this problem for their platform. I would also update the core
>> > plugins to define a destroy() method if they have relevant cleanups to
>> make.
>> >
>> > Thoughts on the approach, things I'm missing?
>> >
>> > Braden

View raw message