Using the per-revision bisect providing the bisect results,
Good Build: 57.0.2979.0 (revision : 443120)
Bad Build: 57.0.2980.0 (revision : 443474)

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

CHANGELOG URL:

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

 https://chromium.googlesource.com/chromium/src/+log/2dcda31b3f6d9e8cf588f0c233d9c8c7cb9b4521..c5138fa204cedceffaf7a7e777529a9a5d69964c

From the CL above, assigning the issue to the concern owner 

@yosin - 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/2628763003

Thanks!

Adding release block label, please undo if not the case.

Issue is still reproducible on the latest M-57 branched build(57.0.2987.6). Friendly ping to get an update on this.

yosin@ Since this issue is marked as RB-Stable, could you please let us know is there any latest update available for this issue.

Thanks!

A friendly reminder that M57 Stable is launch is coming soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP so it gets enough baking time in Beta (before Stable promotion). Thank you!

Able to reproduce this issue on Windows-7 using chrome latest Dev 58.0.3012.0.

yosin@ We're getting closer to M57 early stable launch and this issue is marked as RB-Stable, so can we get any latest update on this issue? 

Thanks!

My patch doesn't affect focus change. Rather my patch checks focus.

A friendly reminder that M57 Stable is launch is coming VERY soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch (2987) ASAP so it gets enough baking time in Beta (before Stable promotion). Thank you!

URGENT - PTAL ASAP.

We're getting VERY close to M57 Stable promotion. And 
this issue is marked as M57 stable release blocker. Pls make sure to land the fix and get it merged into the release branch ASAP so it gets enough baking time in Beta (before Stable promotion).

Know that this issue shouldn't block the release?  Remove the ReleaseBlock-Stable label or move to M58.

Thank you.

While performing per-revision bisect getting the same suspect as mentioned in the comment #1.

rkote@ Could you please check the same and provide chromium bisect from your end?

Thanks!

This is not the internal PDF viewer, it's an extension which displays PDFs as HTML5. Removing the Internals>Plugins>PDF label.

The assigned owner "rkote@etouch.net" is not able to receive e-mails, please re-triage.

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

rdevlin.cronin@, could you ptal please? 

The bisect from #1 is correct; I've confirmed that reverting it locally changes the behavior.  This also makes sense with the cl description, "Keyboard event should not insert a character at selection if selection doesn't have focus".  We would previously insert characters into the text field even if the field didn't have focus, and yosin@'s patch changed that behavior.

It may be that the new behavior is desired; I'll leave that up to others to decide.

Yes, this is expected behavior both logical, compatible to other browsers and W3C UI Event spec[1].


[1] https://www.w3.org/TR/uievents/