Can't reproduce in Windows 7 x64 and Canary 69.0.3496.0 x64.

ABBYY Lingvo works with Ctrl-C-C and Alt + mouse cursor.
https://www.abbyy.com/en-eu/translation_dictionary/features/

Punto Switcher works with RCtrl hotkey.
https://yandex.ru/soft/punto/

Do the hotkeys work for you when the Canary window is active?

Still can reproduce with all extensions toggled off and all chrome://flags/ reset to default.

Thanks for filing the issue!

Tried checking the issue on reported chrome version 69.0.3496.0 using Windows 7 with the below mentioned steps.
1. Launched Chrome
2. Installed the "ABBYY" application from the URL provided in comment#1
3. Tried using the application installed.

Our observations:
-----------------
When trying to use the application we found "ABBYY Compare documents", "ABBYY Fine Reader OCR Editor", "ABBYY Hot Folder" and "ABBYY screenshot Reader". On opening the mentioned installations we were able to compare documents but couldn't able to check for translations/keyboard shortcuts.

@Reporter: As we are not very sure about the process further to be followed, i.e.,Working of Global keyboard shortcuts, Could you please help us in triaging the issue further. Any further inputs from your end may be helpful.

As I cannot see ABBYY Lingvo (http://www.lingvo.ru/) in the free trial downloads, can you test the second, much simpler application:

https://yandex.ru/soft/punto/

I can toggle the keyboard layout with the Left Ctrl in the last Dev build (69.0.3493.3), but cannot do this in the last canaries. The concerning settings are in the screenshot attached.

Deleted: ps.png 31.9 KB

	ps.png 31.9 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

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

It seems the free trial download of ABBYY Lingvo can be obtained here: http://www.lingvo.ru/download/

The concerning settings are in the screenshot attached.

Deleted: Lv.png 38.8 KB

	Lv.png 38.8 KB View Download

Tried checking the issue as per comment#6 by navigating to the URL provided and installed ""Punto Switcher"", but the screenshot provided is in Non-English hence couldn't proceed further as we are not very clear about the settings to be changed. As an alternate checked with the URL provided in comment#8 to download/install ""Lingvo"", but it says Server error. Attaching the screen shot of the same for reference. 

@Reporter: Could you please let us know the changes to be made in settings for 'Punto switcher', that helps us to triage the issue further in a better way.

Thanks!

Deleted: 865439 server error.PNG 55.6 KB

	865439 server error.PNG 55.6 KB View Download

1. http://www.lingvo.ru/download/ seems to be temporarily down, maybe will be up soon.

2. As for the Punto switcher settings, I've marked the significant options by the red rectangle. These are English translations:

Toggle layout by: Left Ctrl
English/Russian layout only (this is optional, may be checked out to toggle any layouts that are already active in the OS).

Thank you for providing more feedback. Adding the requester to the cc list.

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

Sorry, the last Punto switcher version seems to fix the issue (the changelog states fixing some compatibility issues with some applications).

ABBYY Lingvo still remains unresponsible to global shortcuts.

As per comment#12, latest Punto switcher version has fixed the issue and as per comment#10 currently ABBYY Lingvo isn't available to download/install. Hence removing Needs-Bisect label.

Thanks!

http://www.lingvo.ru/download/ is up again)

I've uninstalled and reinstalled Canary and the issue has gone. Maybe something had broken in my Canary files.

As per comment#15, after fresh installation of Chrome the issue seems to be resolved, Could you please let us know if we can close this issue.

Thanks! 

Unfortunately, the issue is back after a day of using and reinstalling does not help anymore.

Interesting info: after the previous reinstall, I've got 32-bit dcheck version, it worked. After an auto-update, the normal 64-bit Canary also worked. But in some next update, the issue is back.

Thank you for providing more feedback. Adding the requester to the cc list.

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

70.0.3532.0 seems fixed. I hope this fix is not flaky)

