Auto scroll doesn't triggered on google presentation/docs web site |
||||||||
Issue description61.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.
,
Jun 30 2017
,
Jul 4 2017
,
Jul 5 2017
Auto scroll doesn't work on google docs too.
,
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?
,
Sep 20 2017
,
Feb 26 2018
,
Jul 4
Issue 759812 has been merged into this issue.
,
Aug 21
This bug has a target milestone that has passed. Please help bug cleanup: mark it closed or update/remove the milestone target.
,
Sep 6
,
Sep 6
|
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by oka@chromium.org
, Jun 27 2017