|
|
Created:
3 years, 8 months ago by mthiesse Modified:
3 years, 8 months ago Reviewers:
David Trainor- moved to gerrit, Sami, boliu, aelias_OOO_until_Jul13, Jinsuk Kim, Changwan Ryu CC:
agrieve+watch_chromium.org, Changwan Ryu, chromium-reviews, darin-cc_chromium.org, feature-vr-reviews_chromium.org, jam, Jinsuk Kim Target Ref:
refs/heads/master Project:
chromium Visibility:
Public. |
Description[Android] Focus/Blur contents when window focus changes
This ensure that when an activity loses input focus (OnWindowFocusChanged), that the web page is blurred and not considered to be focused.
BUG=686232
Review-Url: https://codereview.chromium.org/2779033004
Cr-Commit-Position: refs/heads/master@{#463390}
Committed: https://chromium.googlesource.com/chromium/src/+/460ffe75e23987ac6760d668963d9d2f1a83962b
Patch Set 1 #Patch Set 2 : Add missing file #
Total comments: 5
Patch Set 3 : Address comments #
Total comments: 8
Patch Set 4 : Address comments #Patch Set 5 : preemptive nit #
Total comments: 2
Patch Set 6 : rebase + fix nit #
Total comments: 2
Patch Set 7 : address comments #Patch Set 8 : Fix initialization order issues. #Patch Set 9 : Fix tests #Patch Set 10 : Add comments #
Total comments: 2
Patch Set 11 : Fix popups #Patch Set 12 : Fix tests #Patch Set 13 : fix compile #Patch Set 14 : rebase #Patch Set 15 : Use pause/resume instead of WindowFocusChanged #
Messages
Total messages: 74 (36 generated)
mthiesse@chromium.org changed reviewers: + aelias@chromium.org
PTAL
Description was changed from ========== [Android] Focus/Blur contents in when window focus changes This ensure that when an activity loses input focus (OnWindowFocusChanged), that the web page is blurred and not considered to be focused. BUG=686232 ========== to ========== [Android] Focus/Blur contents when window focus changes This ensure that when an activity loses input focus (OnWindowFocusChanged), that the web page is blurred and not considered to be focused. BUG=686232 ==========
mthiesse@chromium.org changed reviewers: + skyostil@chromium.org
skyostil@chromium.org: Please review changes in chrome/android/javatests.
The CQ bit was checked by mthiesse@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
https://codereview.chromium.org/2779033004/diff/20001/content/public/android/... File content/public/android/java/src/org/chromium/content/browser/ContentViewCore.java (right): https://codereview.chromium.org/2779033004/diff/20001/content/public/android/... content/public/android/java/src/org/chromium/content/browser/ContentViewCore.java:1340: if (hasFocus()) onFocusChanged(false, true /* hideKeyboardOnBlur */); This is stacking the effects of the view focus and window focus booleans in a way that's hard to reason about. I suggest changing ContentViewCore.onFocusChanged to not take the first boolean argument, and instead directly within itself call the view and window focus methods to determine the new focus status. Please also add an early-return at the top of ContentViewCore.onFocusChanged if focus did not wind up changing, which probably should involve a boolean which is also set correctly at ContentViewCore construction.
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED, https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)
The CQ bit was checked by mthiesse@chromium.org
The CQ bit was unchecked by mthiesse@chromium.org
The CQ bit was checked by mthiesse@chromium.org
The CQ bit was unchecked by mthiesse@chromium.org
changwan@chromium.org changed reviewers: + changwan@chromium.org
https://codereview.chromium.org/2779033004/diff/20001/content/public/android/... File content/public/android/java/src/org/chromium/content/browser/ContentViewCore.java (right): https://codereview.chromium.org/2779033004/diff/20001/content/public/android/... content/public/android/java/src/org/chromium/content/browser/ContentViewCore.java:1343: } Because ImeAdapter and SelectionPopupController already handle window and view focus changes separately, could we refactor this into something like the following? public void onWindowFocusChanged(boolean hasWindowFocus) { ... onFocusChangeInternal(); } public void onFocusChanged(boolean gainFocus, boolean hideKeyboardOnBlur) { ... onFocusChangeInternal(); } private void onFocusChangeInternal() { boolean focused = hasWindowFocus() && hasFocus(); if (focused != mFocused) { if (mNativeContentViewCore != 0) { nativeSetFocus(mNativeContentViewCore, hasWindowFocus() && hasFocus()); } mFocused = focused; } } I think this should be enough for now. Otherwise, at least ThreadedInputConnectionFactory's logging will be messed up. BTW, as aelias@ pointed out, window and view focus change order can be quite complex and hard to predict. In the case of web app, the normal order would be window focus loss --> view focus loss, but some webview app may change view focus in the middle of window focus loss which will end up as view focus loss --> window focus loss.
https://codereview.chromium.org/2779033004/diff/20001/content/public/android/... File content/public/android/java/src/org/chromium/content/browser/ContentViewCore.java (right): https://codereview.chromium.org/2779033004/diff/20001/content/public/android/... content/public/android/java/src/org/chromium/content/browser/ContentViewCore.java:1343: } On 2017/03/30 00:05:49, Changwan Ryu wrote: > Because ImeAdapter and SelectionPopupController already handle window and view > focus changes separately, could we refactor this into something like the > following? > > public void onWindowFocusChanged(boolean hasWindowFocus) { > ... > onFocusChangeInternal(); > } > > public void onFocusChanged(boolean gainFocus, boolean hideKeyboardOnBlur) { > ... > onFocusChangeInternal(); > } > > private void onFocusChangeInternal() { > boolean focused = hasWindowFocus() && hasFocus(); > if (focused != mFocused) { > if (mNativeContentViewCore != 0) { > nativeSetFocus(mNativeContentViewCore, hasWindowFocus() && > hasFocus()); > } > mFocused = focused; > } > } > > I think this should be enough for now. > > Otherwise, at least ThreadedInputConnectionFactory's logging will be messed up. > > BTW, as aelias@ pointed out, window and view focus change order can be quite > complex and hard to predict. In the case of web app, the normal order would be > window focus loss --> view focus loss, but some webview app may change view > focus in the middle of window focus loss which will end up as view focus loss > --> window focus loss. Thanks, that's essentially what I'm writing now. However, I'm bashing my head against a wall because View#hasWindowFocus() returns false when we first get a ContainerView, but then OnWindowFocusChanged is *never* called until the app first loses window focus. I'm trying to find some other way of setting the initial state correctly, but it seems that View#hasWindowFocus() really can't be trusted.
ugh. getContainerView().hasWindowFocus() returns false whenever the View doesn't have view focus. It only returns true if you have View and Window focus. So getContainerView().hasWindowFocus() can change its return value without OnWindowFocusChanged ever getting called.
Note that I didn't implement exactly as you requested, because tests still need to override these values (so we can't just always check for the actual values), but I think I captures the spirit of it ;) https://codereview.chromium.org/2779033004/diff/20001/content/public/android/... File content/public/android/java/src/org/chromium/content/browser/ContentViewCore.java (right): https://codereview.chromium.org/2779033004/diff/20001/content/public/android/... content/public/android/java/src/org/chromium/content/browser/ContentViewCore.java:1340: if (hasFocus()) onFocusChanged(false, true /* hideKeyboardOnBlur */); On 2017/03/29 21:54:04, aelias wrote: > This is stacking the effects of the view focus and window focus booleans in a > way that's hard to reason about. I suggest changing > ContentViewCore.onFocusChanged to not take the first boolean argument, and > instead directly within itself call the view and window focus methods to > determine the new focus status. > > Please also add an early-return at the top of ContentViewCore.onFocusChanged if > focus did not wind up changing, which probably should involve a boolean which is > also set correctly at ContentViewCore construction. Done. https://codereview.chromium.org/2779033004/diff/20001/content/public/android/... content/public/android/java/src/org/chromium/content/browser/ContentViewCore.java:1343: } On 2017/03/30 00:12:45, mthiesse wrote: > On 2017/03/30 00:05:49, Changwan Ryu wrote: > > Because ImeAdapter and SelectionPopupController already handle window and view > > focus changes separately, could we refactor this into something like the > > following? > > > > public void onWindowFocusChanged(boolean hasWindowFocus) { > > ... > > onFocusChangeInternal(); > > } > > > > public void onFocusChanged(boolean gainFocus, boolean hideKeyboardOnBlur) { > > ... > > onFocusChangeInternal(); > > } > > > > private void onFocusChangeInternal() { > > boolean focused = hasWindowFocus() && hasFocus(); > > if (focused != mFocused) { > > if (mNativeContentViewCore != 0) { > > nativeSetFocus(mNativeContentViewCore, hasWindowFocus() && > > hasFocus()); > > } > > mFocused = focused; > > } > > } > > > > I think this should be enough for now. > > > > Otherwise, at least ThreadedInputConnectionFactory's logging will be messed > up. > > > > BTW, as aelias@ pointed out, window and view focus change order can be quite > > complex and hard to predict. In the case of web app, the normal order would be > > window focus loss --> view focus loss, but some webview app may change view > > focus in the middle of window focus loss which will end up as view focus loss > > --> window focus loss. > > Thanks, that's essentially what I'm writing now. > > However, I'm bashing my head against a wall because View#hasWindowFocus() > returns false when we first get a ContainerView, but then OnWindowFocusChanged > is *never* called until the app first loses window focus. > > I'm trying to find some other way of setting the initial state correctly, but it > seems that View#hasWindowFocus() really can't be trusted. Done.
https://codereview.chromium.org/2779033004/diff/40001/content/public/android/... File content/public/android/java/src/org/chromium/content/browser/ContentViewCore.java (right): https://codereview.chromium.org/2779033004/diff/40001/content/public/android/... content/public/android/java/src/org/chromium/content/browser/ContentViewCore.java:115: private final Map<String, Pair<Object, Class>> mJavaScriptInterfaces = new HashMap<>(); I assume you made these changes because of a presubmit warning or something? Could you keep them out of this patch and ignore the warning? This makes the git history confusing and a revert (if needed) more annoying. https://codereview.chromium.org/2779033004/diff/40001/content/public/android/... content/public/android/java/src/org/chromium/content/browser/ContentViewCore.java:1367: public void onFocusChanged(boolean gainFocus, boolean hideKeyboardOnBlur) { Please rename "gainFocus" to "hasViewFocus" https://codereview.chromium.org/2779033004/diff/40001/content/public/android/... content/public/android/java/src/org/chromium/content/browser/ContentViewCore.java:1379: if (hasInputFocus == hadInputFocus) return; This early-return seems to do nothing given the others. I suggest deleting this one, and putting the assignments right below the early-returns in onWindowFocusChanged and onFocusChanged. https://codereview.chromium.org/2779033004/diff/40001/content/public/android/... File content/public/android/javatests/src/org/chromium/content/browser/ContentViewCoreSelectionTest.java (right): https://codereview.chromium.org/2779033004/diff/40001/content/public/android/... content/public/android/javatests/src/org/chromium/content/browser/ContentViewCoreSelectionTest.java:709: contentViewCore.onFocusChangedInternal(true, gainFocus, true); Would it be difficult to call onFocusChanged directly from these tests instead? @VisibleForTesting is a bit of an antipattern.
https://codereview.chromium.org/2779033004/diff/40001/content/public/android/... File content/public/android/java/src/org/chromium/content/browser/ContentViewCore.java (right): https://codereview.chromium.org/2779033004/diff/40001/content/public/android/... content/public/android/java/src/org/chromium/content/browser/ContentViewCore.java:115: private final Map<String, Pair<Object, Class>> mJavaScriptInterfaces = new HashMap<>(); On 2017/03/30 02:06:55, aelias wrote: > I assume you made these changes because of a presubmit warning or something? > Could you keep them out of this patch and ignore the warning? This makes the > git history confusing and a revert (if needed) more annoying. My editor automatically makes these changes, and I can't convince it not to. It's really annoying having to undo them every time I save the file. https://codereview.chromium.org/2779033004/diff/40001/content/public/android/... content/public/android/java/src/org/chromium/content/browser/ContentViewCore.java:1367: public void onFocusChanged(boolean gainFocus, boolean hideKeyboardOnBlur) { On 2017/03/30 02:06:55, aelias wrote: > Please rename "gainFocus" to "hasViewFocus" Done. https://codereview.chromium.org/2779033004/diff/40001/content/public/android/... content/public/android/java/src/org/chromium/content/browser/ContentViewCore.java:1379: if (hasInputFocus == hadInputFocus) return; On 2017/03/30 02:06:55, aelias wrote: > This early-return seems to do nothing given the others. I suggest deleting this > one, and putting the assignments right below the early-returns in > onWindowFocusChanged and onFocusChanged. It doesn't do nothing - it stops us from doing work when we go from (false, false) to (false, true). https://codereview.chromium.org/2779033004/diff/40001/content/public/android/... File content/public/android/javatests/src/org/chromium/content/browser/ContentViewCoreSelectionTest.java (right): https://codereview.chromium.org/2779033004/diff/40001/content/public/android/... content/public/android/javatests/src/org/chromium/content/browser/ContentViewCoreSelectionTest.java:709: contentViewCore.onFocusChangedInternal(true, gainFocus, true); On 2017/03/30 02:06:55, aelias wrote: > Would it be difficult to call onFocusChanged directly from these tests instead? > @VisibleForTesting is a bit of an antipattern. Done.
lgtm https://codereview.chromium.org/2779033004/diff/80001/chrome/android/javatest... File chrome/android/javatests/src/org/chromium/chrome/browser/ContentViewFocusTest.java (right): https://codereview.chromium.org/2779033004/diff/80001/chrome/android/javatest... chrome/android/javatests/src/org/chromium/chrome/browser/ContentViewFocusTest.java:40: private final ArrayDeque<Boolean> mFocusChanges = new ArrayDeque<>(); You still have one of these.
https://codereview.chromium.org/2779033004/diff/80001/chrome/android/javatest... File chrome/android/javatests/src/org/chromium/chrome/browser/ContentViewFocusTest.java (right): https://codereview.chromium.org/2779033004/diff/80001/chrome/android/javatest... chrome/android/javatests/src/org/chromium/chrome/browser/ContentViewFocusTest.java:40: private final ArrayDeque<Boolean> mFocusChanges = new ArrayDeque<>(); On 2017/03/30 18:10:35, aelias wrote: > You still have one of these. Done.
lgtm. https://codereview.chromium.org/2779033004/diff/100001/chrome/android/javates... File chrome/android/javatests/src/org/chromium/chrome/browser/ContentViewFocusTest.java (right): https://codereview.chromium.org/2779033004/diff/100001/chrome/android/javates... chrome/android/javatests/src/org/chromium/chrome/browser/ContentViewFocusTest.java:193: mObserver = new WebContentsObserver(getActivity().getActivityTab().getWebContents()) { nit: Looks like mObserver could be a local variable, and mOnTitleUpdatedHelper could be a final local too.
https://codereview.chromium.org/2779033004/diff/100001/chrome/android/javates... File chrome/android/javatests/src/org/chromium/chrome/browser/ContentViewFocusTest.java (right): https://codereview.chromium.org/2779033004/diff/100001/chrome/android/javates... chrome/android/javatests/src/org/chromium/chrome/browser/ContentViewFocusTest.java:193: mObserver = new WebContentsObserver(getActivity().getActivityTab().getWebContents()) { On 2017/04/03 10:23:45, Sami wrote: > nit: Looks like mObserver could be a local variable, and mOnTitleUpdatedHelper > could be a final local too. Done.
The CQ bit was checked by mthiesse@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from aelias@chromium.org, skyostil@chromium.org Link to the patchset: https://codereview.chromium.org/2779033004/#ps120001 (title: "address comments")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: android_n5x_swarming_rel on master.tryserver.chromium.android (JOB_FAILED, https://build.chromium.org/p/tryserver.chromium.android/builders/android_n5x_...)
The CQ bit was checked by mthiesse@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED, https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)
mthiesse@chromium.org changed reviewers: + boliu@chromium.org
boliu@chromium.org: Please review changes in android_webview/
android_webview lgtm I assume aelias already reviewed content, so I didn't
aelias, please re-review the changes to setContainerView. OnFocusChanged/OnWindowFocusChanged currently assume they'll only be called after the CVC is initialized, so I had to slightly change how setContainerView is called, and set the initial focus state after the CVC is initialized.
https://codereview.chromium.org/2779033004/diff/180001/content/public/android... File content/public/android/java/src/org/chromium/content/browser/ContentViewCore.java (right): https://codereview.chromium.org/2779033004/diff/180001/content/public/android... content/public/android/java/src/org/chromium/content/browser/ContentViewCore.java:560: setContainerView(viewDelegate.getContainerView(), false); Could you try just moving this to the end of the constructor instead? Most of the other objects being constructed in this method take the View as an argument directly so it should be fine. If there are any leftovers that use ContentViewCore.getContainerView(), please change them to use the argument model or just leave them null and initialize them in ContentViewCore.setContainerView().
Well this is very annoying. When Android shows a popup, the CVC loses window focus, which causes the page to blur, which hides the popup.
The CQ bit was checked by mthiesse@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was checked by mthiesse@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: android_clang_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED, https://build.chromium.org/p/tryserver.chromium.android/builders/android_clan...)
Note that I also fixed the issue of popups automatically closing after opening - by ignoring the focus state of the CVC while it has a popup open and updating after the popup closes. https://codereview.chromium.org/2779033004/diff/180001/content/public/android... File content/public/android/java/src/org/chromium/content/browser/ContentViewCore.java (right): https://codereview.chromium.org/2779033004/diff/180001/content/public/android... content/public/android/java/src/org/chromium/content/browser/ContentViewCore.java:560: setContainerView(viewDelegate.getContainerView(), false); On 2017/04/03 21:57:56, aelias wrote: > Could you try just moving this to the end of the constructor instead? Most of > the other objects being constructed in this method take the View as an argument > directly so it should be fine. If there are any leftovers that use > ContentViewCore.getContainerView(), please change them to use the argument model > or just leave them null and initialize them in > ContentViewCore.setContainerView(). Done.
Hmm, on further thought, not lgtm as is, sorry. I get the sense that the popup you found is just the tip of the iceberg and we will find many other types of window focus stealers (what about, PopupZoomer, IME, autofill, URL-bar, etc?). And the bypass to look at draw state is another sign window focus is problematic. It seems window focus is not the appropriate thing to look at for what you're trying to achieve here. Going back to your original goal, you want to lose focus when the user presses the home button. It seems Activity onStart/onStop https://developer.android.com/reference/android/app/Activity.html#onStop() is a more safely narrow mapping to what you want. (It seems this is a better fit than Activity.onWindowFocusChanged because the documentation says: "Returns true if this activity's *main* window currently has window focus".)
On 2017/04/05 19:23:42, aelias wrote: > Hmm, on further thought, not lgtm as is, sorry. I get the sense that the popup > you found is just the tip of the iceberg and we will find many other types of > window focus stealers (what about, PopupZoomer, IME, autofill, URL-bar, etc?). > And the bypass to look at draw state is another sign window focus is > problematic. It seems window focus is not the appropriate thing to look at for > what you're trying to achieve here. > > Going back to your original goal, you want to lose focus when the user presses > the home button. It seems Activity onStart/onStop > https://developer.android.com/reference/android/app/Activity.html#onStop() is a > more safely narrow mapping to what you want. (It seems this is a better fit > than Activity.onWindowFocusChanged because the documentation says: "Returns true > if this activity's *main* window currently has window focus".) Fair point, I thought about doing that too. Does this have implications for the IME as well, which looks at window focus for the CVC? Should we map that to activity start/stop as well?
On 2017/04/05 19:26:43, mthiesse wrote: > On 2017/04/05 19:23:42, aelias wrote: > > Hmm, on further thought, not lgtm as is, sorry. I get the sense that the > popup > > you found is just the tip of the iceberg and we will find many other types of > > window focus stealers (what about, PopupZoomer, IME, autofill, URL-bar, etc?). > > > And the bypass to look at draw state is another sign window focus is > > problematic. It seems window focus is not the appropriate thing to look at > for > > what you're trying to achieve here. > > > > Going back to your original goal, you want to lose focus when the user presses > > the home button. It seems Activity onStart/onStop > > https://developer.android.com/reference/android/app/Activity.html#onStop() is > a > > more safely narrow mapping to what you want. (It seems this is a better fit > > than Activity.onWindowFocusChanged because the documentation says: "Returns > true > > if this activity's *main* window currently has window focus".) > > Fair point, I thought about doing that too. Does this have implications for the > IME as well, which looks at window focus for the CVC? Should we map that to > activity start/stop as well? Actually activity start/stop is probably not right for IME either. However, I found a bunch of issues with tracking WindowFocused state in this CL, like how it's nearly impossible to get the initial state right.
Let's leave IME behavior as it unless there's a good reason to change it. I'd like to minimize potential possibility of regression from doing this.
The CQ bit was checked by mthiesse@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
Alright, changed to use pause/resume. PTAL
I would've preferred onStart/onStop, is there a reason you used onPause/onResume instead? Those have a nebulous definition and I worry they may be subject to the same kind of issues as window focus.
jinsukkim@, could you take a look at this and see if the additional calls to ChromeActivity.getContentViewCore() will cause problems for you? If so, how should this be factored? It seems there was only one remaining one in backPressed() which maybe you were planning to remove.
On 2017/04/06 01:06:07, aelias wrote: > I would've preferred onStart/onStop, is there a reason you used onPause/onResume > instead? Those have a nebulous definition and I worry they may be subject to > the same kind of issues as window focus. pause/resume is explicitly with respect to active state/input focus, is it not? Only one activity can be resumed at a time, and that activity is considered to be 'active', meaning it's the only activity that can have input focus, though actual input focus is gained asynchronously I believe. start/stop has to do with visibility. If we were to use start/stop, then in multi-window mode both tabs would be considered focused at the same time, which breaks the conventions of other platforms. This is exactly the problem I was originally trying to solve in tackling this bug.
aelias@chromium.org changed reviewers: + jinsukkim@chromium.org
On 2017/04/06 01:08:36, aelias wrote: > jinsukkim@, could you take a look at this and see if the additional calls to > ChromeActivity.getContentViewCore() will cause problems for you? If so, how > should this be factored? It seems there was only one remaining one in > backPressed() which maybe you were planning to remove. I think it can be handled later when the idea around how the focus-related stuff in CVC wil be refactored becomes clearer. The change in ChromeActivity looks fine to me.
OK. It does seem like the best one to use in principle. Please wait for jinsukkim@'s review on the factoring, and I'll lgt'm after if it looks good to him.
OK, our messages raced, lgtm.
mthiesse@chromium.org changed reviewers: + dtrainor@chromium.org
dtrainor, please review ChromeActivity changes.
have you checked what this does in multiwindow? is the behavior what you expect/want?
On 2017/04/06 21:44:41, David Trainor-ping if over 24h wrote: > have you checked what this does in multiwindow? is the behavior what you > expect/want? Yes. The page you tap on gets focused, the other page gets blurred. In the case of VR, this means head position information for magic window VR only goes to the multiwindow window you most recently interacted with.
Sorry I missed your reply. lgtm!
The CQ bit was checked by mthiesse@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from skyostil@chromium.org, boliu@chromium.org Link to the patchset: https://codereview.chromium.org/2779033004/#ps280001 (title: "Use pause/resume instead of WindowFocusChanged")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
CQ is committing da patch. Bot data: {"patchset_id": 280001, "attempt_start_ts": 1491850457487210, "parent_rev": "f061caa204ec63d0aed8921101751c574915cafb", "commit_rev": "460ffe75e23987ac6760d668963d9d2f1a83962b"}
Message was sent while issue was closed.
Description was changed from ========== [Android] Focus/Blur contents when window focus changes This ensure that when an activity loses input focus (OnWindowFocusChanged), that the web page is blurred and not considered to be focused. BUG=686232 ========== to ========== [Android] Focus/Blur contents when window focus changes This ensure that when an activity loses input focus (OnWindowFocusChanged), that the web page is blurred and not considered to be focused. BUG=686232 Review-Url: https://codereview.chromium.org/2779033004 Cr-Commit-Position: refs/heads/master@{#463390} Committed: https://chromium.googlesource.com/chromium/src/+/460ffe75e23987ac6760d668963d... ==========
Message was sent while issue was closed.
Committed patchset #15 (id:280001) as https://chromium.googlesource.com/chromium/src/+/460ffe75e23987ac6760d668963d... |