Tested the issue using #66.0.3359.158 on Nexus 6P; 8.1.0 as per the steps mentioned in original comment and could not reproduce the issue. The white sidebar is getting extended upto Ominbox.

@Reporter: Could you please let us know the details of your device for further triaging and if possible attach a screencast for further triaging?

Thanks!!

I've encountered this issue on a Samsung S9+ running Android 8.0.0, a OnePlus 3T running Android 8.0.0, and a Motorola phone running Android 7.x (not sure on the details of the Motorola device).

A screencast of the issue is attached. In the video, I take the following steps using the same CodePen demo linked above:

- reload page
- scroll up and down on the blue background a few times to show the expected behavior
- make a swipe on the white fixed position sidebar, this initiates the bugged state
- demonstrate that scrolling down the page and hiding the omnibox no longer affects the sidebar
- demonstrate the incorrect hit testing on the buttons (and how it only takes place when omnibox is hidden)
- reload the page again
- scroll down to hide omnibox; observe sidebar expanding
- make a swipe gesture on sidebar to initiate bug, this time in the expanded state
- scroll page up to reveal omnibox, observing how the omnibox now covers up the sidebar
- demonstrate the incorrect hit testing on buttons again, but in the reverse direction

Let me know if there's anything else I can help with. Thanks!

Deleted: chrome-bug-848122.mp4 2.5 MB

	chrome-bug-848122.mp4 2.5 MB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Unable to test the issue on the mentioned devices above, as those are not available with us.

@Reporter: Could you please update Chrome to latest version #67.0.3396.68 and check if you still face the issue?

Thanks!!

Co-signing on a similiar issue ... i'm on a Samsung S9+ with Chrome 67.0.3396.68.

I noticed the issue on a site I was developing which has a navigation bar "pinned" to the bottom of the viewport using CSS:

position: fixed
bottom: 0

... which you scroll down and Chrome becomes "chrome-less" (aka the address url bar disappears), it seems to trigger some funky behavior. On my site, the bottom positioned navbar will disappear occasionally or even worse it will stay visible but will not detect touch. (insteads it seems the touch event happens behind the floating navbar ... triggering a click on the dom element that's hidden behind the nav even though the zIndex for the navbar is higher)

You can actually reproduce this by going to instagram.com in browser, scrolling down on your newsfeed a bit to trigger the chrome-less browser state (hidden address bar) and then trying to click on one of the navigation buttons in the bottom position instagram ui bar that's also pinned to the bottom of the browser.

Hi Sandeep,

I have all versions of Chrome up-to-date as far as the Play Store is concerned. I'm currently running:

Stable: 66.0.3359.158
Beta: 67.0.3396.68
Dev: 68.0.3440.14
Canary: 69.0.3451.0

The issue I've described is present on all of the above versions of Chrome, on my OnePlus 3T.

I also confirmed the issue is present on the Samsung S9+ running Chrome 67.0.3396.68.

Is there any chance this problem is resolved with Android 8.1.0, as you mentioned you are using? I'd be surprised if that is the case, but who knows. All of the devices I'm testing with are running Android 8.0.0 or lower.

Also, I assume you've followed all the steps I listed with the video, but I just want to reiterate that the step of doing a *swipe* gesture on the white sidebar is crucial to reproduction. A simple tap on the sidebar won't initiate the bugged behavior.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

 Issue 850889  has been merged into this issue.

Confirmed in 67.0.3396.87 and 68.0.3440.23 but doesn't repro for me in 69.0.3462.0. calebdotmiller@, can you please check the latest canary?

Can confirm this is still an issue on 69.0.3462.0. The same procedure on the CodePen demo still triggers the bug for me.

You're right, it took a bit more work but seems to repro there as well. thanks, will investigate.

Seems like it does not require touch:none to trigger.

Using the attached file, scroll really really fast to the bottom (within about 0.2 seconds).

If the red sidebar does not stay attached to the top of screen, the bugged state is triggered.

In the bugged state, clicks land about one omnibox away from where they should be (i.e. clicking on 6 presses 8)

The opposite can be triggered by scrolling up really fast.

Deleted: scrollbug.html 5.4 KB

scrollbug.html 5.4 KB View Download

Deleted: Screenshot_2018-06-19-00-51-19-41.png 150 KB

	Screenshot_2018-06-19-00-51-19-41.png 150 KB View Download

Also, if it helps: once Chrome gets into the bugged state, rotating the phone to try to re-layout the page would not get it out of the bugged state.

The position:fixed, top:0, bottom:0 element is still one omnibox away from the top of screen, and clicks are still landing one omnibox below where they should be.

@mings Running your HTML file on the current Stable & Canary builds, and scrolling violently, I can't reproduce the same issue. I can get the omnibox to overlap a few of the fixed list items on Stable, but upon tapping, the correct element is still targeted. What version of Chrome are you using?

Also, in the CodePen demo I've linked, if I comment out the `touch-action: none` line, the issue no longer manifests. The only way I've personally been able to repro this is when `touch-action: none` is used. It sounds like you might be onto something, but unfortunately I can't see it! I do like your use of an "omnibox unit", though :)

@calebdot  67.0.3396.87 on Android 6.0.1 on OPPO A57.

Yes it seems to be easier to reproduce with touch-action:none, but I managed to do it without.

I think I managed to consistently trigger the bug on 67.0.3396.87 on Android 6.0.1.

Using the attached scrollbug.html from Comment 13:

1) Fling upwards (means scroll downwards) at a speed which causes omnibox to hide updwards.
2) While page is scrolling downwards under inertia, fling downwards again.

