[Android] Fix timing issue in enabling/disabling printing.

[Android] Fix timing issue in enabling/disabling printing.

There are a couple timing issues in the previous
implementation of the code that enables/disables the print
activity that is accessible via share.

1.) Multiple calls to enablePrintShareOption could result
    in the second call having the callback run immediately
    without the component first being enabled (since it
    would have been triggered in an AsyncTask in the first
    call).
2.) Back to back enable/disable calls could result in
    unpredictable execution ordering as they run their
    tasks on the thread pool instead of in serial.  Because
    the initial UI is only shown after the first callback is
    run, this would require a show, followed by a hide, followed
    by a show where the task enqueued by the hide is run after
    the enabling call in the second show.

To work around this (and due to the expected usage pattern of
this class), just wait for the task to be run in either of these
states to avoid this being possible.  It would also be possible
to use the SERIAL executor, but that might end up slowing down
the default share flow where we don't expect this interleaving
issue.

BUG=649453, 664486
Committed: https://crrev.com/bce6119f7e2937314f787b8d430ce71142714496
Cr-Commit-Position: refs/heads/master@{#434676}

[Ted C, 2016-11-23 17:29:48]

Description was changed from

==========
[Android] Make enabling/disabling printing threadsafe.

There are a couple thread safety issues in the previous
implementation of the code that enables/disables the print
activity that is accessible via share.

1.) Multiple calls to enablePrintShareOption could result
    in the second call having the callback run immediately
    without the component first being enabled (since it
    would have been triggered in an AsyncTask in the first
    call).
2.) Back to back enable/disable calls could result in
    unpredictable execution ordering as they run their
    tasks on the thread pool instead of in serial.  Because
    the initial UI is only shown after the first callback is
    run, this would require a show, followed by a hide, followed
    by a show where the task enquenced by the hide is run after
    the enabling call in the second show.

To work around this (and due to the expected usage pattern of
this class), just wait for the task to be run in either of these
states to avoid this being possible.  It would also be possible
to use the SERIAL executor, but that might end up slowing down
the default share flow where we don't expect this interleaving
issue.

BUG=649453
==========

to

==========
[Android] Fix timing issue in enabling/disabling printing.

There are a couple timing issues in the previous
implementation of the code that enables/disables the print
activity that is accessible via share.

1.) Multiple calls to enablePrintShareOption could result
    in the second call having the callback run immediately
    without the component first being enabled (since it
    would have been triggered in an AsyncTask in the first
    call).
2.) Back to back enable/disable calls could result in
    unpredictable execution ordering as they run their
    tasks on the thread pool instead of in serial.  Because
    the initial UI is only shown after the first callback is
    run, this would require a show, followed by a hide, followed
    by a show where the task enqueued by the hide is run after
    the enabling call in the second show.

To work around this (and due to the expected usage pattern of
this class), just wait for the task to be run in either of these
states to avoid this being possible.  It would also be possible
to use the SERIAL executor, but that might end up slowing down
the default share flow where we don't expect this interleaving
issue.

BUG=649453
==========

[Ted C, 2016-11-23 18:01:17]

tedchoc@chromium.org changed reviewers:
+ nyquist@chromium.org

[Ted C, 2016-11-23 18:01:18]

PTAL

[Ted C, 2016-11-23 21:16:32]

Description was changed from

==========
[Android] Fix timing issue in enabling/disabling printing.

There are a couple timing issues in the previous
implementation of the code that enables/disables the print
activity that is accessible via share.

1.) Multiple calls to enablePrintShareOption could result
    in the second call having the callback run immediately
    without the component first being enabled (since it
    would have been triggered in an AsyncTask in the first
    call).
2.) Back to back enable/disable calls could result in
    unpredictable execution ordering as they run their
    tasks on the thread pool instead of in serial.  Because
    the initial UI is only shown after the first callback is
    run, this would require a show, followed by a hide, followed
    by a show where the task enqueued by the hide is run after
    the enabling call in the second show.

