iOS keyboard covers a contenteditable div and is not scrollable while focused
Reported by
ch...@xenforo.com,
Nov 30 2016
|
|||||||
Issue descriptionExample URL: https://xenforo.com/bugs/chrome-ios-contenteditable-scroll.html Steps to reproduce the problem: 1. Load the demo URL 2. Scroll down to the editor, focus it, and fill it with some text or line breaks 3. While the editor is focused, try to scroll. The page will jump, the keyboard will cover the editor (either partially or totally) and you will be unable to scroll. What is the expected behavior? Test the same page in Safari on iOS for the desired behaviour - the page should still scroll even while the editor went focused. What went wrong? The keyboard will either totally or partially cover the editor, you therefore can't see what you have typed, or in some cases can't see where the caret is. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? Yes Chrome version: 55.0.2883.55 Channel: beta OS Version: 10.2 Flash Version: This will ultimately effect a great number of online applications which make use of a rich text editor type system, which often use contenteditable divs for containing the editor contents.
,
Dec 1 2016
Confirmed on 55, 56 and 57. Does not repro on Firefox.
,
Dec 2 2016
,
Dec 19 2016
Any update on this at all, guys? This is affecting all iOS Chrome users of our software, and has the potential to affect many thousands of users of similar software.
,
Dec 19 2016
This works fine in ios_web_shell and broken in Chrome for iOS. The issue is reproducible in Chrome with Safari user agent, so it can be caused by our scripts (like Autofill).
,
Dec 19 2016
Sorry to be "that guy" who bumps a report, earlier. Thanks for replying eugene, much appreciated :)
,
Dec 19 2016
This is a regression caused by Pull To Action changes. Pull To Action restores content inset when scrolling ends and assumes that left-right-bottom insets are always 0. When keyboard is displayed, bottom inset is not zero and should not be reset to zero.
,
Dec 22 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/0774dcc15d6c7f59bcca77b5c2d1288b49911707 commit 0774dcc15d6c7f59bcca77b5c2d1288b49911707 Author: eugenebut <eugenebut@chromium.org> Date: Thu Dec 22 00:07:06 2016 [ios] Fixed web-compat bug related to resetting top content inset. OverscrollActionsController resets top content inset every time when scolling is finished. Before this change it assumed that bottom inset should be always reset to 0. This is not correct for cases when soft keyboard is displayed and bottom offset is non-zero to accomodate the keyboard. This CL adds resetScrollViewTopContentInset method and calls it when scrolling is finished. Remaining fixed will be landed in separate CLs to make changes less risky. BUG= 669908 ,675763 Review-Url: https://codereview.chromium.org/2589973004 Cr-Commit-Position: refs/heads/master@{#440273} [modify] https://crrev.com/0774dcc15d6c7f59bcca77b5c2d1288b49911707/ios/chrome/browser/ui/overscroll_actions/overscroll_actions_controller.mm
,
Dec 22 2016
,
Dec 22 2016
,
Jan 3 2017
Page is scrollable when the editor is focused. Looks good with the steps in #0. Verified on iPhone 6s+(10.2) in M57
,
Jan 27 2017
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by baxley@chromium.org
, Dec 1 2016Components: -Blink Mobile>WebView>Glue
Labels: -Arch-x86_64