For some reason the first auto-repeat keyboard event is being processed. Subsequent auto-repeat keyboard events are ignored.

I verified this by adjusting the auto-repeat delay and observing that this affected when the second zoom adjustment happened.

The bug doesn't repro 100% of the time. I think it happens more reliably if you wait for the zoom amount popup to disappear before trying to reproduce it.

Using the W3C UI Events viewer (https://w3c.github.io/uievents/tools/key-event-viewer.html) I verified that |keydown| events for = have _two_ initial events with no repeat bit set.

Pressing = without the Control modifier, or with Shift (to get +), I see the second and subsequent |keydown| events all have the repeat bit set.

Pressing e.g. X with the Control modifier, I see the second and subsequent |keydown| events all have the repeat bit set.

Pressing Ctrl+0 after having first set a non-default zoom level, the first two 0 events are missing the repeat bit, whereas if zoom was already default then the second 0 keydown will have the repeat bit set correctly.  The difference between these two cases is that when going from non-default to default we get the pop-up shown.

=> This seems to be a bug triggered by the accelerator causing a pop-up to be shown.  Perhaps the second event is being received by the pop-up and routed to the owning window to process?

https://chromium.googlesource.com/chromium/src/+/e22d04949d069f7184b3233d1b83e26fe79e1bcc changed things such that KeyEvent::IsRepeated() now determines whether an event is a repeat from the native event under Windows, and only falls-back to comparing against the previous event (as we do on other platforms) if the event is synthetic.

I suspect that the old behaviour masked the strange Windows' repeat flag setting, so that when the pop-up appears, and we get a not-repeat =, Chrome internally "corrects" that to a repeat before passing it on to the accelerator handler.

Modifying the code path locally to restore the event-comparison code even when a KeyEvent has a native Windows event associated does seem to fix things for me.

Do we know why the native event for these keystrokes has bit 30 (the previous state flag) clear?

Re #4: I'm doing some experiments to diagnose that right now; I expect that the previous-key-state bit is per-thread, and affected by focus changes, so that showing the pop-up confuses things, but we'll see...

Re #4: Going to go ahead and land the patch to restore the old in-process repeat-flag calculation, but will also take a quick look at behaviour in M63 to verify whether this was always the case and just being masked by the repeat logic back then.

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

commit 5307906de5307f9c997a79634f10bd00c203f625
Author: Wez <wez@chromium.org>
Date: Tue Oct 16 20:59:30 2018

[Windows] Make KeyEvent is-repeat flag consistent with other platforms.

In https://chromium-review.googlesource.com/c/chromium/src/+/754130 we
switched to populating the is-repeat flag of ui::KeyEvent solely based
on the flags in the underlying native event, if present.

In the case of a key event triggering a pop-up window to appear, this
caused the first auto-repeat of that event to be dispatched without the
repeat flag set.

To address this we restore the "fallback" path to manually determine
whether an event should be flagged as a repeat, in the case of where a
native event does not itself have the repeat flag set.

Bug:  895266 
Change-Id: Ia224e38768d67bf0dc74d60d7e5ed7b6b6663d80
Reviewed-on: https://chromium-review.googlesource.com/c/1281874
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Commit-Queue: Wez <wez@chromium.org>
Cr-Commit-Position: refs/heads/master@{#600116}
[modify] https://crrev.com/5307906de5307f9c997a79634f10bd00c203f625/ui/events/event.cc

Verified with a local M63 build (63.0.3203.0) that this bug existed even then.

1. Testing with the W3C UI Events viewer, I see two events for the '=' which do NOT have the repeat flag set.
2. Testing with the zoom level on e.g. the New Tab Page, I see it stop at 110%, 125% or 150%.

The broken behaviour in #2 does seem easier to repro in M72 than in M63, but I was still able to get it, occasionally. It seemed easier to repro with particular sites (e.g. the W3C event viewer) than with others (e.g. chrome://version).

With the old logic we would get ui::KeyEvents with the repeat flag set on the second and subsequent '=' event, I believe, but the WebKeyboardEvents re-set their repeat flag based on the underlying Windows-native event, so would still expose the underlying Windows issue as per #1.

So I think this is a long-standing issue rather than an M64 regression.  Will re-test with tomorrow's Canary, which will have the in-process repeat-detection fallback.

Ooops, leaving open to re-evaluate with tomorrow's Canary.

The NextAction date has arrived: 2018-10-17

Update:

Rechecked the above issue on Windows 10 using latest canary version 72.0.3583.0 and the issue is found FIXED.
Hence, adding TE verified labels.

Please refer the attached screen-cast.

Thank You..!!

Deleted: Fixed Video.mp4 586 KB

	Fixed Video.mp4 586 KB View Download