tree dd86d4b10e658cef8bf5fea5d99baa1d15bda7ca
parent 135b99861d0d898850754a845f607ec48f0bcccc
author tsepez <tsepez@chromium.org> 1470442347 -0700
committer Commit bot <commit-bot@chromium.org> 1470442347 -0700

Remove another potential stale CJS_Timer usage

Fix memory ownership model for PDFium timers.

The |app| class owns the CJS_Timer as part of its vector<unique_ptr>
to them.

The CJS_Timer "owns" its slot in the global ID to timer map, and
removes itself when it is destroyed. Nothing else deletes
from the global map. Deleting from the global map is
accompanied by a callback to the embedder to clear its
resources.

Next, the proper way to remove a CJS_Timer is by going
through the app, and having the app erase its unique ptr,
which then deletes the CJS_Timer, which in turn cleans up the
global map. Provide a CJS_Timer::Cancel static method to
do this conveniently.

There is a alternate path to the CJS_timer via JS and its
CJS_TimerObj. CJS_TimerObj owns a TimerObj that currently
points to the CJS_Timer. If the timer fires, and cleans
itself up, this can go stale.

Make the TimerObj maintain a weak reference via global
timer ID rather than a direct pointer to the CJS_Timer, so
that if the timer fires and is destroyed, future attempts
to cancel find nothing.

There is another path, where if the JS timer object is GC'd, then we
just clean up its CJS_TimerObj without touching
the actual CJS_Timers.  We could make this match the spec
by calling into the new cancel routine as described above,
but it seems weird to have a timer depend on whether a gc
happened or not.

A subsequent CL will rename these objects to more closely
match the conventions used by the other JS wrappers.

BUG=634716

Review-Url: https://codereview.chromium.org/2221513002