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

Issue 737257 link

Starred by 2 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug

Blocking:
issue 759812


Participants' hotlists:
Fixing-touch


Sign in to add a comment

Auto scroll doesn't triggered on google presentation/docs web site

Project Member Reported by oka@chromium.org, Jun 27 2017

Issue description

61.0.3138.0 9690.0.0 caroline

What steps will reproduce the problem?
(1) Make sure the device is in tablet mode
(2) Open a presentation on docs.google.com/presentation
(3) Tap the speaker note

What is the expected result?
Virtual keyboard opens and auto scroll happens so that the caret is not occluded by the keyboard.

What happens instead?
Virtual keyboard opens but auto scroll doesn't happen.

 

Comment 1 by oka@chromium.org, Jun 27 2017

Blake, could you take a look?
Status: Assigned (was: Untriaged)
Labels: Pri-2 Type-Bug

Comment 4 by oka@chromium.org, Jul 5 2017

Summary: Auto scroll doesn't triggered on google presentation/docs web site (was: Auto scroll doesn't triggered on google presentation web site)
Auto scroll doesn't work on google docs too.

Comment 5 by blakeo@chromium.org, Jul 19 2017

After adding a million print statements to WebKit and poking at the developer console, here's what I figured out:

Slides (and Docs, I assume) uses Sketchy for rendering text. This is an SVG rendered element which is backed by a contenteditable=true element living inside an off-screen iframe as its event target. When you tap on the SVG text in the Speaker Notes field, this offscreen text element is the actual text element that has focus. The iframe has CSS of position:absolute and top:-10000px. When Chrome tries to overscroll to this element, it is actually trying to scroll up, but it can't scroll up beyond the top of the page so it looks like it does nothing (not that you would want it to scroll up. You want it to scroll down to the SVG rendered text). 

Possible fixes:
- Hand this off to the Sketchy team as an accessibility bug. You can repro this on Chrome in Android (if you request desktop site so that it doesn't direct you to use the app instead). A potential fix on their end is to modify the margins of the body of the offscreen-iframe to match the position of the SVG text editor so that WebKit will try to scroll to the correct place. The downside of this is this is JUST a sketchy fix. There are numerous other websites with rich text editing capabilities that are probably doing something similar to Sketchy. But even if this isn't the end-all fix, they should probably be given a bug anyway. 
- Add a hack to check to see if the bounds of the text field contain the location of the click. If not, scroll to the click instead of the cursor. This is more general but more hacky and I'm not even sure if access to the click information is available at this point in the code. Most of the scroll calculation occurs in the WebKit layer. It finds the text element, the caret, and then invokes the scrolling virtual function without any handoff to Chrome code, so it may be difficult to find a place to add this. 
- Something else?

Comment 6 by blakeo@chromium.org, Sep 20 2017

Blocking: 759812
Labels: M-66
Issue 759812 has been merged into this issue.
This bug has a target milestone that has passed.  Please help bug cleanup: mark it closed or update/remove the milestone target. 
Labels: -M-66
Owner: ----
Status: Available (was: Assigned)
Labels: -Pri-2 Pri-3

Sign in to add a comment