Fix theme inconsistencies for WebViews used in dialogs.

Fix theme inconsistencies for WebViews used in dialogs.

Try to load menu resources via the standard method first, before
falling back to using the context we were constructed with.

BUG=506579
Committed: https://crrev.com/92fddcd70e7247fc3af519e7e2575837c3966e50
Cr-Commit-Position: refs/heads/master@{#337404}

[Tobias Sargeant, 2015-07-02 14:35:40]

tobiasjs@chromium.org changed reviewers:
+ jdduke@chromium.org

[Tobias Sargeant, 2015-07-02 14:35:40]

PTAL. If you can think of a way of doing this that doesn't involve logspam, we'd
love to hear it. The only other option appears to involve relflection, though,
and we came to the decision that this way was the least worst.

[jdduke (slow), 2015-07-02 18:44:15]

Seems fine as long as we don't regress the issue fixed by
https://codereview.chromium.org/1139743003.

https://codereview.chromium.org/1216853005/diff/1/content/public/android/java...
File
content/public/android/java/src/org/chromium/content/browser/SelectActionModeCallback.java
(right):

https://codereview.chromium.org/1216853005/diff/1/content/public/android/java...
content/public/android/java/src/org/chromium/content/browser/SelectActionModeCallback.java:147:
} catch (Exception e) {
Hmm, I don't think we should be catching all exception types here. Is there a
specific exception type you're seeing? If so, we should catch only that.

[Tobias Sargeant, 2015-07-03 11:05:19]

I've checked, and we don't regress the groupon issue or any of the other
resource loading issues that I'm aware of on L or M. Eventually we will want to
resolve this by supporting what webview needs to do better in the framework, but
for the moment this improves things.

https://codereview.chromium.org/1216853005/diff/1/content/public/android/java...
File
content/public/android/java/src/org/chromium/content/browser/SelectActionModeCallback.java
(right):

https://codereview.chromium.org/1216853005/diff/1/content/public/android/java...
content/public/android/java/src/org/chromium/content/browser/SelectActionModeCallback.java:147:
} catch (Exception e) {
On 2015/07/02 18:44:15, jdduke(OOO_until_July_6) wrote:
> Hmm, I don't think we should be catching all exception types here. Is there a
> specific exception type you're seeing? If so, we should catch only that.

I've changed it to be more specific. As a general rule I agree that catching the
most specific exception possible is a good idea. In this case, what I was
thinking, though, is that in the case where anything goes wrong at all with menu
inflation, we have a second chance using the context we were constructed with.
So it made sense to me to catch everything, then retry (and possibly fail again)
with the alternative context. By being specific we run the risk that we will
crash in cases that we could have recovered from.

[jdduke (slow), 2015-07-06 15:15:29]

jdduke@chromium.org changed reviewers:
+ torne@chromium.org

[jdduke (slow), 2015-07-06 15:15:29]

Looks fine. +torne who reviewed the original change. lgtm when he's happy.

[Torne, 2015-07-06 15:16:52]

lgtm

[Tobias Sargeant, 2015-07-06 15:21:44]

The CQ bit was checked by tobiasjs@chromium.org

[commit-bot: I haz the power, 2015-07-06 15:22:23]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1216853005/20001

[commit-bot: I haz the power, 2015-07-06 16:14:53]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-07-06 16:15:54]

Patchset 2 (id:??) landed as
https://crrev.com/92fddcd70e7247fc3af519e7e2575837c3966e50
Cr-Commit-Position: refs/heads/master@{#337404}