Created an issue with proposed changes: https://issues.apache.org/jira/browse/CB-7947. Let's move discussion there.
On Tue, Oct 21, 2014 at 12:03 PM, Andrew Grieve <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> wrote: >> >> > >> > >> > On Fri, Sep 12, 2014 at 10:34 AM, Archana Naik <[email protected]> >> > 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 <[email protected]> >> >> wrote: >> >> >> >> > On Fri, Sep 12, 2014 at 1:02 PM, Joe Bowser <[email protected]> >> 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 < >> [email protected] >> >> > >> >> > > 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 < >> >> > [email protected]> >> >> > >> 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 <[email protected]>: >> >> > >> > >> >> > >> > > 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 < >> >> [email protected] >> >> > > >> >> > >> > > wrote: >> >> > >> > > > Biiiiig -1 for breaking current background behaviour. >> >> > >> > > > >> >> > >> > > > Or am I misunderstanding? >> >> > >> > > > On 11 Sep 2014 10:34, "Joe Bowser" <[email protected]> >> 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 < >> >> > >> [email protected]> >> >> > >> > > >> 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 < >> [email protected]> >> >> > 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" < >> >> [email protected] >> >> > > >> >> > >> > > 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 < >> >> > [email protected] >> >> > >> > >> >> > >> > > >> 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 < >> >> > >> > > >> [email protected] >> >> > >> > > >> > > >> >> > >> > > >> > >> > 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 < >> >> > >> > > [email protected]> >> >> > >> > > >> > >> 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 < >> >> > >> > > >> > [email protected]> >> >> > >> > > >> > >> > > 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 < >> >> > >> > > >> > [email protected] >> >> > >> > > >> > >> > >> >> > >> > > >> > >> > > >> 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? >> >> > >> > > >> > >> > > > >> >> > >> > > >> > >> > > > >> >> > >> > > >> > >> > > >> >> > >> > > >> > >> > >> >> > >> > > >> > >> >> >> > >> > > >> > >> >> > >> > > >> >> >> > >> > > >> >> > >> > >> >> > >> >> >> > >> >> >> > >> > >> > >
