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.
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? > > > >> > >> > > > > > > >> > >> > > > > > > >> > >> > > > > > >> > >> > > > > >> > >> > > > >> > > > > >> > > > > > >
