Address HandlerLeak lint warnings.

chrome/android/java/src/org/chromium/chrome/browser/TidyHandler.java

+// Copyright 2016 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+package org.chromium.chrome.browser;
+
+import android.os.Handler;
+import android.os.Message;
+
+import java.lang.ref.WeakReference;
+
+/**
+ * Abstract Handler subclass that can be used to prevent memory leaks. Handlers may cause leaks if
+ * handling a message is delayed. Messages added to the message queue have a reference to the
+ * Handler and the Handler has a reference to the outer class which prevents the outer class from
+ * being garbage collected. Child classes should be static so that their lifetime isn't tied to the
+ * containing class.
+ * <p>
+ * A sample implementation of a {@link TidyHandler} is shown below:
+ *
+ * <pre>
+ * <code>
+ * {@code public static class ExampleTidyHandler extends TidyHandler<ContainingClass>} {
+ *     public ExampleTidyHandler(ContainingClass instance) {
+ *         super(instance);
+ *     }
+ *
+ *     {@literal @}Override
+ *     public void handleMessageTidy(Message m, ContainingClass instance) {
+ *         instance.doSomeInstanceMethodThatHandlesTheMessage();
+ *     }
+ * }
+ * </code>
+ * </pre>
+ *
+ * @param <T> The containing class.
+ */
+public abstract class TidyHandler<T> extends Handler {
+
+    private WeakReference<T> mClassReference;

[Ted C, 2016/09/13 17:25:54]

For the places that use this, do we actually have destroy call paths that we
could hook into?

I know Tab in particular has destroy(), and it seems like we could instead call
https://developer.android.com/reference/android/os/Handler.html#removeCallbac...
w/ null and remove any pending callbacks and then we're not relying on weak
references to clean this up.

"Ideally" we just introduce a more consistent policy of cleaning up your
handlers instead of weak refs, but that might not always be possible.  I just
think we should explore that option first.  We'd still need to add FindBugs
exclusions, but that seems "more correct" in terms of logic.

If we do need this, I wonder if we could introduce an interface

interface MessageHandler {
    void handleMessage(Message m);
}

Then instead of taking a <T>, this could just take the MessageHandler interface
and clean that up a bit.

For example, Tab would just implement the interface at the top level and then
could create a new TidyHandler(this) to reduce the inner class fun.

+
+    public TidyHandler(T instance) {
+        mClassReference = new WeakReference<T>(instance);
+    }
+
+    @Override
+    public void handleMessage(Message m) {
+        T instance = mClassReference.get();
+        if (instance != null) {
+            handleMessage(m, instance);
+        }
+    }
+
+    protected void baseHandlerHandleMessage(Message m) {
+        super.handleMessage(m);
+    }
+
+    protected abstract void handleMessage(Message m, T instance);
+}