I can't get the overlay content to show up.

AFAIU, the issue is because the content specifies the height of the overlay content (div) as viewport height (height: 100%).
When we scroll and the url bar gets hidden, the height of the overlay content (div) suddenly becomes less than the actual viewport height. Once we release the touch, since we resize the viewport size, the content (div) resizes itself to the new viewport size.
It explains the behavior only during scroll (when the resize is still pending).

Still not able to understand one thing here:
Since we removed the touch chaining, why are we scrolling the below content layer? When we started scroll, we should have latched to the top most content (div) and once that layer has scrolled completley, we should have stopped scrolling. Please correct me, if my understanding is wrong. 

Could you attach a video showing the repro?

As to the scroll chaining issue. It looks like the overlay has no scrolling so the scroll will latch to the content below.

Even unable to get the overlay currently. Seems content is changed. :(
I will keep checking and will upload a video if I find the overlay content again.

@bokan
As to the scroll chaining, probably that is correct.
IIRC the content has set the css property 'overscroll-y: auto'.
Since, the height of the div was set to 100%, there will has no scrolling for this content. So the scroll will latch to below content which is seen since top layer content is not 100% of new viewport after scroll. :)

I believe the changes for using the ICB value in the blink should solve this problem. WDYT?

The change to make the ICB not resize from top controls won't help here but it won't hurt either since the overlay is position: fixed, it'll resize when the finger is lifted.

The ideal solution would be to resize position: fixed elements in real-time (i.e. 60fps) but that's not feasible in our current arrangement. Perhaps with compositor worker something like that might become possible.

Removing CSS label as this is not related to the style engine.

Sorry for late response. I forgot to attach the video. :)
Please check the attached video. Let me know if you need any other info.

Deleted: overlay_div_wrong_height_bg_content_scrolling.mp4 8.0 MB

overlay_div_wrong_height_bg_content_scrolling.mp4 8.0 MB Download

I got the overlay to show up now. This is working as intended, the overlay is a height:100% position: fixed element. This means that it gets resized at the end of the scroll when you lift your finger.

The "scrolls the background" issue too is a problem in that there's no easy way to control scroll chaining on the web. This is a long standing issue, tracked in  issue 162179 . One potential solution is the non document root scroller proposal (https://github.com/bokand/NonDocumentRootScroller), tracked in  issue 505516 .

Aside from that, there's no bug on our side here so I'm going to close this.

As commented in previous comments, even I felt the resize of overlay is not an issue. It is working as intended.
The major issue, as I felt was that the background content is scrolling giving ugly experience.
As I was not sure whether the non-document root scroller proposal by you would solve the issue or not, I raised the issue separately.
Would be checking the non-document root scroller implementation to observe for this issue resolution. :)

Unfortunately, non-document root scroller would only help if the website is redesigned to use it (once/if it ships).  Issue 162179  is the one to watch for this, IMO. Should also note, Firefox behaves the same way here so it's technically an issue with the website.

Perhaps in the short term we shouldn't be bubbling scroll from a position:fixed element. That could have other consequences but I can't think of why you'd want that to happen. tdresser@, thoughts?

I agree that its a content issue. All mobile browsers (incl safari, firefox, opera etc.) are showing same behavior.

I just thought it would be cool if chromium can handle even this content graciously to avoid the awkward experience during scroll. :).

It's hard to estimate how much content would break if fixed position elements didn't bubble scroll.

I suspect that this would make the user experience slightly worse on a lot of sites. For example, any site with a fixed position header would now have regions you can swipe in which won't cause scrolling, which is a bit annoying.

We already had this discussion in  http://crbug.com/173403  and concluded at the time that we shouldn't change the default bubbling behavior of fixed-pos but provide an explicit bubbling control CSS.

The change seems a bit too scary.  A seemingly ordinary page have a full-screen transparent fixed-pos overlay, for example.