To work around this (and due to the expected usage pattern of
this class), just wait for the task to be run in either of these
states to avoid this being possible.  It would also be possible
to use the SERIAL executor, but that might end up slowing down
the default share flow where we don't expect this interleaving
issue.

BUG=649453
==========

to

==========
[Android] Fix timing issue in enabling/disabling printing.

There are a couple timing issues in the previous
implementation of the code that enables/disables the print
activity that is accessible via share.

1.) Multiple calls to enablePrintShareOption could result
    in the second call having the callback run immediately
    without the component first being enabled (since it
    would have been triggered in an AsyncTask in the first
    call).
2.) Back to back enable/disable calls could result in
    unpredictable execution ordering as they run their
    tasks on the thread pool instead of in serial.  Because
    the initial UI is only shown after the first callback is
    run, this would require a show, followed by a hide, followed
    by a show where the task enqueued by the hide is run after
    the enabling call in the second show.

To work around this (and due to the expected usage pattern of
this class), just wait for the task to be run in either of these
states to avoid this being possible.  It would also be possible
to use the SERIAL executor, but that might end up slowing down
the default share flow where we don't expect this interleaving
issue.

BUG=649453,664486
==========

[nyquist, 2016-11-23 21:22:07]

lgtm

https://codereview.chromium.org/2523873003/diff/20001/chrome/android/java/src...
File
chrome/android/java/src/org/chromium/chrome/browser/printing/PrintShareActivity.java
(right):

https://codereview.chromium.org/2523873003/diff/20001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/printing/PrintShareActivity.java:127:
private static void waitForPendingStateChangeTask() {
Could you copy-paste (parts of) the CL description to the bug, and then refer to
the bug here? I'd be a small improvement to using 'git blame' in the future for
the calls to waitForPendingStateChangeTask().

[Ted C, 2016-11-23 21:34:20]

The CQ bit was checked by tedchoc@chromium.org

[Ted C, 2016-11-23 21:34:20]

The patchset sent to the CQ was uploaded after l-g-t-m from nyquist@chromium.org
Link to the patchset: https://codereview.chromium.org/2523873003/#ps40001
(title: "comment")

[commit-bot: I haz the power, 2016-11-23 21:34:53]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-23 23:37:06]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-23 23:37:07]

Try jobs failed on following builders:
  linux_chromium_compile_dbg_ng on master.tryserver.chromium.linux
(JOB_TIMED_OUT, no build URL)

[Ted C, 2016-11-24 00:01:02]

https://codereview.chromium.org/2523873003/diff/20001/chrome/android/java/src...
File
chrome/android/java/src/org/chromium/chrome/browser/printing/PrintShareActivity.java
(right):

https://codereview.chromium.org/2523873003/diff/20001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/printing/PrintShareActivity.java:127:
private static void waitForPendingStateChangeTask() {
On 2016/11/23 21:22:07, nyquist wrote:
> Could you copy-paste (parts of) the CL description to the bug, and then refer
to
> the bug here? I'd be a small improvement to using 'git blame' in the future
for
> the calls to waitForPendingStateChangeTask().

Done

[Ted C, 2016-11-24 00:01:12]

The CQ bit was checked by tedchoc@chromium.org

[commit-bot: I haz the power, 2016-11-24 00:02:45]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-24 02:05:07]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-24 02:05:08]

Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_TIMED_OUT, no build
URL)

[Ted C, 2016-11-28 16:54:28]

The CQ bit was checked by tedchoc@chromium.org

[commit-bot: I haz the power, 2016-11-28 16:54:53]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-28 17:30:15]

CQ is committing da patch.

Bot data: {"patchset_id": 40001, "attempt_start_ts": 1480352068755980,
"parent_rev": "ee2553f0fb724c1683222493d0af01612b9bb012", "commit_rev":
"0d6f1b18bd46f478177487a6bb488bec55cbbf17"}

[commit-bot: I haz the power, 2016-11-28 17:30:41]

Description was changed from

==========
[Android] Fix timing issue in enabling/disabling printing.

There are a couple timing issues in the previous
implementation of the code that enables/disables the print
activity that is accessible via share.

