A similar bug exists after you take a screenshot. To reproduce:
(1) Visit http://www.nytimes.com/interactive/2016/06/05/magazine/new-york-life.html
(2) Scroll down so the url bar hides
(3) Take a screenshot (hold power and volume down for 3 seconds)

At this point the url bar will be visible and will obscure the header on the page.


@aelias, can you triage this? I've seen it on several large sites now.

Deleted: stuckhideybar.png 368 KB

	stuckhideybar.png 368 KB View Download

I have also noticed that recently the omnibox fails to hide fully and gets stuck
in a partially-hidden state sometimes. This is on Chrome Dev on Android. Is 
that a known bug?

This reproes in M51, so it's a nonregression.

I believe the not-hiding is an intentional timeout mechanism, with the theory that users still may want to read the URL.  (Personally I dislike all such timeouts and would prefer the URL-bar always to respond immediately to scrolling, but the decision has been made to make it unresponsive in certain situations.)

The second, indisputable problem is that the holding the bar in place is done on the browser side and this causes weirdness like covering fixed-position elements.  I think the browser-side hold mechanism should be restricted to only when the render process is unresponsive.

The first issue is worse than just a timeout because the fixed position content does not update and is left obscured by the url bar.

> I have also noticed that recently the omnibox fails to hide fully and gets stuck
in a partially-hidden state sometimes. This is on Chrome Dev on Android. Is 
that a known bug?

That's not known, please file another bug if you have a consistent repro.

>> I have also noticed that recently the omnibox fails to hide fully and gets stuck
in a partially-hidden state sometimes. This is on Chrome Dev on Android. Is 
that a known bug?

> That's not known, please file another bug if you have a consistent repro.

On second thought, I think this is one symptom of http://crbug.com/608257, which is fixed as of 52.0.2743.32.

I've diagnosed that the problem is in the delay between when ChromeFullscreenManager.animateIfNecessary() posts the hide animation, and when it actually executes.  It only reproes when the URL-bar was only selected very briefly, since the the delay length is mMinShowNotificationMs from the *start* of selection time.

Probably, the fix will be to post a task with a delay that then sends an animation request to the renderer (the renderer TopControlsManager is already capable of doing self-driven animations and they should behave better).

OK, there is actually a regression in 52 here.  Although the repro steps in #0 *do* cause a transient bug for the duration of the 3-seconds in M51, I've observed in more recent builds (53.0.2768.0 and 52.0.2743.32) that the URL-bar sometimes get stuck in a perma-visible state, and the only way to get things back to normal is to go to homescreen.  (pdr@ was likely trying to communicate that it was stuck permanently, but I didn't realize.)

In my daily browsing, it most commonly happens after navigation-induced show animations.  Unfortunately, I haven't found a consistent repro, it seems there is a random (30%?) chance of getting stuck after any show animation.

I suspect this is more fallout from http://crbug.com/608257 and https://codereview.chromium.org/2022183005 wasn't a complete fix [+cc sievers].

I've tracked the regression to a spurious call of RenderWidgetHostViewImpl::RendererIsUnresponsive by the timeout monitor.  The timeout monitor is checking that the count of sent input events matches the count of input acks.  If an ack is never accounted for, the browser reacts by locking the URL-bar to a shown state to allow the user to navigate away from the stuck renderer.

I can intermittently repro by going to http://mobile.nytimes.com/ and navigating back and forth between a news article, then back to the homepage, then repeat until the URL-bar eventually gets stuck.  It's a bit hard to bisect but I'm now suspecting one of the recent input router changes, so assigning to dtapuska@.

Adding mustaq@; most of my changes ended up in 51 with respect to input routing changes. But I'll be happy to look at this when I'm back from blink on.

Mustaq however did some additional work with respect to sending a touch start cancel in m52 so I might suspect that since it seems reported in m52.

I've tracked this down to the main thread event queue. It is possible to coalesce two blocking events together to cause only one ack produced where there should be 2.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b08721e61d24d65dce50e40731e08231deb95932

