Hello, Google?  Is anybody working on this bug?  It still exists, even after applying all of today's monthly app updates.

Hello

Can you please provide your device details, like name, model, android version?

Device name:  BlackBerry PRIV
Device Model:  STV100-2
Android version:  6.0.1
Patch level:  March 5, 2017
Kernel version:  3.10.84-perf-gaabbea9
Build number:  AAJ926
Gmail App version:  7.4.23.154506495.release
BlackBerry Keyboard version:  2.6.0.11265

Thank you for providing more feedback. Adding requester "ppolisetty@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Is anybody at Google or BlackBerry trying to fix this very bad bug?

I gave up and bought a BlackBerry KeyONE to replace my PRIV, and the same bug exists in the brand-new KeyOne!  I've also noticed that it happens not only in Gmail, but also in the BlackBerry Hub when composing a new email message.

New device (same old bug) info:

Device name:  BlackBerry KeyONE
Device Model:  BBB100-1
Android version:  7.1.1
Patch level:  April 5, 2017
Kernel version:  3.18.31-perf-g7381ac5
Build number:  AAL093
BlackBerry Hub version:  1.5.1.12605
BlackBerry Keyboard version:  2.5.1.11075

Hello everybody,

My brand new KEYone also has this unbearable bug, rendering it useless for me :-( 

Of course, everything is up to date. 

Device name:  BlackBerry KeyONE
Device Model:  BBB100-2
Android version:  7.1.1
Patch level:  April 5, 2017
Kernel version:  3.18.31-perf-g7aee73f
Build number:  AAK819
BlackBerry Hub version:  1.5.3.13082
BlackBerry Keyboard version:  2.7.0.11589


Please let us know of an alternative if you can! Many thanks. 

Issue is reproducible, tested on Blackberry Priv/AAD442/5.1.1, Device Model:  STV100-1.

This is a regression issue broken in M-57.

Per-Version bisect information:
Good build: 57.0.2951.4
Bad build: 57.0.2952.0

Bisect Range:https://chromium.googlesource.com/chromium/src/+log/57.0.2951.4..57.0.2952.0?pretty=fuller&n=10000

Since it is OEM specific we could not get Per-CL bisect information.

Logs @ http://go/chrome-androidlogs1/7/712380

sgurun@, can you please take a look and assign it to the right owner? 

Himm, I wonder why blackberry did not open a bug, or if it did how was it concluded. 

It is probably a blink related issue. 

The same bug exists on the new BlackBerry KeyONE, BBB100-1, which is
actally manufactured by TCL.

I had reported this bug to BlackBerry via their user forum on
CrackBerry.com. The BlackBerry monitor there referred me to this website to
file the bug report. It's been a few months now.

Yeah that is bad. thanks for clearly description in the bug.

Satya: do we have a userdebug blackberry? 

Changwan/Aelias: any ideas?

The bisect range is large but http://crrev.com/438490 "Introduce InsertIncrementalTextCommand to respect existing style for composition" seems like a fairly likely culprit.

Blackberry keyboard is available on APKMirror: http://www.apkmirror.com/apk/blackberry-limited/blackberry-keyboard/ although I'm not sure whether it would successfully run on non-Blackberry or not.  I'd guess this issue also reproduces in Chrome, not only WebView, unless there is evidence otherwise.

I don't think it should be RBS according to the new criteria in https://chromium.googlesource.com/chromium/src.git/+/master/docs/process/release_blockers.md :
- Severity: Low because this is an optional feature and there are other ways to enter addresses (copy/paste)
- Users affected: Low because Blackberry has small market share
- Already shipped in 3 stable releases.

I think we should still follow up and fix because it may be a theoretically incorrect behavior on our part that may cause other bugs, but not urgently.

We've already landed https://codereview.chromium.org/2763873003 to fix its major issue caused by http://crrev.com/438490. Could someone test against M58 or later version?

ppolisetty@, please confirm whether or not this issue still reproes on latest M60.  If it still reproes, please reassign to changwan@.

aelias@, I could still repro the issue with latest M60, Webview:60.0.3112.51 on Blackberry  Priv.

I've added logcat & screenshot to http://go/chrome-androidlogs1/7/712380

#11 - sgurun@, we don't have user debug blackberry.

Please attempt to repro the problem in Chrome (for example, on http://textarea.org/), and if it reproes there, then I'd like an exact bisect to confirm/disconfirm the theory that http://crrev.com/438490 is the culprit.  If only repro in WebView, fine to just remove Needs-Bisect label.

aelias@, I could not repro this issue on Chrome: 60.0.3112.51 & 58.0.3029.83(did not test M59) with http://textarea.org/. 

I'm unable to add screenshot of Chrome behavior to http://go/chrome-androidlogs1/7/712380, I keep getting server error.

aelias@, screenshot added :blackberry_chrome_60.0.3112.51.png to http://go/chrome-androidlogs1/7/712380

This appears to be an issue with contenteditable elements, textareas are not affected

FYI

I have been experiencing this issue on DTEK50, Samsung S7 with BlackBerry Hub subscription and now on the KeyOne and S8. I found that if you turn off text formating in the Hub email it works fine just like in any other field on any app that is not set for html formating. It is very annoying and hopeful will get fixed soon. 

I checked out Chromium to the http://crrev.com/438490 patch (ef5c846a3e5d3c994d962ddca7d40f4bc1476044) and built. With multiline text to insert only the first line was inserted, but it was not garbled. I then checked out and built to the change (afdef36fb3116c5b6e07a5727bf9ee42e690ed4e) before the incremental insertion patch and the multiline text to insert was displayed normally.

I tested the text insertion with a content editable element. Based on this it appears there was a problem with initial patch and one or subsequent patches which added multiline support. 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/20b5f338855c0349685cebd889302e62537fb12d

commit 20b5f338855c0349685cebd889302e62537fb12d
Author: Changwan Ryu <changwan@chromium.org>
Date: Fri Jul 21 08:11:21 2017

Fix multiline incremental insertion

The previous fixing attempt for multiline insertion
(http://crrev.com/2680733002) only worked for two-line text, and this CL
allows for incremental insertion of three or more lines of text.

Since selection is shifted after insertion, we need to update the
selection start offset that will be used in adjusting selection for
incremental insertion.

BUG= 712380 

Change-Id: Ibb3212bd78fc7e30232aaa6b780c0c1182b63d1c
Reviewed-on: https://chromium-review.googlesource.com/580496
Commit-Queue: Yoshifumi Inoue <yosin@chromium.org>
Reviewed-by: Yoshifumi Inoue <yosin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#488616}
[modify] https://crrev.com/20b5f338855c0349685cebd889302e62537fb12d/third_party/WebKit/Source/core/editing/InputMethodControllerTest.cpp
[modify] https://crrev.com/20b5f338855c0349685cebd889302e62537fb12d/third_party/WebKit/Source/core/editing/commands/TypingCommand.cpp
[modify] https://crrev.com/20b5f338855c0349685cebd889302e62537fb12d/third_party/WebKit/Source/core/editing/commands/TypingCommand.h

Thanks changwan@! Can this fix be included in M61? (I'd love to see it in M60 as well, but I realize that it's late for that.)

requesting merge of #24 to fix a regression

Your change meets the bar and is auto-approved for M61. Please go ahead and merge the CL to branch 3163 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), ketakid @(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ac3eaa4bc5de3053f9f5595dd273552be2478bee

commit ac3eaa4bc5de3053f9f5595dd273552be2478bee
Author: Changwan Ryu <changwan@chromium.org>
Date: Tue Jul 25 23:51:56 2017

Fix multiline incremental insertion

The previous fixing attempt for multiline insertion
(http://crrev.com/2680733002) only worked for two-line text, and this CL
allows for incremental insertion of three or more lines of text.

Since selection is shifted after insertion, we need to update the
selection start offset that will be used in adjusting selection for
incremental insertion.

BUG= 712380 

(cherry picked from commit 20b5f338855c0349685cebd889302e62537fb12d)

Change-Id: Ibb3212bd78fc7e30232aaa6b780c0c1182b63d1c
Reviewed-on: https://chromium-review.googlesource.com/580496
Commit-Queue: Yoshifumi Inoue <yosin@chromium.org>
Reviewed-by: Yoshifumi Inoue <yosin@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#488616}
Reviewed-on: https://chromium-review.googlesource.com/585770
Reviewed-by: Changwan Ryu <changwan@chromium.org>
Cr-Commit-Position: refs/branch-heads/3163@{#43}
Cr-Branched-From: ff259bab28b35d242e10186cd63af7ed404fae0d-refs/heads/master@{#488528}
[modify] https://crrev.com/ac3eaa4bc5de3053f9f5595dd273552be2478bee/third_party/WebKit/Source/core/editing/InputMethodControllerTest.cpp
[modify] https://crrev.com/ac3eaa4bc5de3053f9f5595dd273552be2478bee/third_party/WebKit/Source/core/editing/commands/TypingCommand.cpp
[modify] https://crrev.com/ac3eaa4bc5de3053f9f5595dd273552be2478bee/third_party/WebKit/Source/core/editing/commands/TypingCommand.h

I am the original reporter.  This bug's status is listed as Fixed, but it isn't.  When will regular end-users like me actually see the fix pushed to our devices?  My Android received the last monthly update package yesterday, but it still has the same issue with multi-line text substitution as I reported above.

Model number: STV100-2 (BlackBerry Priv, U.S., Verizon)
Android version: 6.0.1
Android security patch level: August 5, 2017
Baseband version: MPSS.BO.2.6.2.c2-00011-M8994FAAAANAZM-1.96809.1.98116.1
Kernel version: 3.10.84-perf-gb0e8ac7 ec_agent@br608cnc #1 Fri Jul 28 15:34:25 EDT 2017
Build number: AAN368
Configuration Version: F15.BB.STV1002.0

Gmail version: 7.7.30.165668480.release
BlackBerry Keyboard version: 3.0.0.12459

Update:

I am the original poster of this bug.  While the bug still exists in the latest Stable version of Android M on the Priv (see posting immediately prior to this one), I can also confirm that the bug is fixed once the current Beta of Webview  (version 6) is installed per LiamQ's instructions here:

https://forums.crackberry.com/showthread.php?t=1105419&p=12998494&viewfull=1#post12998494

Liam mentions that once version 6 of Webview is promoted from Beta to Stable in the next couple of weeks, the bug will be resolved for all users.

Thank you.