Tested the issue using #60.0.3112.116 on Android 7.1.2 Pixel XL Build/N2G48E and could not reproduce the issue as per the steps mentioned in comment#0.

Able to scroll the DIV elements from left to right after zooming and panning the Google maps.

@maherrj: Could you please add some other info like details of your device, if possible please attach a video of your issue, that would help us in further triaging of the issue.

Thanks!!

Hi Sandeep, Thanks for looking at this.

It's a Samsung Galaxy S7, Android 7.0, kernel 3.18.14-11104523, Chrome 60.0.3112.116.

It may seem hard to reproduce but please persist as the problem is intermittent but reliable.

Please try "Replay several times, or Zoom using the +/- buttons or pinch zoom (after each time scroll up and try again). Also try 2 finger swipe the map right/left then scroll back up to try logWindow scroll.

I can't give you exact gesture sequence as it varies but it WILL happen.

Cheers Richard 

Thank you for providing more feedback. Adding requester "sandeepkumars@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

Able to reproduce the issue in Android. Unable to scroll on the Div after zooming and panning the Google maps as per the steps mentioned in comment #0.

This seems to be a Non-Regression issue as same behavior is seen since M52 in Samsung Galaxy S7

Chrome versions tested
60.0.3112.116
63.0.3218.0

OS
Android 6.0.1, 

Android Devices
Samsung Galaxy S7, 6.0.1: SM-G930F Build/MMB29K

Issue is seen in M63 as well

Unable to provide the logs and videos as issue is reproducible intermittently.

Thanks!!

Thanks for sticking with it! Please let me know if I can provide any
further information or assistance. Once again, does not occur on Firefox.
Cheers.

Hi maherrj@,

Could you provide a reduced test case? I'm having a hard time generating enough location points. That or provide a way to inject some "fake locations" into the page. Thanks.

If you're still having trouble I can provide a version with some hard-coded
locations but please try this first: -

Note: You only need one additional, and different, location apart from the
Start, and that step in the journey must be sans-loiter. (Can't have been
standing for 50secs). When you press "Arrive" the current location is
retrieved and, even if you haven't moved, can be several meters from the
start location reading. Finally you only need one journey to reproduce the
bug. Once you have that just don't close the App and you can hit "Replay"
as many times as you want. So: -

1) Start the app by tapping the Ginger Bread house
2) Wait about 20secs and then press end.
3) If you get the error "You need to get out more" turn off the wi-fi
network and try again Or go near a window. and go back to (1)
4) If the Trip Summary displays, note that the scrolling of the previous
DIV is already disabled.
5) Press "Map Trip" If scrolling is not disabled try
a) Press "Replay" and check again
b) Zoom out and check again
c) Two finger swipe the Hat off the map and check scrolling again

The (a) to (c) varies in combination but some small number and type of map
interactions will alternately disable and re-enable scrolling on the
original Trip Log logWindow.

HTH

Let me know if still no good.

Cheesr

Another alternative is that Chrome lets you go Dev Tools...->More
Tools->Sensors->Location->Custom location and set the location that way.

Make it Berlin if you want, the trip doesn't matter in this case. But at
least you can reproduce it on the desktop for easy debugging?

Ok, thanks, managed to repro using dev tools. I'll dig into it a bit more...

Ok, it looks like the #logWindow Element gets composited when we first click "Arrive". The reason is it may overlap another composited Element.

But it looks like it scrolls on the main thread. When we do successfully scroll it it's scrolls on main. (I think main-thread scrolling is forced by box-shadow).

From Dev Tools it seems like it doesn't have a main-thread scrolling reason though. A trace showed that we do call into LayerTreeHostImpl::ScrollBy when we try to scroll it (and it then fails). After a resize, the scrolls go to the main thread. This looks like a case where we're not correctly propagating a MainThreadScrollingReason in CC.

I imagine we're probably hitting a DCHECK somewhere, unfortunately I can't get there as we hit other DCHECKs on load :(

flackr@, mind triaging this further?

Really appreciate the progress on this. If a work-around becomes clear (such as turn off box-shadow) before a resolution that would be good also.

Can I please also beg everyone on the recipient list to look at my Backgrounf-Geolocation POC example as developers?

Do you not agree that that the ServiceWorker pattern is the most appropriate and efficient architecture delivery mechanism for background geolocation?

You people familiar with the UA code must agree that the TravelManagerPolyfill would be very easy to implement?

maherrj@, yeah, I think turning off box-shadow and or border-radius should help but I can't try this myself to verify. that said, that's a bit sad and it seems like we have an edge case where Chrome is breaking down so we should definitely fix it on our end.

As to your ideas on geolocation, you're unlikely to get much input here. You'd be better off filing a new bug at crbug.com/new with a feature request or taking the discussion to a more public facing group like https://discourse.wicg.io/

@bokan you're right! It was the redundant border-radius on #logWindow .log

/* border-radius: 1.0em; */

box-shadow did not seem to play a part. #logScroll already had a border radius set so no loss of functionality.

I'm happy if you want to just close this ticket. If you do wish to pursue it, don't forget that all you have to do is copy the files from here https://drive.google.com/open?id=0B7Rmd3Rn8_hDNW1zSWRoXzBTclU to your own server and it works.

Thanks for your help!

FWIW, on Android Browser the corners of #logWindow orginally honour the border-radius setting but revert to pointy/square corners when a log entry is added and scrollTop is set. Chrome, FF, and Opera all preserve the border-radius.

Any update on this?  Do we want to close it as WAI?