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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 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 >>