In 70.0.3538.3 the issue is back(

Since you're the only one who can reproduce the issue currently, consider performing a bisect:
https://www.chromium.org/developers/bisect-builds-py

Bisect result:

You are probably looking for a change made after 587803 (known good), but no later than 587811 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/19c79f6f5541fbe1f2abe13b943cb3c9c3239067..79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6

Just a shot in the dark: it seems this commit is close to the fix in 70.0.3532.0:

https://chromium-review.googlesource.com/c/chromium/src/+/1187861

and this revert is close to the issue return:

https://chromium-review.googlesource.com/c/chromium/src/+/1196840

That commit and its revert are for ChromeOS.
I don't see any obvious culprits in the found range.
Make sure the range is stable by repeating the process at least once.

Strange. Bisecting proves good all the last revisions. And when I download the build from the https://download-chromium.appspot.com/ it is also good. But when I run my "C:\Users\[user]\AppData\Local\Google\Chrome SxS\Application\chrome.exe" with temp data dir (clean profile), the issue appears. Can it be something outside of profile that hurt installed Canary?

I've uninstalled and reinstalled the Canary and the issue is gone. But it seems I've done it before and it returned back somehow: https://bugs.chromium.org/p/chromium/issues/detail?id=865439#c15

Something constantly happens with the installed app during updates(

The version did not change after the reinstalling but the issue returned.

>I've uninstalled and reinstalled the Canary and the issue is gone. 
>The version did not change after the reinstalling but the issue returned.

This implies some the cause is a Field Trial, which are enabled at random for random people.
It might be helpful if you post the value of "Variations" from chrome://version.
And compare that to the value in a clean non-buggy installation.

Thank you. My action:

1. Copy Variations in the current buggy 71.0.3542.0 ("Buggy 1").
2. Uninstall and reinstall the same 71.0.3542.0, make sure there is no issue, copy Variations ("Fresh").
3. Relaunch freshly installed 71.0.3542.0, make sure the issue is back, copy Variations  ("Buggy 2").
4. Compare 3 Variations, indent only those that match in "Buggy 1" and "Buggy 2". There is the result in the file attached.

Sorry, one variation was wrongly indented int he previous file. This file is fixed.

Deleted: variations.txt 5.5 KB

variations.txt 5.5 KB View Download

Is there a way to map variations to meaningful field trial names and to toggle them one by one to find the culprit?

The only way I know is to set a breakpoint in GetFieldTrialActiveGroupIdsForActiveGroups function and inspect the variable using Visual Studio to debug Chrome. This is relatively involved, but doable. 

* install Visual Studio (a 2017 Community version is probably ok)
* add chromium debugging symbol URL in the VS options as described somewhere in chromium docs
* in VS menu - debug - attach, choose the main browser process,
  you can find its PID in Chrome's own task manager (Shift-Esc)
* wait for the symbols to download
* in VS click the pause button
* in VS drag'n'drop or open a locally stored active_field_trials.cc downloaded from here:
  https://cs.chromium.org/codesearch/f/chromium/src/components/variations/active_field_trials.cc
* in VS set a breakpoint inside that function (the breakpoint's icon should become red)
* in VS click the unpause/run button
* in Chrome open/reload chrome://version

The breakpoint should activate in VS and you'll see the local variables in e.g. Autos panel.

Deleted: Clip545-fs8.png 69.5 KB

	Clip545-fs8.png 69.5 KB View Download

Thank you. Maybe I will dare to try.

But it is not very user-friendly way) Why use field trials if a trial subject cannot easily detect a buggy trial, test its impact, report it more exactly and toggle it out if it is not fixed in the foreseeable future?

Elaboration concerning "Components: UI>Input>KeyboardShortcuts" — this is not only a keyboard issue. There is an option to use pure mouse wheel click for the same dictionary action, and this option also does not work. It seems any user input transferring is blocked, not dispatched to the system/other application hooks.

Well, I am stuck)

I've done all the steps from https://bugs.chromium.org/p/chromium/issues/detail?id=865439#c32 (on "in VS click the pause button" VS required various source files so I've also got all the Chrome source). Then I copied all the trial names from the variable (see attached file), group them by 4-5 trials and call Chrome with this flag (no others I can find by googling):

