Using the per-revision bisect providing the bisect results,
Good build: 59.0.3071.0(Revision:464641).
Bad build: 60.0.3072.0 (Revision:464836).

You are probably looking for a change made after 464697 (known good), but no later than 464698 (first known bad).

CHANGELOG URL:

The script might not always return single CL as suspectas some perf builds might get missing due to failure.

 https://chromium.googlesource.com/chromium/src/+log/188c1056bbfb9c98eca691c12f5641d4204f6066..0f65d25a4097959d977dbb1077717323438240a6

From the CL above, assigning the issue to the concern reviewer as owner is not found in the list

@hugoh - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Review-Url: https://codereview.chromium.org/2616623002

Note : Adding ReleaseBlock-Stable for now , please feel free to edit/remove this.

Thanks!

Clicking next to the <button> sets an invisible caret. But below the <button>, there's no text node to hold a caret so the selection stays inside the <input>.

However, the "hide path" *is* taken ...
UpdateAppearance(LayoutSelection::PaintHint::kHide) 
LayoutSelection::Commit() 
LayoutSelection::ClearSelection()
LayoutSelection::SetSelection() Oops! Leaves the cursor blinking because: // Just return if the selection hasn't changed.

To hide the cursor, we cannot return early here. 

I see another bug; even if we hide the cursor, the <input> still receives keystrokes. It shouldn't because it doesn't have focus. Right, @yosin ?

I think this is the minimal test case:

<!-- This div can take mouse focus but not tab focus! -->
<div style="background: orange; padding: 20%; user-select: none" tabindex="-1">
  <input value="click on orange" autofocus>
</div>

Isn't it weird that a tabindex="-1" disallows tab to focus an area but makes it a focusable area [1] for mouse clicks? :)

If I remove the tabindex attributes from that devtools page, the bug does not reproduce. Why does devtools use tabindex on <div>s anyway? Just to make them focusable? And why make the <div>s focusable? :) Just curious. Anyway, of course we should not break such pages.

[1] https://html.spec.whatwg.org/multipage/interaction.html#data-model

Lower to Pri-3 and remove ReleaseBlock-Stable, because
 - Use still enter text and adding folder
 - The root cause is introduced on July 2016, but no one complain until this issue.


#c2 >I see another bug; even if we hide the cursor, the <input> still receives keystrokes. It shouldn't because it doesn't have focus. Right, @yosin ?
Yes, keystroke should go focused element.

Here is root cause:
 - FrameCaret::shouldBlinkCaret() returns true if 

focusedElement->isShadowIncludingInclusiveAncestorOf(caretPosition().position().anchorNode());

Introduced by patch[1] on July 20, 2016


 - Editor::HandleEditingKeyboardEvent() executes typing command if
focused_element->ContainsIncludingHostElements(
          *frame_->Selection()
               .ComputeVisibleSelectionInDOMTreeDeprecated()
               .Start()
               .ComputeContainerNode()))

Introduced by patch[2] on January 13, 2017

In case of #c3, orange background DIV enclosing INPUT has focus, so we show caret and 
executes typing command. 

When we change INPUT to DIV w/ contenteditable, we can reproduce on M57
<div style="background: orange; padding: 20%; user-select: none" tabindex="-1">
  <div contenteditable>click on orange</div>
</div>

Hence, the patch[3] exposes the root cause for INPUT element and isn't the root cause.

To fix this issue, we should stop traversing ancestor tree after root editable element.

[1] http://crrev.com/2161373002: Make FrameCaret to retrieve caret position from SelectionEditor
[2] http://crrev.com/2628763003: Keyboard event should not insert a character at selection if selection doesn't have focus
[3] http://crrev.com/2616623002: Do not send redundant selectionchange-events 

 Issue 713644  has been merged into this issue.

 Issue 717955  has been merged into this issue.

 Issue 715038  has been merged into this issue.

 Issue 718367  has been merged into this issue.

This seems to be the root cause of many regressions so I'm raising to Pri-1 again.

 Issue 723671  has been merged into this issue.

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

commit f56b768202fbf0ea253e350a43259781e453c48d
Author: yoichio <yoichio@chromium.org>
Date: Fri May 19 10:48:41 2017

Blink caret only if selection has focus.

Use Selection().SelectionHasFocus() in FrameCaret::ShouldBlinkCaret();

BUG= 713051 

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

[modify] https://crrev.com/f56b768202fbf0ea253e350a43259781e453c48d/third_party/WebKit/Source/core/editing/FrameCaret.cpp
[modify] https://crrev.com/f56b768202fbf0ea253e350a43259781e453c48d/third_party/WebKit/Source/core/editing/FrameCaret.h
[modify] https://crrev.com/f56b768202fbf0ea253e350a43259781e453c48d/third_party/WebKit/Source/core/editing/FrameCaretTest.cpp

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

commit 8e46baf867a845e459199e2aefa358ee1e26a559
Author: yoichio <yoichio@chromium.org>
Date: Fri May 19 12:01:58 2017

Accept text input only if selection has focus.

At Editor::HandleEditingKeyboardEvent(), use
FrameSelection::SelectionHasFocus() to check editability.

BUG= 713051 

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

[add] https://crrev.com/8e46baf867a845e459199e2aefa358ee1e26a559/third_party/WebKit/LayoutTests/editing/inserting/insert-on-unfocused-element.html
[modify] https://crrev.com/8e46baf867a845e459199e2aefa358ee1e26a559/third_party/WebKit/Source/core/editing/EditorKeyBindings.cpp

Tested the issue using Chrome Dev# 60.0.3107.4 on Windows, Mac and Linux and found the issue to be Fixed.
Hence adding TE-Verified labels. Adding screen cast for further reference.
Thank You.

Deleted: 713051.ogv 1.3 MB

	713051.ogv 1.3 MB View Download