1.背景：
使用QT+CEF做了一个客户端，并在客户端中注册了全局键盘钩子，本来一切都工作正常，键盘钩子也正常，但是我发现当我在cef中加载了执行WebRTC功能的页面时，
键盘钩子尽然失效了，不过切换到其他的桌面程序的时候，发现这个键盘钩子还是存在的，起作用的。
2.分析
通过上面的现象开始排查，WebRTC主要是用到摄像头和麦克风功能；通过单独的测试，如果只打开摄像头的话，键盘钩子依旧有效，那问题的根源就在于当网页中使用了麦克风时，会导致键盘钩子失效。
首先想到的是到CEF Forum上查找，起初不知道该怎么描述这种现象，不确定是否有其他人遇到这种应用场景很小的问题，不过通过仔细查找，最终也是找到了一个帖子，所描述的现象与现在存在的问题一致。
通过查看帖子，发现原来是Chromium内核中使用的某个特性：在使用Audio的使用，为了对键盘敲击所产生的噪音进行处理，WebRTC模块也注册了自己的全局键盘钩子，导致当CEF加载一个具有使用Audio的页面时，会导致本来存在的键盘钩子失效。（具体原因就是Windows规定，注册的低级别键盘钩子只针对Application级别，如果一个Application的不同Window注册低级别键盘钩子，后注册的会起作用，二先注册的会失效，也就是只有后注册的才能接受消息）。
对Chromium源码分析：
追踪到关键类型：UserInputMonitor类，这个类决定是否对用户键盘输入Monitor，目前Chromium也没有提供单独的控制参数来关闭这个Monitor，所以暂时无解。
3.解决办法
既然不能同时在一个Application中拥有两个一样的键盘钩子，所以只能将自己的键盘钩子放到其他的程序里，作为一个辅助程序来调用。然后通过进程间通讯来实现其他业务逻辑。
4.链接
forum讨论：https://bitbucket.org/chromiumembedded/cef/issues/2609/chomium-windows-when-using-own-low-level
源码：https://source.chromium.org/chromium/chromium/src/+/master:media/base/user_input_monitor_win.cc;l=95;bpv=1;bpt=1