The key is 2 flings to trigger the internal confusion.

@mings Hey, that does the trick. I think you meant "fling *upwards* again", but yes if I perform two swipe up gestures in quick succession, where the second swipe up happens mid-scroll while the document is coasting on its own, the same bug occurs.

This same trick does indeed work on my CodePen, even with `touch-action: none` commented out. It is harder to perform, but it's consistent once you figure it out. Nice find!!

This seems to prove that `touch-action: none` isn't a requirement. The title of this issue may be misleading.

I wonder if performing a swipe gesture on an element with `touch-action: none` triggers the same internal state as when the page is scrolling from inertia, but without actually scrolling. So then it gets "stuck" in that state and doesn't reset. Just a wild guess, but that would explain why `touch-action: none` and a swipe makes it easier to repro, because there's no longer a strict timing requirement.

I wonder if the issue described by @webworld is the same one @mings demonstrated, since `touch-action: none` didn't seem to play a part. I can reproduce the issue on Instagram as mentioned, by scrolling quickly as described by @mings.

I think we've encountered a slight variation of this issue (or mings.. must refer to this when stating 'The opposite can be triggered by scrolling up really fast'). The result is also an offset in the place where a push/click is registered compared to where it is shown on an android device. 

Symptoms:
In the example given in Comment 13: we noticed that the red area would show up underneath the omnibox (approximately until line 5). When trying to click on link 8 it would register the click as if we where clicking line 2 or so.

We've also create a small example to reproduce the issue but we have only  been able to observe the behavior as primary described: http://embed.plnkr.co/KYXVjVmTrT0eFqedcFxT/

 Issue 854408  has been merged into this issue.

Coming from  Issue 854408  I see many other people here with the same issue. I believe I found a workaround for the issue but would love to get more feedback from people having the same problem so that I can think of pushing this to production (until it's fixed on Chromium).

What I did was replace the offending element with itself (forcing a browser re-layout) on the 'touchend' event. This is perfect because the problem only exists on mobile and 'touchend' does not exist on desktop versions.

Working workaround (hopefully): https://codepen.io/rfgamaral/pen/WyzBay

@mas: After copying your code from codepen i can't seem to see the fix after triggering the bug. 

This workaround would be quite surprising to me if it worked, as the website I was debugging would have fixed itself due to the way it works. (the fixed position element is a modal overlay with dynamic content, showing and hiding that model re-creates the DOM)

Are you saying the workaround didn't work for you?

> (the fixed position element is a modal overlay with dynamic content, showing and hiding that model re-creates the DOM)

Depends, how are you showing/hiding? Are you really adding/removing elements from the DOM or just switching the display property? Those are two different things. The latter might not trigger whatever my workaround triggers in Chrome to fix the issue. Don't know, just thinking out loud.

So far, on my end, I wasn't able to replicate the issue anymore after applying the workaround. i might have to test this a little bit further maybe... That's why I'd love it if more people could try this to reach a conclusion if this is a viable workaround or not.

QA team: a bisect would be very helpful in getting a fix here. The repro in the report worked well for me.

@mas: it does not seem to work for me. Unless I misunderstood React badly, my production code will destroy and re-create the DOM for the fixed-position element.

Using your codepen on 67.0.3396.87:
1) scroll downwards using two flings
2) I need to touch one omnibox above the button to change its color

I want to narrow the triggering conditions a bit more: 

This bug seems to require bottom:0px to trigger.

top:0px elements seem to be immune to this.

This is tested with the fling downwards and fling upwards variants of the bug.

Deleted: test2.html 7.3 KB

test2.html 7.3 KB View Download

I'm seeing this bug with any fixed element, regardless of bottom or top positions. 

