Merge 2 CLs to M53.

Merge 2 CLs to M53.

TBR=tsepez@chromium.org

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
(cherry picked from commit 8ca63de14d522d3d259d74fa43b28b05b02728e8)

openjpeg: Prevent negative x, y values in opj_tcd_init_tile

BUG=632622
Review-Url: https://codereview.chromium.org/2223303002
(cherry picked from commit b6befb2ed2485a3805cddea86dc7574510178ea9)

Committed: https://pdfium.googlesource.com/pdfium/+/fe9485fff248dd04a0643e4ce2309aec7ae237e1

[Oliver Chang, 2016-08-16 19:47:26]

Patchset #2 (id:20001) has been deleted

[Oliver Chang, 2016-08-16 19:47:55]

Description was changed from

==========
Merge 2 CLs to M53.

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
(cherry picked from commit 8ca63de14d522d3d259d74fa43b28b05b02728e8)

openjpeg: Prevent negative x, y values in opj_tcd_init_tile

BUG=632622

Review-Url: https://codereview.chromium.org/2223303002
(cherry picked from commit b6befb2ed2485a3805cddea86dc7574510178ea9)
==========

to

==========
Merge 2 CLs to M53.

TBR=tsepez@chromium.org

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
(cherry picked from commit 8ca63de14d522d3d259d74fa43b28b05b02728e8)

openjpeg: Prevent negative x, y values in opj_tcd_init_tile

BUG=632622

Review-Url: https://codereview.chromium.org/2223303002
(cherry picked from commit b6befb2ed2485a3805cddea86dc7574510178ea9)
==========

[Oliver Chang, 2016-08-16 19:47:55]

ochang@chromium.org changed reviewers:
+ tsepez@chromium.org

[Oliver Chang, 2016-08-16 19:48:02]

TBR, clean merge.

[Oliver Chang, 2016-08-16 19:52:30]

Description was changed from

==========
Merge 2 CLs to M53.

TBR=tsepez@chromium.org

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
(cherry picked from commit 8ca63de14d522d3d259d74fa43b28b05b02728e8)

openjpeg: Prevent negative x, y values in opj_tcd_init_tile

BUG=632622

Review-Url: https://codereview.chromium.org/2223303002
(cherry picked from commit b6befb2ed2485a3805cddea86dc7574510178ea9)
==========

to

==========
Merge 2 CLs to M53.

TBR=tsepez@chromium.org

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
(cherry picked from commit 8ca63de14d522d3d259d74fa43b28b05b02728e8)

openjpeg: Prevent negative x, y values in opj_tcd_init_tile

BUG=632622

Review-Url: https://codereview.chromium.org/2223303002
(cherry picked from commit b6befb2ed2485a3805cddea86dc7574510178ea9)

Committed:
https://pdfium.googlesource.com/pdfium/+/fe9485fff248dd04a0643e4ce2309aec7ae2...
==========

[Oliver Chang, 2016-08-16 19:52:32]

Committed patchset #1 (id:1) manually as
fe9485fff248dd04a0643e4ce2309aec7ae237e1 (presubmit successful).