1.) Multiple calls to enablePrintShareOption could result
    in the second call having the callback run immediately
    without the component first being enabled (since it
    would have been triggered in an AsyncTask in the first
    call).
2.) Back to back enable/disable calls could result in
    unpredictable execution ordering as they run their
    tasks on the thread pool instead of in serial.  Because
    the initial UI is only shown after the first callback is
    run, this would require a show, followed by a hide, followed
    by a show where the task enqueued by the hide is run after
    the enabling call in the second show.

To work around this (and due to the expected usage pattern of
this class), just wait for the task to be run in either of these
states to avoid this being possible.  It would also be possible
to use the SERIAL executor, but that might end up slowing down
the default share flow where we don't expect this interleaving
issue.

BUG=649453,664486
==========

to

==========
[Android] Fix timing issue in enabling/disabling printing.

There are a couple timing issues in the previous
implementation of the code that enables/disables the print
activity that is accessible via share.

1.) Multiple calls to enablePrintShareOption could result
    in the second call having the callback run immediately
    without the component first being enabled (since it
    would have been triggered in an AsyncTask in the first
    call).
2.) Back to back enable/disable calls could result in
    unpredictable execution ordering as they run their
    tasks on the thread pool instead of in serial.  Because
    the initial UI is only shown after the first callback is
    run, this would require a show, followed by a hide, followed
    by a show where the task enqueued by the hide is run after
    the enabling call in the second show.

To work around this (and due to the expected usage pattern of
this class), just wait for the task to be run in either of these
states to avoid this being possible.  It would also be possible
to use the SERIAL executor, but that might end up slowing down
the default share flow where we don't expect this interleaving
issue.

BUG=649453,664486
==========

[commit-bot: I haz the power, 2016-11-28 17:30:41]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2016-11-28 17:33:02]

Description was changed from

==========
[Android] Fix timing issue in enabling/disabling printing.

There are a couple timing issues in the previous
implementation of the code that enables/disables the print
activity that is accessible via share.

1.) Multiple calls to enablePrintShareOption could result
    in the second call having the callback run immediately
    without the component first being enabled (since it
    would have been triggered in an AsyncTask in the first
    call).
2.) Back to back enable/disable calls could result in
    unpredictable execution ordering as they run their
    tasks on the thread pool instead of in serial.  Because
    the initial UI is only shown after the first callback is
    run, this would require a show, followed by a hide, followed
    by a show where the task enqueued by the hide is run after
    the enabling call in the second show.

To work around this (and due to the expected usage pattern of
this class), just wait for the task to be run in either of these
states to avoid this being possible.  It would also be possible
to use the SERIAL executor, but that might end up slowing down
the default share flow where we don't expect this interleaving
issue.

BUG=649453,664486
==========

to

==========
[Android] Fix timing issue in enabling/disabling printing.

There are a couple timing issues in the previous
implementation of the code that enables/disables the print
activity that is accessible via share.

1.) Multiple calls to enablePrintShareOption could result
    in the second call having the callback run immediately
    without the component first being enabled (since it
    would have been triggered in an AsyncTask in the first
    call).
2.) Back to back enable/disable calls could result in
    unpredictable execution ordering as they run their
    tasks on the thread pool instead of in serial.  Because
    the initial UI is only shown after the first callback is
    run, this would require a show, followed by a hide, followed
    by a show where the task enqueued by the hide is run after
    the enabling call in the second show.

To work around this (and due to the expected usage pattern of
this class), just wait for the task to be run in either of these
states to avoid this being possible.  It would also be possible
to use the SERIAL executor, but that might end up slowing down
the default share flow where we don't expect this interleaving
issue.

BUG=649453,664486

Committed: https://crrev.com/bce6119f7e2937314f787b8d430ce71142714496
Cr-Commit-Position: refs/heads/master@{#434676}
==========

[commit-bot: I haz the power, 2016-11-28 17:33:03]

Patchset 3 (id:??) landed as
https://crrev.com/bce6119f7e2937314f787b8d430ce71142714496
Cr-Commit-Position: refs/heads/master@{#434676}