I don't think there's even been an issue opened for it. Seems like maybe the proper thing to do here though, is to move the pause/resumeTimers logic into CordovaActivity since they apply to all webviews.
On Thu, Oct 16, 2014 at 2:29 PM, Joe Bowser <bows...@gmail.com> wrote: > So, what's going on with this? Did this land in any release of Cordova? > > On Fri, Sep 12, 2014 at 12:24 PM, Joe Bowser <bows...@gmail.com> wrote: > > > > > > > On Fri, Sep 12, 2014 at 10:34 AM, Archana Naik <naik.arch...@gmail.com> > > wrote: > > > >> We have tested this behavior and in fact AmazonWebView which was and is > >> always based on chromium, we recommend to pause/resume timers in order > to > >> manage resources. > >> > > > > So, it works on the Amazon Chromium build? > > > > The more things change, the more they stay the same! We should probably > > adopt the changes that Andrew did, and the patch from Crosswalk, since > I'd > > rather have it be our problem than it being all over the place. > > > > > >> > >> On Fri, Sep 12, 2014 at 10:21 AM, Andrew Grieve <agri...@chromium.org> > >> wrote: > >> > >> > On Fri, Sep 12, 2014 at 1:02 PM, Joe Bowser <bows...@gmail.com> > wrote: > >> > > After testing this again for sanity, we should probably kill this > >> option. > >> > > I don't like it (in fact I hate it), but resumeTimers doesn't > >> actually > >> > > resume the timers on KitKat, and since other browsers may not even > >> > support > >> > > this, we have to add a bunch of buggy Javascript that will be prone > to > >> > > breaking instead of buggy Chromium code that's prone to breaking. > >> > > >> > Which part did you test (what do you mean by "this")? I've not seen > >> > resumeTimers() fail to work. > >> > > >> > > > >> > > I still wish someone other than me actually bothered testing this > and > >> > > showing what they had. > >> > > > >> > > On Fri, Sep 12, 2014 at 5:10 AM, Ian Clelland < > iclell...@chromium.org > >> > > >> > > wrote: > >> > > > >> > >> The patch that they applied was actually taken from the > >> > >> Cordova-crosswalk-engine plugin, so in this case, they're keeping > up > >> > with > >> > >> us :) > >> > >> > >> > >> And yeah, once we get this all sorted out, it should be documented. > >> > >> > >> > >> On Fri, Sep 12, 2014 at 1:55 AM, Andrey Kurdumov < > >> > kant2...@googlemail.com> > >> > >> wrote: > >> > >> > >> > >> > Hi, > >> > >> > > >> > >> > I periodically check how Crosswalk engine developed and seen that > >> they > >> > >> land > >> > >> > functionality which you are discussing today/yesterday > >> > >> > > >> > > https://github.com/crosswalk-project/crosswalk-cordova-android/pull/136 > >> > >> > > >> > >> > Maybe there make sense keep compatibility with them too. Or at > >> least > >> > if > >> > >> > timers would be paused, this should be documented. > >> > >> > Would be good if alternative engines have compatible lifecycle as > >> > much as > >> > >> > possible. > >> > >> > > >> > >> > Best regargs, > >> > >> > Andrey Kurdyumov > >> > >> > > >> > >> > > >> > >> > 2014-09-12 0:58 GMT+06:00 Andrew Grieve <agri...@chromium.org>: > >> > >> > > >> > >> > > I guess I can see the value of providing a safety option for > >> "pause > >> > my > >> > >> > > app in the background", but in general I think it's better > >> practice > >> > to > >> > >> > > not pause forcefully, and instead have apps listen to the > "pause" > >> > >> > > event, and stop battery-draining activity there instead. So... > >> let's > >> > >> > > keep the option in, and keep it off by default. > >> > >> > > > >> > >> > > Joe / Tommy - not sure from your comments as to whether they > were > >> > >> > > directed at the idea of removing the option completely, or to > the > >> > >> > > patch I sent that gets rid of unconditionally pausing timers > >> during > >> > >> > > startActivityForResult flows. Really can't see why you'd want > >> that, > >> > >> > > and I think it would just cause subtle bugs. > >> > >> > > > >> > >> > > On Wed, Sep 10, 2014 at 8:42 PM, Tommy Williams < > >> to...@devgeeks.org > >> > > > >> > >> > > wrote: > >> > >> > > > Biiiiig -1 for breaking current background behaviour. > >> > >> > > > > >> > >> > > > Or am I misunderstanding? > >> > >> > > > On 11 Sep 2014 10:34, "Joe Bowser" <bows...@gmail.com> > wrote: > >> > >> > > > > >> > >> > > >> Pausing timers means that the JS isn't running in the > >> background > >> > at > >> > >> > all. > >> > >> > > >> This now means that the Javascript is running constantly, > >> > >> regardless > >> > >> > of > >> > >> > > >> whether it's an event. This means that setInterval is still > >> > >> running. > >> > >> > > This > >> > >> > > >> could break people's applications. > >> > >> > > >> > >> > >> > > >> On Wed, Sep 10, 2014 at 5:29 PM, Andrew Grieve < > >> > >> agri...@chromium.org> > >> > >> > > >> wrote: > >> > >> > > >> > >> > >> > > >> > Getting off track here a bit. > >> > >> > > >> > > >> > >> > > >> > Here's what I'm suggesting with my original email: > >> > >> > > >> > > >> > >> > > >> > > >> > >> > > >> > >> > >> > > > >> > >> > > >> > >> > >> > > >> > https://github.com/agrieve/cordova-android/compare/apache:4.0.x...no_disable_timers?expand=1 > >> > >> > > >> > > >> > >> > > >> > I was further asking if there was any use in ever pausing > >> > timers > >> > >> > (aka, > >> > >> > > >> > removing the KeepRunning preference). > >> > >> > > >> > > >> > >> > > >> > > >> > >> > > >> > > >> > >> > > >> > On Wed, Sep 10, 2014 at 4:56 PM, Brian LeRoux <b...@brian.io > > > >> > wrote: > >> > >> > > >> > > I consider 4 a release branch. Merge in tested green lit > >> > code to > >> > >> > > your > >> > >> > > >> > > hearts desire but 4.0 is definitely not a feature. It > >> should > >> > be > >> > >> > > always > >> > >> > > >> > in a > >> > >> > > >> > > releasable state. > >> > >> > > >> > > On Sep 10, 2014 1:53 PM, "Michal Mocny" < > >> mmo...@chromium.org > >> > > > >> > >> > > wrote: > >> > >> > > >> > > > >> > >> > > >> > >> Question is, do you consider the fact that bugs are > >> > introduced > >> > >> & > >> > >> > > >> > discovered > >> > >> > > >> > >> (possibly with pain) a sign that the system is broken, > >> or a > >> > >> sign > >> > >> > > that > >> > >> > > >> > the > >> > >> > > >> > >> system is working? > >> > >> > > >> > >> > >> > >> > > >> > >> I sense that Andrew worries that if work has to land > on a > >> > >> feature > >> > >> > > >> > branch of > >> > >> > > >> > >> this feature branch, it won't get eyeballs. > >> > >> > > >> > >> > >> > >> > > >> > >> I sense that Joe worries that if we land > >> > everything/anything in > >> > >> > > >> > Android-4.0 > >> > >> > > >> > >> it will become unstable, as mistakes are prone to > happen > >> > (see > >> > >> > i.e. > >> > >> > > >> > recent > >> > >> > > >> > >> issue with black background). > >> > >> > > >> > >> > >> > >> > > >> > >> Personally, I prefer eyeballs and instability to > delayed > >> > >> > discovery > >> > >> > > >> and a > >> > >> > > >> > >> sense of stability, especially for a feature branch > like > >> > >> > > Android-4.0. > >> > >> > > >> > >> There are workarounds for demos (i.e. create your own > >> > branch > >> > >> off > >> > >> > > of a > >> > >> > > >> > >> known working version), but its not as easy to solve > the > >> > >> eyeball > >> > >> > > >> > problem. > >> > >> > > >> > >> > >> > >> > > >> > >> -Michal > >> > >> > > >> > >> > >> > >> > > >> > >> On Wed, Sep 10, 2014 at 3:50 PM, Joe Bowser < > >> > bows...@gmail.com > >> > >> > > >> > >> > > >> wrote: > >> > >> > > >> > >> > >> > >> > > >> > >> > I think this needs to be thought through more, and > I'm > >> > >> > extremely > >> > >> > > >> wary > >> > >> > > >> > >> when > >> > >> > > >> > >> > you say this is a single commit, especially based on > >> the > >> > last > >> > >> > > couple > >> > >> > > >> > of > >> > >> > > >> > >> > months and how long it took 3.6 to go through. Given > >> > that we > >> > >> > > have > >> > >> > > >> > people > >> > >> > > >> > >> > travelling halfway across the planet who intend to > show > >> > >> people > >> > >> > > their > >> > >> > > >> > work > >> > >> > > >> > >> > in less than two weeks, I would definitely like it if > >> you > >> > >> were > >> > >> > to > >> > >> > > >> put > >> > >> > > >> > >> this > >> > >> > > >> > >> > in your own branch for testing. > >> > >> > > >> > >> > > >> > >> > > >> > >> > On Wed, Sep 10, 2014 at 12:41 PM, Andrew Grieve < > >> > >> > > >> agri...@chromium.org > >> > >> > > >> > > > >> > >> > > >> > >> > wrote: > >> > >> > > >> > >> > > >> > >> > > >> > >> > > I don't think there'd be much value in that. It'll > >> be a > >> > >> > single > >> > >> > > >> > commit > >> > >> > > >> > >> > > that almost entirely just deletes lines. > >> > >> > > >> > >> > > > >> > >> > > >> > >> > > What do you think about the never auto-pausing on > >> > >> > > backgrounding? > >> > >> > > >> or > >> > >> > > >> > >> > > about auto-pausing when intent sending? > >> > >> > > >> > >> > > > >> > >> > > >> > >> > > On Wed, Sep 10, 2014 at 12:32 PM, Joe Bowser < > >> > >> > > bows...@gmail.com> > >> > >> > > >> > >> wrote: > >> > >> > > >> > >> > > > Can you put this on its own branch before it > lands > >> in > >> > >> > 4.0.x? > >> > >> > > >> > That'd > >> > >> > > >> > >> be > >> > >> > > >> > >> > > > awesome! > >> > >> > > >> > >> > > > > >> > >> > > >> > >> > > > On Tue, Sep 9, 2014 at 5:32 PM, Andrew Grieve < > >> > >> > > >> > agri...@chromium.org> > >> > >> > > >> > >> > > wrote: > >> > >> > > >> > >> > > >> > >> > >> > > >> > >> > > >> For cordova-android 4.0, I'd like to go as far > as > >> > just > >> > >> > > deleting > >> > >> > > >> > the > >> > >> > > >> > >> > > >> "KeepRunning" <preference>. > >> > >> > > >> > >> > > >> > >> > >> > > >> > >> > > >> Apps get a "pause" event when they are > >> backgrounded, > >> > and > >> > >> > > they > >> > >> > > >> > can do > >> > >> > > >> > >> > > >> any pause-type logic there (e.g. unlisten to > >> > >> accelerometer > >> > >> > > >> > events or > >> > >> > > >> > >> > > >> pausing audio). > >> > >> > > >> > >> > > >> > >> > >> > > >> > >> > > >> Any strong objections? > >> > >> > > >> > >> > > >> > >> > >> > > >> > >> > > >> On Tue, Sep 9, 2014 at 4:27 PM, Andrew Grieve < > >> > >> > > >> > agri...@chromium.org > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> wrote: > >> > >> > > >> > >> > > >> > Commit description: If multitasking is turned > on > >> > >> > > >> > >> (keepRunning=true), > >> > >> > > >> > >> > > >> > then temporarily disable it when starting a > new > >> > >> activity > >> > >> > > that > >> > >> > > >> > >> > returns > >> > >> > > >> > >> > > >> > a result - such as camera. > >> > >> > > >> > >> > > >> > > >> > >> > > >> > >> > > >> > > >> > >> > > >> > >> > > >> > > >> > >> > > >> > >> > > > >> > >> > > >> > >> > > >> > >> > > >> > >> > >> > >> > > >> > > >> > >> > > >> > >> > >> > > > >> > >> > > >> > >> > >> > > >> > https://github.com/apache/cordova-android/commit/26adfb634651196106fb5b66f15eecb535a06d82 > >> > >> > > >> > >> > > >> > > >> > >> > > >> > >> > > >> > Bryce / anyone - clues as to *why* we'd want > to > >> > >> disable > >> > >> > JS > >> > >> > > >> > timers > >> > >> > > >> > >> > when > >> > >> > > >> > >> > > >> > firing off an intent? > >> > >> > > >> > >> > > > > >> > >> > > >> > >> > > > > >> > >> > > >> > >> > > > >> > >> > > >> > >> > > >> > >> > > >> > >> > >> > >> > > >> > > >> > >> > > >> > >> > >> > > > >> > >> > > >> > >> > >> > > >> > > > > >