commit b08721e61d24d65dce50e40731e08231deb95932
Author: dtapuska <dtapuska@chromium.org>
Date: Wed Jun 29 03:35:07 2016

Ensure acks are sent for all blocking events.

It was possible for two touch moves that had acks to get coalesced together
and the main thread would only process one and deliver the ack for it. This
caused a situation where the hung renderer timer was getting fired because
there was an outstanding ack in the count. And this timer forced the
omnibox to not go away.

A large portion of this change (plumbing the ack_state will go away when
I land my multi-thread main_thread_event_queue design); but since this
needs to be merged back to M52 this is safest.

BUG= 616991 

Review-Url: https://codereview.chromium.org/2094323002
Cr-Commit-Position: refs/heads/master@{#402703}

[modify] https://crrev.com/b08721e61d24d65dce50e40731e08231deb95932/content/renderer/input/input_event_filter.cc
[modify] https://crrev.com/b08721e61d24d65dce50e40731e08231deb95932/content/renderer/input/input_event_filter.h
[modify] https://crrev.com/b08721e61d24d65dce50e40731e08231deb95932/content/renderer/input/input_event_filter_unittest.cc
[modify] https://crrev.com/b08721e61d24d65dce50e40731e08231deb95932/content/renderer/input/input_handler_manager.cc
[modify] https://crrev.com/b08721e61d24d65dce50e40731e08231deb95932/content/renderer/input/input_handler_manager.h
[modify] https://crrev.com/b08721e61d24d65dce50e40731e08231deb95932/content/renderer/input/input_handler_manager_client.h
[modify] https://crrev.com/b08721e61d24d65dce50e40731e08231deb95932/content/renderer/input/main_thread_event_queue.cc
[modify] https://crrev.com/b08721e61d24d65dce50e40731e08231deb95932/content/renderer/input/main_thread_event_queue.h
[modify] https://crrev.com/b08721e61d24d65dce50e40731e08231deb95932/content/renderer/input/main_thread_event_queue_unittest.cc
[modify] https://crrev.com/b08721e61d24d65dce50e40731e08231deb95932/content/renderer/input/render_widget_input_handler.cc
[modify] https://crrev.com/b08721e61d24d65dce50e40731e08231deb95932/content/renderer/input/render_widget_input_handler_delegate.h
[modify] https://crrev.com/b08721e61d24d65dce50e40731e08231deb95932/content/renderer/mus/compositor_mus_connection_unittest.cc
[modify] https://crrev.com/b08721e61d24d65dce50e40731e08231deb95932/content/renderer/mus/render_widget_mus_connection.cc
[modify] https://crrev.com/b08721e61d24d65dce50e40731e08231deb95932/content/renderer/mus/render_widget_mus_connection.h
[modify] https://crrev.com/b08721e61d24d65dce50e40731e08231deb95932/content/renderer/render_widget.cc
[modify] https://crrev.com/b08721e61d24d65dce50e40731e08231deb95932/content/renderer/render_widget.h

Your change meets the bar and is auto-approved for M52 (branch: 2743)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5041a16e38bf17352fb59d805c2cab35242b549a

commit 5041a16e38bf17352fb59d805c2cab35242b549a
Author: Dave Tapuska <dtapuska@chromium.org>
Date: Mon Jul 04 13:08:31 2016

Ensure acks are sent for all blocking events.

It was possible for two touch moves that had acks to get coalesced together
and the main thread would only process one and deliver the ack for it. This
caused a situation where the hung renderer timer was getting fired because
there was an outstanding ack in the count. And this timer forced the
omnibox to not go away.

A large portion of this change (plumbing the ack_state will go away when
I land my multi-thread main_thread_event_queue design); but since this
needs to be merged back to M52 this is safest.

BUG= 616991 

Review-Url: https://codereview.chromium.org/2094323002
Cr-Commit-Position: refs/heads/master@{#402703}
(cherry picked from commit b08721e61d24d65dce50e40731e08231deb95932)

Review URL: https://codereview.chromium.org/2118273002 .

Cr-Commit-Position: refs/branch-heads/2743@{#578}
Cr-Branched-From: 2b3ae3b8090361f8af5a611712fc1a5ab2de53cb-refs/heads/master@{#394939}

[modify] https://crrev.com/5041a16e38bf17352fb59d805c2cab35242b549a/content/renderer/input/input_event_filter.cc
[modify] https://crrev.com/5041a16e38bf17352fb59d805c2cab35242b549a/content/renderer/input/input_event_filter.h
[modify] https://crrev.com/5041a16e38bf17352fb59d805c2cab35242b549a/content/renderer/input/input_event_filter_unittest.cc
[modify] https://crrev.com/5041a16e38bf17352fb59d805c2cab35242b549a/content/renderer/input/input_handler_manager.cc
[modify] https://crrev.com/5041a16e38bf17352fb59d805c2cab35242b549a/content/renderer/input/input_handler_manager.h
[modify] https://crrev.com/5041a16e38bf17352fb59d805c2cab35242b549a/content/renderer/input/input_handler_manager_client.h
[modify] https://crrev.com/5041a16e38bf17352fb59d805c2cab35242b549a/content/renderer/input/main_thread_event_queue.cc
[modify] https://crrev.com/5041a16e38bf17352fb59d805c2cab35242b549a/content/renderer/input/main_thread_event_queue.h
[modify] https://crrev.com/5041a16e38bf17352fb59d805c2cab35242b549a/content/renderer/input/main_thread_event_queue_unittest.cc
[modify] https://crrev.com/5041a16e38bf17352fb59d805c2cab35242b549a/content/renderer/input/render_widget_input_handler.cc
[modify] https://crrev.com/5041a16e38bf17352fb59d805c2cab35242b549a/content/renderer/input/render_widget_input_handler_delegate.h
[modify] https://crrev.com/5041a16e38bf17352fb59d805c2cab35242b549a/content/renderer/mus/compositor_mus_connection_unittest.cc
[modify] https://crrev.com/5041a16e38bf17352fb59d805c2cab35242b549a/content/renderer/mus/render_widget_mus_connection.cc
[modify] https://crrev.com/5041a16e38bf17352fb59d805c2cab35242b549a/content/renderer/mus/render_widget_mus_connection.h
[modify] https://crrev.com/5041a16e38bf17352fb59d805c2cab35242b549a/content/renderer/render_widget.cc
[modify] https://crrev.com/5041a16e38bf17352fb59d805c2cab35242b549a/content/renderer/render_widget.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ae1fbf08fd54ed8bc7290c50ee41e56ac79b78cb

commit ae1fbf08fd54ed8bc7290c50ee41e56ac79b78cb
Author: Dave Tapuska <dtapuska@chromium.org>
Date: Wed Jul 06 23:19:10 2016

Fix M52 only android build failure.

change 5041a16e38bf17352fb59d805c2cab35242b549a was merged into M52 but
failed on android because trunk doesn't contain the code anymore.

Patch the code manually to fix the build.

BUG= 616991 

(cherry picked from commit 2ad437491349565cfe2a9d38ccbc469febdb2399)

Review URL: https://codereview.chromium.org/2126013003 .

Cr-Commit-Position: refs/branch-heads/2743@{#590}
Cr-Branched-From: 2b3ae3b8090361f8af5a611712fc1a5ab2de53cb-refs/heads/master@{#394939}

[modify] https://crrev.com/ae1fbf08fd54ed8bc7290c50ee41e56ac79b78cb/content/renderer/android/synchronous_compositor_filter.cc
[modify] https://crrev.com/ae1fbf08fd54ed8bc7290c50ee41e56ac79b78cb/content/renderer/android/synchronous_compositor_filter.h

Issue 607128 has been merged into this issue.

Issue 621303 has been merged into this issue.

Issue 622230 has been merged into this issue.

Issue 608306 has been merged into this issue.