Tested with Chrome stable 53.0.2785.143 on Windows 7 , issue is reproduced.

As Issue is also reproduced in M30 # 30.0.1549.0, hence it is a Non-regression issue and marking it as Untriaged.

Attached screen cast for reference.

Thank you.

Deleted: 653160.mp4 180 KB

	653160.mp4 180 KB View Download

Is there any progress on this? Can we expect a release in 55 as it's labeled.

@Dimitris

Here comes native Korean speaker.
This issue is not fixed. as you can see on the video you uploaded, the cursor location is at the left of the last character. 

This issue is not functional issue. there's absolutely no problem to compose korean owrd. The problem is just that visually the cursor is at the left of last character.

@lima
Yes you are right, have not been solved.  
According to the video, I felt that the problem was the symbols , and not the cursor it self.

The ticket description is clear.
In chrome the cursor remains in front of the last character.

The chrome is doing the job differently with the other browser and applications in windows.
Please check the attached new print screens

Deleted: Chrome_the_problem.png 195 KB

	Chrome_the_problem.png 195 KB View Download

Deleted: Internet_Explorer.png 57.3 KB

	Internet_Explorer.png 57.3 KB View Download

Deleted: Firefox.png 79.3 KB

	Firefox.png 79.3 KB View Download

Deleted: Safari.png 298 KB

	Safari.png 298 KB View Download

Deleted: MS_outlook.png 53.7 KB

	MS_outlook.png 53.7 KB View Download

Deleted: WINDOWS_IN_GENERAL.png 65.3 KB

	WINDOWS_IN_GENERAL.png 65.3 KB View Download

Deleted: NODEPAD++.png 28.8 KB

	NODEPAD++.png 28.8 KB View Download

Deleted: VirtualBox.png 94.8 KB

	VirtualBox.png 94.8 KB View Download

In Chrome for macOS it is also different; 
On MACs the cursor is  "|" but is on right side from the last letter and there is an underscore "_" underneath.

Deleted: from_mac.png 555 KB

	from_mac.png 555 KB View Download

The cursor placement is left of the Korean character only on Windows.

Using Mac or Mobile versions of Chrome, the cursor is to the right of the
Korean character.

I'm working on this. https://codereview.chromium.org/2816683004/

I think it's possible for Chromium to render the composing character like what Internet Explorer and Firefox are doing (Internet_Explorer.png and Firefox.png in the comment 5), but to do so there are three sub tasks.

 Change 1. Specify |gfx::Range(0, length)| to |ui::CompositionText::selection| in IMM32Manager::GetCompositionInfo when |lparam| satisfies |(lparam & CS_INSERTCHAR) && (lparam & CS_NOMOVECARET)|.

https://cs.chromium.org/chromium/src/ui/base/ime/win/imm32_manager.cc?rcl=32280ef94afa5d6d8150c63206a035fe37aafc75&l=308-321
 308:  // Retrieve the selection range information. If CS_NOMOVECARET is specified,
 309:  // that means the cursor should not be moved, then we just place the caret at
 310:  // the beginning of the composition string. Otherwise we should honour the
 311:  // GCS_CURSORPOS value if it's available.
 312:  // TODO(suzhe): due to a bug of webkit, we currently can't use selection range
 313:  // with composition string. See: https://bugs.webkit.org/show_bug.cgi?id=40805
 314:  if (!(lparam & CS_NOMOVECARET) && (lparam & GCS_CURSORPOS)) {
 315:    // IMM32 does not support non-zero-width selection in a composition. So
 316:    // always use the caret position as selection range.
 317:    int cursor = ::ImmGetCompositionString(imm_context, GCS_CURSORPOS, NULL, 0);
 318:    composition->selection = gfx::Range(cursor);
 319:  } else {
 320:    composition->selection = gfx::Range(0);
 321:  }

 Change 2. Remove the work-around that passes |composition.selection.end()| to selection_start parameter in |RenderWidgetHostImpl::ImeSetComposition()|.

https://cs.chromium.org/chromium/src/content/browser/renderer_host/render_widget_host_view_aura.cc?rcl=2040988b1345e6ce738bd03ab7ccd5f4b73a956b&l=1178-1182
1178:  // TODO(suzhe): due to a bug of webkit, we can't use selection range with
1179:  // composition string. See: https://bugs.webkit.org/show_bug.cgi?id=37788
1180:  text_input_manager_->GetActiveWidget()->ImeSetComposition(
1181:      composition.text, underlines, gfx::Range::InvalidRange(),
1182:      composition.selection.end(), composition.selection.end());

 Change 3. Update Blink to render characters within |selection_start| and |selection_end| as if those characters are selected (like Internet_Explorer.png and Firefox.png in the comment 5).

https://cs.chromium.org/chromium/src/content/renderer/render_widget.cc?rcl=1c4d759e44259650dfb2c426a7f997d2d0bc73dc&l=1565-1569

1565: void RenderWidget::OnImeSetComposition(
1566:     const base::string16& text,
1567:     const std::vector<WebCompositionUnderline>& underlines,
1568:     const gfx::Range& replacement_range,
1569:     int selection_start, int selection_end) {

For text fields that are not rendered by Blink, for instance Omnibox (address bar) and search box shown by Ctrl-F, Change 1 should be good enough to address the issue.  I think suzhe@, shuchen@ and/or I (yukawa@) can probably take a look at such a change.

For text fields that are rendered by Blink, at least both Change 2 and Change 3 are required.  For this part, I think Blink editing team should take a look.  Over to yoichio@ regarding this.

I don't assure that IME composition and text selection stay simultaneously in Blink.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

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