chrome.exe --force-fieldtrials="Name 1/Disabled/Name 2/Disabled/.../"

All the instances still had the bug.


Please, tell me, if I should do something else.

Deleted: variations.txt 6.4 KB

variations.txt 6.4 KB View Download

Maybe some of the variations don't have a "Disabled" state.
You can try comparing the list to a fresh non-buggy profile like you did before but this time with the actual names.

I've compared variations names/values in a freshly installed Canary (still without the bug) and in the same Canary just after one restart (still with the bug at once) — see the summary in the attached file.

Then firstly I launched chrome.exe with --force-fieldtrials="name/value from the fresh installation" one by one, and then with all the initial name/values in one option. Each time I checked the hex representations in chrome://version to be sure the values are actual.

Unfortunately, in all instances, the bug remained.

Deleted: var-hex-2-names.txt 6.6 KB

var-hex-2-names.txt 6.6 KB View Download

BTW, it seems there is a function in active_field_trials.cc that converts variation names/values into hex strings: AppendActiveGroupIdsAsStrings(). Or maybe the call to base::StringPrintf() is the most interesting here. Sorry, I do not know C++, but maybe the conversion algorithm can be implemented in JavaScript so that users can convert hex representation in the chrome://version into names/values to test them with --force-fieldtrials?

1. Some variations may require using --disable-features= or --enable-features= or two restarts with the same command line.
2. AppendActiveGroupIdsAsStrings simply formats those hexadecimal hashes.

1. Is there a way to detect the wanted values of --disable-features= or --enable-features= for a variation?
2. Yes, it seems there is suffix adding and SHA-1 hashing in the chain. Maybe somebody can implement the decoding in JavaScript some time.

I will try two restarts with the same command line.

Thank you for your time.

>detect the wanted values of --disable-features= or --enable-features= for a variation

* search for the variation name on https://cs.chromium.org/
* in most cases you'll see a json file with the feature names inside the variation's block
  for example: https://cs.chromium.org/chromium/src/testing/variations/fieldtrial_testing_config.json

>decoding in JavaScript some time

Hashes cannot be decoded by definition of a hash. Such script would have to index the entire source code of chromium to find all names of variations and their potential values and calculate the hashes using the same simple algorithm, then correlate the results with the provided list. I guess chromium team has some internal utility that uses such a map.

I've tested with restarting and --disable-features=/--enable-features= and no luck.

BTW, if I launch some --force-fieldtrials with --disable-features=/--enable-features=, I cannot find their hashes in the Variations anymore. For example, these commands:

chrome.exe --enable-features=BlinkSchedulerHighPriorityInputOnCompositorThread --force-fieldtrials="BlinkSchedulerHighPriorityInputOnCompositorThread/Enabled"

chrome.exe --enable-features=PrioritizedSimpleCacheTasks --force-fieldtrials="PrioritizedSimpleCacheTasks/Enabled"

No ecpexted 61832c80-3f4a17df and 7a5ba892-3f4a17df, even no names 61832c80 or 7a5ba892.

Thank you a lot for the help anyway. I've learned many useful things)

Another observation: if I launch the Canary with --reset-variation-state and then restart some times with this flag, the issue can disappear. But then it can return if I close the Canary and open it without the flag.

In a similar issue 882833 they say starting chrome with "--force-renderer-accessibility" fixes the bug.

Thank you! Unfortunately, I cannot test this solution as the issue has gone once and for all since I did some launches with --reset-variation-state flag.

vsemozhetbyt@ Thanks for the update.

As per comment #45, can you please confirm if this issue can be closed?

Thanks..

For me, it has gone, so this can be closed if nobody else is affected.

Thank you for providing more feedback. Adding the requester to the cc list.

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

From comment#47 closing this issue and marking it as Won't Fix.

Thanks!