Able to reproduce this issue on reported version 65.0.3325.181, on latest beta 66.0.3359.66 and on latest canary 67.0.3382.0 using  Ubuntu 14.04 and Mac 10.13.3 when changed input source to Chinese Pinyin.

Issue is not seen in Windows.

Good Build: 65.0.3291.0
Bad Build: 65.0.3292.0

You are probably looking for a change made after 523243 (known good), but no later than 523244 (first known bad).
CHANGELOG URL:
 https://chromium.googlesource.com/chromium/src/+log/271acc6608e2fc96d3ccf9c73e9f95423d7801db..08e7d08bb2655a8d1d7aafd9db03700492db6722

Reviewed-on: https://chromium-review.googlesource.com/801979

Suspecting same from changelog.

@ rlanday: Please confirm the bug and help in re-assigning if it is not related to your change. Adding RB-Stable for M-65. Please change if not the case.

Thanks! 

 Issue 826686  has been merged into this issue.

We’ve already released M65 so I don’t think this can be ReleaseBlock-Stable for that version. I’ll take a look and see if we can get this fixed for M67.

In TypingCommand::InsertText(), we're setting the following ending selection (used to set the new composition range):

TR (editable)@offsetInAnchor[3] to #text "\u306E"@offsetInAnchor[1]

The table's DOM looks like this at this point:

03-30 03:40:50.282 28037 28073 I chromium: 		TABLE (editable)
03-30 03:40:50.282 28037 28073 I chromium: 			#text "\n    "
03-30 03:40:50.282 28037 28073 I chromium: 			TBODY (editable)
03-30 03:40:50.282 28037 28073 I chromium: 				TR (editable)
03-30 03:40:50.282 28037 28073 I chromium: 					#text "\n      "
03-30 03:40:50.282 28037 28073 I chromium: 					TD (editable)
03-30 03:40:50.282 28037 28073 I chromium: 					#text "\n      "
03-30 03:40:50.282 28037 28073 I chromium: 					TD (editable)
03-30 03:40:50.282 28037 28073 I chromium: 					#text "\n    "
03-30 03:40:50.282 28037 28073 I chromium: 				#text "\n    "
03-30 03:40:50.282 28037 28073 I chromium: *				TR (editable)
03-30 03:40:50.282 28037 28073 I chromium: 					#text "\n      "
03-30 03:40:50.282 28037 28073 I chromium: 					TD (editable)
03-30 03:40:50.282 28037 28073 I chromium: 						#text "next cell won't work"
03-30 03:40:50.282 28037 28073 I chromium: 					#text "\n      "
03-30 03:40:50.282 28037 28073 I chromium: 					TD (editable)
03-30 03:40:50.282 28037 28073 I chromium: 						#text "\u306E"
03-30 03:40:50.282 28037 28073 I chromium: 					#text "\n    "
03-30 03:40:50.282 28037 28073 I chromium: 				#text "\n  "

So it seems the returned selection is from the start of the <td> element containing the newly-inserted character to the end of the newly-inserted character. In InputMethodController::SetComposition(), we try to find the most forward position of the selection base:

  const Position base =
      MostForwardCaretPosition(selection.Base(), kCanSkipOverEditingBoundary);
  Node* base_node = base.AnchorNode();
  if (!base_node || !base_node->IsTextNode())
    return;

MostForwardCaretPosition() is failing to move the selection base into the text node, so we're returning without setting a composition. So it seems we have a bug in MostForwardCaretPosition(). Or do we intentionally handle a selection containing the start of a table cell this way for some reason?

Sounds like a bug of MostForwardCaretPosition.

Let me take a look.

MostForwardCaretPosition returning TR@1 seems intentional. It hits this when traversing to TD@0:

// Do not move to a visually distinct position.
if (EndsOfNodeAreVisuallyDistinctPositions(current_node) &&
    current_node != boundary)
  return last_visible.DeprecatedComputePosition();

Or at least, this part seems too risky to modify...

=======================

From the view of the IME, the root editable is a plaintext editor of content:

\t\nnext cell won't work\t\u306E

Position TR@1 is ambiguous in terms of whether it's before or after the '\t' between the two cells.

So probably we should avoid setting such positions in the ending selection of TypingCommand

The \t's and \n's are not being counted when TypingCommand::InsertText() manipulates the plain text offsets. Maybe we need to use a different TextIteratorBehavior?

>#c8, MostForwardCaretPosition returning TR@1 seems intentional.

I think MostForwardCaretPosition() should not return TR@n because TR accepts only
TD and TH. Thus, it is NOT right position to place caret.

Please make MostForwardCaretPosition() not to return TR@n first.

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

commit 9696438d582824750318748c70a95ef6c1285aca
Author: Ryan Landay <rlanday@chromium.org>
Date: Mon Apr 02 16:35:23 2018

Fix bug entering text into table cell using IME

My CL https://chromium-review.googlesource.com/801979 exposed a bug with
PlainTextRange::CreateRange() when passed a collapsed range at the beginning of
a table cell. TextIterator outputs a tab character ('\t') when iterating over a
table cell boundary; PlainTextRange() is currently counting the tab character
in its character count for this case, but returning a start/end position
(they're the same since it's a collapsed range) before the <td> element, causing
an off-by-one error.

xiaochengh@ found a fix for this issue, so CreateRange() now returns a position
inside the text node, instead of before the <td> element.

Bug:  826615 
Change-Id: Ief427ea6aeb0b93cf82bae3b6901cf1b2a8cb4c7
Reviewed-on: https://chromium-review.googlesource.com/987385
Reviewed-by: Xiaocheng Hu <xiaochengh@chromium.org>
Reviewed-by: Yoshifumi Inoue <yosin@chromium.org>
Commit-Queue: Ryan Landay <rlanday@chromium.org>
Cr-Commit-Position: refs/heads/master@{#547447}
[modify] https://crrev.com/9696438d582824750318748c70a95ef6c1285aca/third_party/WebKit/Source/core/editing/BUILD.gn
[modify] https://crrev.com/9696438d582824750318748c70a95ef6c1285aca/third_party/WebKit/Source/core/editing/PlainTextRange.cpp
[add] https://crrev.com/9696438d582824750318748c70a95ef6c1285aca/third_party/WebKit/Source/core/editing/PlainTextRangeTest.cpp
[modify] https://crrev.com/9696438d582824750318748c70a95ef6c1285aca/third_party/WebKit/Source/core/editing/ime/InputMethodControllerTest.cpp

ouyangguodong@:

This should be fixed in Chrome 67, targeted for release around May 29. The change should be in a Canary build within the next few days. I recommend testing your app with pre-release Chrome builds so we can find out about issues like this before release.

 Issue 829224  has been merged into this issue.

Many thanks! rlanday@.

I have tested it in latest Canary build and it doesn't appear any more. I will make some more smoke tests.

I've a customer with this issue:
case: 15453351
Chrome os:
Chrome stable channel(65)  --  Issue occurs
Chrome beta  channel(66) -- Issue occurs
Chrome dev channel(67) -- issue never occurs.

Windows:
Chrome browser stable(65)  --  Issue occurs
Chrome browser beta(66) -- Issue occurs
Chrome browser Dev(67)  --  Issue never occurs. 
Chrome browser canary(68) -- Issue never occurs.

it's possible to merge this fix to the stable or the beta release?

I don’t think this is safe to merge into stable. The code the fix touches is fairly complicated and there’s some risk that it actually introduces another issue we haven’t found out about yet. It’s also not a new issue as of 66 since it was already in 65. I think this has to wait for 67, which we’re going to start releasing around May 29.

 Issue 829686  has been merged into this issue.