Scroll on portlets will not work for authenticated users on first tap on Chrome for Android

• Type: Bug
• Status: Closed
• Resolution: Fixed
• Affects Version/s: 7.0.X, Master
• Fix Version/s: 7.0.0 DXP FP42, 7.0.6 CE GA7, 7.0.0 DXP SP8, 7.0.X, 7.1.0 M2, 7.1.X, Master
• Component/s: Frontend Infrastructure
• Labels:
  • ee-ts
  • liferay-digital-enterprise-70-sp8
  • liferay-fixpack-de-42-7010
• Branch Version/s:
  7.0.x
• Backported to Branch:
  Committed
• Fix Priority: 1
• Git Pull Request: https://github.com/brianchandotcom/liferay-portal/pull/56033

Reproduction steps:
1) Patch vanilla DXP with de-39 and start the server, login on Desktop browser
2) Add a Web Content Display portlet on the Welcome page and enter a very long text into it, something of about 100+ lines so that scrolling is enabled, publish
3) Access the page on mobile browser: latest Chrome for Android, incognito mode, and login with OmniAdmin user
4) Tap inside the area of the Web Content Display portlet and move from down to upwards to scroll the web content:

Expected: The scroll to work
Actual behavior: Nothing will happen

5) Detach your finger from the screen and repeat step 4)

Actual behavior: Scrolling will now work

6) Go back to step 3 and instead of tapping inside the Web Content Display div, tap upper, e.g. where the Site Name and header are:

Actual behavior: Scrolling will work at first attempt

7) Logout from DXP (visit the same page as Guest) and tap inside the Web Content Display div:

Actual behavior: Scrolling will work at first attempt

Reproduced on ee-private-7.0.x @ 788161b414cefb00a136311c0fd55391a431eeee
Reproduced on master @ 9f2cbbd236513332dca1ef619bca3dec6616a4c1

If I enforce the rule: overflow: scroll; to the Web Content Display portlet, the issue won't happen, however, on Desktop, the portlet will behave strangely (no chance for example to configure it afterwards)

It does not happen on Chrome for iPhone, Safari, Firefox for Android / UC Browser for Android

If you use a large blog post, and Blogs portlet you can see same behaviour. It is not "Web Content Display" exclusive