New issue
Advanced search Search tips

Issue 795386 link

Starred by 2 users

Issue metadata

Status: Started
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome
Pri: 1
Type: Bug

Blocked on:
issue 654917

Blocking:
issue 791225



Sign in to add a comment

Touchscreen scrolling speed in OOPIFs affected by page scale

Project Member Reported by mcnee@chromium.org, Dec 15 2017

Issue description

Chrome Version: 65.0.3296.0

What steps will reproduce the problem?
(1) Run chrome on android with --site-per-process
(2) Visit http://csreis.github.io/tests/cross-site-iframe-simple.html
(3) Scroll in the OOPIF
(4) Observe that the speed of the scroll is slower than the speed of the finger
(5) Pinch zoom in a bit
(6) Scroll in the OOPIF
(7) Observe that the speed of the scroll has gotten relatively faster
(8) Pinch zoom all the way in
(9) Scroll in the OOPIF
(10) Observe that the speed of the scroll is faster than the speed of the finger

What is the expected result?
The speed at which the content scrolls should match the speed of the finger.

What happens instead?
The page scale appears to impact the speed of scrolling in the OOPIF.
 

Comment 1 by mcnee@chromium.org, Dec 15 2017

Blocking: 791225

Comment 2 by mcnee@chromium.org, Dec 15 2017

Labels: OS-Chrome OS-Linux OS-Windows
This would affect desktop touchscreens as well, but steps 3-4 don't apply since on desktop we start at page scale 1.0.
I was wondering if this bug should be considered ship blocking for Site Isolation (i.e. if we should add the Proj-SiteIsolation-LaunchBlocking label).  On one hand, this bug is not blocking any functionality - users can still scroll.  On the other hand, the mismatch between finger speed and scroll speed breaks the illusion of interacting with a physical item and seems like an important UX regression.

Comment 4 by creis@chromium.org, Mar 20 2018

Cc: creis@chromium.org
Labels: -Pri-2 Target-67 M-67 Pri-1
Owner: wjmaclean@chromium.org
James, can you help with this or find an owner?  We think it's probably not quite as high priority as the other launch blocking input bugs, but it's still something we'd like to have fixed for M67 if we can.
It's conceivable that this will be fixed by (or will be blocked on) plumbing the page-scale into OOPIFs,  Issue 654917 . Probably blocked on ...

Comment 6 by creis@chromium.org, Mar 29 2018

Blockedon: 654917
Status: Assigned (was: Untriaged)
Cc: riajiang@chromium.org alex...@chromium.org chaopeng@chromium.org sahel@chromium.org
 Issue 878418  has been merged into this issue.
I've just merged  issue 878418  here, and just wanted to note that it still repros even after James's r605456, so it appears that the page-scale fix wasn't enough to fix this.  I think this will be important enough to fix for shipping site isolation on Android.
Status: Started (was: Assigned)
I suspect this is something that gets introduced during event routing ... I don't think we ever expected that my page-scale CL would fix this, but I should try and take a look sometime this week ...
I've tracked this down to where we pull the page scale factor off of the VisualViewport ... OOPIFs don't use this, so we'll need to plumb it from the OOPIF's RenderWidget's LayerTreeHost's external page scale factor.

I'll put up a CL for this tomorrow.
I have a WIP cl for this now at:

https://chromium-review.googlesource.com/c/chromium/src/+/1363358

alexmos@ - feel free to try this out and see if it helps ... there are a lot of scrolling pathways, so I may not have found them all yet.
wjmaclean@ - I tried out your CL in #c12, and it does appear to fix this.  Thanks!
Labels: -Target-67 Proj-SiteIsolationAndroid-BlockingLaunch Target-73
James, is there any more work needed to land the CL at #c12?

I think this will be good to fix for SI on Android, especially given that there's already a WIP CL, hence adding appropriate label.  Let me know if you disagree though.

Sign in to add a comment