New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 599271 link

Starred by 4 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 3
Type: Bug



Sign in to add a comment

Android WebView Scrolling error with densities

Reported by jetison...@gmail.com, Mar 30 2016

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.87 Safari/537.36

Steps to reproduce the problem:
1. Build repro app: https://github.com/FaultException/WebViewDensityRepro
2. Run on Nexus 5X
3. Tap "Scroll with Java"
4. See the very thin red line at the left edge? The app scrolls by the exact size of the view/screen (1080) and there's two divs in the page, both full width. (The page also has a device-width viewport.)
5. Hit "Scroll with JavaScript"
6. See there is now no red line, but the app ends up at scroll position 1082, which is bigger than the screen.
7. Run on Nexus 5 (original) and see that there is no red line when scrolling by either.

What is the expected behavior?
There would be no red lines on either devices when scrolled by Java.

What went wrong?
It seems to be an issue with densities.

The 5X has an odd density of 420 (2.625 times MDPI).
The 5 Original has a density of 480 (3 times MDPI).

The screen from JavaScript on the 5X reports being 412 pixels wide, and 412 x 2.625 is 1081.5, not 1080 which is the actual screen size.

For some reason when scrolling from the Android framework I must use 1081.5 instead of the actual screen size to scroll one full page width.

Did this work before? N/A 

Chrome version: 49.0.2623.87  Channel: n/a
OS Version: 10.0
Flash Version: Shockwave Flash 21.0 r0
 
Dangit, posted as wrong OS... This is for Android/Mobile obviously.
Components: Blink>Scroll Mobile>WebView
Labels: -OS-Windows OS-Android

Comment 3 by bokan@chromium.org, Mar 31 2016

Cc: bokan@chromium.org aelias@chromium.org osh...@chromium.org boliu@chromium.org
Hmm, it does seem odd that the DPR on the 5X is rounded like that...it should be closer to 2.621.

+oshima@, from your work on DPR/CSS Zoom in Blink, do you know where the DPR is calculated and if this is expected?

+aelias@/boliu@ for how WebView handles these subpixel scroll cases since the issue here seems to be with the WebView scroll apis. I'm unable to build/install WebView apps on my 5X due to lack of USB-C laptop/cable.

Comment 4 by osh...@chromium.org, Mar 31 2016

Blink's DPR calculation is here:

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/frame/LocalFrame.cpp&rcl=1459423839&l=621

This has been this way before my work.

And as bokan@ said, nexus5x's device pixel ratio should be ~2.6, not 3. (https://bjango.com/articles/min-device-pixel-ratio/)

Comment 5 by aelias@chromium.org, Mar 31 2016

Owner: bokan@chromium.org
Status: Assigned (was: Unconfirmed)
There's a long tail of off-by-one bugs in viewport/document width sizing under DPR, that sometimes we can get away with shipping for a long time because the symptoms are not too severe.  It's possible this problem may also exist in Chrome (we shouldn't assume it's only on WebView before checking).

If it only reproes in WebView and/or WebView TestShell, I would suspect one of the codepaths triggered by the Android WebView quirk flags may be involved, particularly wideViewportQuirkEnabled, useWideViewport, loadWithOverviewMode, and forceZeroLayoutHeight.  WebView scrolling through the usual CC code, so the problem probably lies in how we initialize the viewport and content widths in the first place.

I'll assign to bokan@ since you're the viewport expert (you can get to it when you obtain a USB A-to-C cable), let me know if you have more questions about WebView.

Comment 6 by boliu@chromium.org, Mar 31 2016

If it's webview only, could also be from stuff in webview for hooking up to the root layer scroll, eg BrowserViewRenderer::ScrollTo

Comment 7 by bokan@chromium.org, May 25 2017

Labels: -Pri-2 Hotlist-Input-Dev Pri-3
Triage check-in. This is probably still worth investigating but it's not severe enough to warrant prioritisation. Perhaps as part of some other DSF related work.

Sign in to add a comment