I could re-produce with M51 stable, so this isn't regression.

Lower to Pri-2, since this bug exists at least May 31, it may from begining, we have 
no report about this.

Remove Release-Block, since this doesn't prevent users to interact with text field.

Simpler steps to re-produce:
(1) Navigate to https://jsfiddle.net/mgfc457f/
(2) Click in text field
(3) Hit End key to locate caret end of text field
(4) Use the right arrow to scroll forward

Actual behavior:
Horizontal scroll to show long line.

Edge and Firefox behave this.

Expected behavior:
Should not scroll

In #c1's step, Shift+ArrowRight doesn't scroll window.

It seems following two statements in FrameSelection::revealSelection() returns different |rect|, but they should be same.
 - rect = LayoutRect(absoluteCaretBounds())
 - rect = LayoutRect(absoluteCaretBoundsOf(createVisiblePosition(extent()))

It does prevent correct interaction with the text field. I can't get the cursor to go to the end of the line to append more email addresses. Raising back to P1 and marking ReleaseBlock-Stable again. We should fix this for M54, even if it regressed in M51 or earlier.

Scroll is caused by scrollViewWithKeyboard() in WebViewImpl::keyEventDefault().
When ArrowRight down at end of text field, FrameSelection::modify("move", "forward", "character") returns false as event not handled, then WebViewImpl::keyEventDefault() does scroll.

In review: http://crrev.com/2200833007

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

commit 8e786c79ce204adb73db01db98f5a606c8365c2a
Author: yosin <yosin@chromium.org>
Date: Fri Aug 05 05:34:03 2016

Change return value of FrameSelection::modify() to prevent unnecessary window scrolling

This patch changes return value of |FrameSelection::modify()| to prevent
unnecessary window scrolling by returning true, indicating user action is
processed. Note: for spacial navigation case, |FrameSelection::modify()| returns
false to allow default key event handler of spacial navigation to move
focus to another element.

Before this patch, hitting right arrow key at end of text field causes
window scrolling by WebViewImpl::keyEventDefault() due by
|FrameSelection::modify()| returns false since selection isn't changed.

BUG= 633376 
TEST=run_webkit_unit_tests --gtest_filter=FrameSelectionTest.ModifyWithUserTriggered

Review-Url: https://codereview.chromium.org/2200833007
Cr-Commit-Position: refs/heads/master@{#409995}

[modify] https://crrev.com/8e786c79ce204adb73db01db98f5a606c8365c2a/third_party/WebKit/Source/core/editing/FrameSelection.cpp
[modify] https://crrev.com/8e786c79ce204adb73db01db98f5a606c8365c2a/third_party/WebKit/Source/core/editing/FrameSelectionTest.cpp

This is still broken in 54.0.2823.0 (Official Build) canary (64-bit).

Revision: c6b7050c321314686730fb679a7122341f16c7c2-refs/heads/master@{#410278}

As an example, go to http://crbug.com/633053 , click the CC: field, and try to use Option + Right arrow (on Mac OS) to scroll to the end of the field. The cursor will start cycling between a few positions but will never reach the right side.

The current behavior is that every time the caret blinks, the cursor jumps to a different position on the line, once scrolled to the right past a certain point.

kbr@, since scrolling bug is fixed, could you file another bug for Move Right by Word bug?

BTW, we, I and two Mac users, could not reproduce Option+Right (Mac), Ctrl+Right (Win/Linux), Move Right by Word, with Canary 54.0.2823.0, in #c10.

I update sample with numbering of words in text field.
https://jsfiddle.net/mgfc457f/1/

If you use this example, and record a word for start of "cycling" and end of "cycling" are helpful.

Thanks!

Filed  Issue 635724  about the continued problems.

Verified the fix on Windows 7, MAC (10.11.6) for Google Chrome Dev Version - 54.0.2824.0 and Ubuntu Trusty (14.04) on Chrome Dev Version - 54.0.2823.0

Screen-recording is attached.

TE-Verified Labels are added.

Deleted: 633376.mov 2.7 MB

633376.mov 2.7 MB Download