This bug also seems to affect the browser's idea of height:100% for position:fixed elements.

1) Use bokan's example https://bokand.github.io/demo/urlbarsize.html
2) Fling up twice as described

Observations:

1) "percentage-based position:fixed" will no longer stretch to fill the viewport height when omnibox is shown
2) OnResize events stopped getting triggered.

Recently we've seen something similar on iOS. It boiled down to not properly passing the visual viewport (if I read correctly).

See webkit bug report: https://bugs.webkit.org/show_bug.cgi?id=176896

This bug affects Discourse, check here for the report: https://meta.discourse.org/t/experiencing-a-lot-of-issues-replying-on-android/84086/31?u=falco

I can repro this on Instagram too, which has a position fixed div in the bottom.

 Issue 855694  has been merged into this issue.

Ok - I have a fix written up, I just need to add tests. Should be able to land it on Monday.

Seems like fixed in canary

I can still repro - my fix hasn't landed yet.

 Issue 850773  has been merged into this issue.

I can see this bug on a site i´m developing with a Floating Action Button (position: fixed; bottom: 15px; right: 15px).

Chrome 67.0.3396.87
Android 8.0.0

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

commit 4b32e5d123858b92e02524bff9a3ecc16ccd692e
Author: David Bokan <bokan@chromium.org>
Date: Mon Jul 09 02:11:59 2018

Stop counting flings in Android gesture listener

This patch changes the Android GestureListenerManagerImpl class to track
ongoing flings as a binary on/off switch, rather than counting
outstanding GestureFlingStarts.

This was previously an integer count as the flings would be processed in
the renderer so the start/end were asynchronous. Now that fling has been
moved into the browser process, we can be immediately sure there's at
most one fling running at any given time.

The attached bug was reproducing because fling boosting
GestureFlingStart events would ACK as consumed [1] to the
GestureListenerManagerImpl class but they wouldn't cause a
GestureFlingEnd. This meant the class would accumulate outstanding
gesture flings, preventing a resize from the URL bar [2] because the class
believed we were still in a scroll.

[1] FlingControllerFilterEvent in InputRouterImpl::SendGestureEvent
[2] GestureStateListener:onScrollingStateChanged in Tab.java

Bug:  848122 
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I69508c3eae88bd528236d7f21cb75136d5f8cc2d
Reviewed-on: https://chromium-review.googlesource.com/1112776
Commit-Queue: David Bokan <bokan@chromium.org>
Reviewed-by: Bo <boliu@chromium.org>
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#573200}
[modify] https://crrev.com/4b32e5d123858b92e02524bff9a3ecc16ccd692e/android_webview/java/src/org/chromium/android_webview/AwContents.java
[modify] https://crrev.com/4b32e5d123858b92e02524bff9a3ecc16ccd692e/chrome/android/javatests/src/org/chromium/chrome/browser/TabsTest.java
[modify] https://crrev.com/4b32e5d123858b92e02524bff9a3ecc16ccd692e/chrome/android/javatests/src/org/chromium/chrome/browser/fullscreen/FullscreenManagerTest.java
[modify] https://crrev.com/4b32e5d123858b92e02524bff9a3ecc16ccd692e/chrome/android/javatests/src/org/chromium/chrome/browser/fullscreen/FullscreenManagerTestUtils.java
[modify] https://crrev.com/4b32e5d123858b92e02524bff9a3ecc16ccd692e/content/browser/android/content_ui_event_handler.cc
[modify] https://crrev.com/4b32e5d123858b92e02524bff9a3ecc16ccd692e/content/browser/renderer_host/render_widget_host_view_android.cc
[modify] https://crrev.com/4b32e5d123858b92e02524bff9a3ecc16ccd692e/content/public/android/java/src/org/chromium/content/browser/ContentUiEventHandler.java
[modify] https://crrev.com/4b32e5d123858b92e02524bff9a3ecc16ccd692e/content/public/android/java/src/org/chromium/content/browser/GestureListenerManagerImpl.java
[modify] https://crrev.com/4b32e5d123858b92e02524bff9a3ecc16ccd692e/content/public/android/java/src/org/chromium/content/browser/JoystickHandler.java
[modify] https://crrev.com/4b32e5d123858b92e02524bff9a3ecc16ccd692e/content/public/android/javatests/src/org/chromium/content/browser/ContentViewScrollingTest.java
[modify] https://crrev.com/4b32e5d123858b92e02524bff9a3ecc16ccd692e/ui/android/event_forwarder.cc
[modify] https://crrev.com/4b32e5d123858b92e02524bff9a3ecc16ccd692e/ui/android/event_forwarder.h
[modify] https://crrev.com/4b32e5d123858b92e02524bff9a3ecc16ccd692e/ui/android/java/src/org/chromium/ui/base/EventForwarder.java
[modify] https://crrev.com/4b32e5d123858b92e02524bff9a3ecc16ccd692e/ui/events/android/gesture_event_android.cc
[modify] https://crrev.com/4b32e5d123858b92e02524bff9a3ecc16ccd692e/ui/events/android/gesture_event_android.h
[modify] https://crrev.com/4b32e5d123858b92e02524bff9a3ecc16ccd692e/ui/events/blink/blink_event_util.cc

