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

Reply via email to