editablecontent sometimes has strange scrolling
Reported by
kmans...@gmail.com,
Feb 28 2018
|
|||
Issue descriptionSteps to reproduce the problem: Possibly related / similar to: https://bugs.chromium.org/p/chromium/issues/detail?id=584978 We have an Android app that uses WebView with contenteditable as its email message editor. The WebView is set to layout_height=wrap_content and is inside a ScrollView (afaik, other email apps including Gmail use this overall scheme for their compose screens, not match_content). There is a <div> with contenteditable=true and that's our editor. 1. If we start typing newlines 2. After a few (blank) newlines 3. WebView decides to scroll itself 4. Our code subscribes to selectionchange event, gets current selection, gets its rangeAt(0), gets its bounding rectange 5. And scrolls the scroll view to keep the cursor visible on the screen (e.g. above the soft keyboard). Still, sometimes the cursor goes under the keyboard. We tracked it down to "3." above - that WebView, due to some logic it has, decides to scroll itself, apparently after 2-3-4 blank lines added with Enter. Then as soon as there is an actual character typed, WebView decides to un-scroll itself back to y=0, and our cursor position is correct again (above the keyboard, not slid under it). --- Our WebView is set to layout_height=wrap_content, so it really has no reason to scroll, and the logic when it decides to do that seems somewhat arbitrary. Would it be possible to add a check in WebView and make it disable the logic for "user typed a few newlines, I'm going to scroll" for wrap_content? The fact that WebView decides to un-scroll itself as soon as the user types something, makes it look more like a bug. What is the expected behavior? WebView not trying to scroll on text input (inside contenteditable) if it's set to layout_height=wrap_content What went wrong? WebView scrolling on text input inside contenteditable, sometimes, and sometimes un-scrolling itself. Did this work before? N/A Chrome version: 64.0.3282.137 Channel: stable OS Version: 7.0 Flash Version: I checked what happens in Gmail app, I think they scroll their WebView back to scrollY = 0 if they see any actual scrolling. This causes a noticeable erase / draw flicker if you add a line of text before starting to add blank lines, I've got a video I could share. I too tried scrollTo(getScrollX(), 0) in our code and got that flicker too, so that would not be a good workaround, and I hope the issue can be fixed at its root, in WebView.
,
Mar 1 2018
@kmansoft: Thanks for the report Could you please attach a sample app or .apk file where you're seeing this issue and the details of your device and if possible attach a screencast as well for triaging of the issue? Thanks!!
,
Apr 19 2018
Closing this issue as there is no response from the reporter. Please update your Chrome to #65.0.3325.109 and feel free to file a new issue if the issue is still observed. Thanks!
,
Apr 20 2018
Sorry I'd missed comment #2. Yes the issue still exists in WebView 66.0.3359.106 Sample app: https://play.google.com/store/apps/details?id=org.kman.AquaMail 1 - Add an account 2 - Start the compose screen 3 - Menu -> Add text formatting 4 - Type a few (3-5-7 or so) blank lines in a row 5 - I assume you'll have a way to attach to WebView code with a debugger -> you'll see that WebView will scroll its content by about 9-15 pixels. 6 - If not - please enable app settings -> debug -> debug log, set its output to logcat and you'll see things like: 04-20 21:39:50.991 I/chromium(13844): [INFO:CONSOLE(7)] "window.scrollY = 15", source: file:///android_asset/web_editor.js (7) You won't see anything wrong in the app's UI because we undo this scrolling. I believe WebView does this because it assumes that it is *the* scrollable "thing" here - i.e. it assumes that it's not inside a ScrollView and its height is not wrap_content. Still would be nice to fix this at the source, in WebView. You might say - duh, don't make WebView height=wrap_content and don't put into a ScrollView. I hear you. But we as well as other apps (I'm quite sure about GMail's compose screen) do this because: Since Android 4.4 it's quite difficult to make a layout that includes a WebView as well as header / footer views and make the whole thing scroll together. Before 4.4 it was quite easy to give WebView a "header" view and that would render and scroll as one piece. And then you could make WebView height = match_parent. Perfect, it just worked. Perhaps you guys might give some thought to adding this capability back (footer views would be nice too). I think you'd "just" need to add in the total height of header + footer when calculating total scroll height, and do some offsetting of mouse events and of render area. |
|||
►
Sign in to add a comment |
|||
Comment 1 by pnangunoori@chromium.org
, Mar 1 2018Labels: Needs-triage-Mobile