I've confirmed the fix in Canary. Requesting merge to M68.

This bug requires manual review: We are only 13 days from stable.
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), kariahda@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Thanks @bokan, I can also confirm this is resolved in Canary.

So great to hear @bokan! https://media.giphy.com/media/1PMVNNKVIL8Ig/giphy.gif

Thanks for getting to the bottom of the issue :)

Issue 856716 has been merged into this issue.

I'll be OOO so handing off the merge and any followup to sahel@.

Re: merge - the patch should be safe to merge. It looks larger than it is because most of the changes are tests and renaming. The functional change is fairly minor. I believe the risk is justified as this is a fairly nasty bug and commonly hit (see # of stars).

I am not comfortable merging this change into M68 at this time. It looks very risky and that's a lot of code change.

Can this wait for M69? What is the rationale behind merging it into M68?

>I am not comfortable merging this change into M68 at this time. It looks very risky and that's a lot of code change.
I have reviewed the cl and can confirm that as bokan mentioned, the functional change is minor. GestureListenerManagerImpl.java has the main changes and the rest of the changes are tests and/or necessary plumbing for prevent_boosting.

>Can this wait for M69? What is the rationale behind merging it into M68?
I cannot comment on the necessity of the merge, since bokan@ is OOO, maybe pnangunoori@
or other people cc'ed have a better idea.

If it helps with a merge decision I am the reporter of  Issue 850773 , the fix for this bug should fix mine. I have been seeing this issue daily in Chrome Dev since before June 7 when I reported it. 

Just want to highlight that this bug breaks:

- Twitter
- Instagram
- Discourse

and every site that uses infinite scroll and has a fixed div.

I think it's reasonable to evaluate fast tracking this into stable sooner.

Agreed with the others here, the faster this gets out the better. This bug plagues our mobile sites main navigation as well as modals and other fixed elements. It completely cripples the UI and therefore diminishes the UX. Please do what you can to fast track this.

If it helps, I'd also like to emphasize that a a fast release of this fix seems necessary. Our application is served to approximately half a million users that now have a flawed user experience. We've had to advice our users to temporarily use other browsers or to try to workaround by scrolling outside the modal panels that are affected. All in all, the impact is pretty high for something that 'should just work'.

Thanks all for your input! Really appreciated!

Let's get this fix into M68 which is going to be released soon.

 Issue 854088  has been merged into this issue.

The fix is merged to M68:
https://chromium-review.googlesource.com/c/chromium/src/+/1134192

I have the same issue on my Android in a very similar scenario of another major project, the tap area and the rendered area of a Div button go out of sync after some URL bar scrolling, I hope this gets fixed quickly, it gives a real bad UX , thank you very much 

 Issue 862130  has been merged into this issue.

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

 Issue 863754  has been merged into this issue.

This issue also affects Airbnb.

Is there a confirmed workaround for this bug?

A new version of Chrome (v68) which contains the fix has been released yesterday. But if you can't use that (yet) we've experienced that you can force a rerender/reset of the touch offset by scrolling somewhere outside of the element that is on top. 

Were you able to make this happen with code without affecting the UX?

Hello, 

I have been able to reproduce a very similar bug. Rendering is broken when fixed element (with top:0, bottom:0) is added to DOM when address bar is animating. Timing is a bit tricky to get, but see attached recording of what happens. Also the html that I used to reproduce this bug. For real world implications this will break adding modals, meaning that user experience is very poor, when some backdrop is completely off. 

Because this particular bug was reported as fixed I tried and succeeded to reproduce this in canary 70.0.3503. If Im correct at reading release notes, this bug should have been fixed in previous version, meaning this is corner case. 

Deleted: index.html 898 bytes

index.html 898 bytes View Download

Deleted: bug_demo_chrome.mp4 274 KB

	bug_demo_chrome.mp4 274 KB View Download

l.kadikinaite@ what you described in comment #66 is a different issue, please file a new bug with steps to reproduce it.

 Issue 869251  has been merged into this issue.