incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: Wiping plugins on navigation
Date Wed, 05 Sep 2012 22:59:45 GMT
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 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 <curtis.bryce@gmail.com> 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 <braden@chromium.org> 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 <b@brian.io> 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 <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 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

Mime
View raw message