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 <[email protected]> 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 would > 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 <[email protected]> wrote: >> 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 >>>> > > > > -- > @purplecabbage > risingj.com
