janked page janks browser keyboard shortcuts |
|||||
Issue description1. go to http://plexode.com/eval3/#s=aekVQXANQSUsDGwMRAw0DS1WTA2ABjFAJCgFcPU8BAWFUVUJTVQEeASVCVUYPT1BYohymqFhJSk1GAQmztbe5ogEOAautrx0BEhHUEaNcXqbZT6agopePS5KUll4A 2. click "eval js now" button 3. hit cmd+l to focus the address bar. It waits till the script is done. Some key handlers we don't allow the page to override, so we can do them even if the page is janked. But other key handlers, we do allow the page to override, so a janked page makes for a bad experience. For the ones where we do, we should keep track in the browser process if the focus is somewhere the page might preventDefault on a key handler. If it's not, then we don't need to round-trip through the renderer at all. Eventually, you could imaging shipping passive keyboard event listeners the same way we do for touch so that pages only affect the browser shortcuts when they need to.
,
Dec 14 2016
Able to reproduce the issue on windows-7, Mac-10.11.6 and Linux Ubuntu-14.04 using chrome stable version 55.0.2883.87 and latest canary 57.0.2951.0 with the steps mentioned above. This is non-regression issue observed from M-30 # 30.0.1551.0. Hence marking it as Untriaged to get more inputs from dev team. Thanks..
,
Dec 15 2016
We likely could ack browser shortcuts early instead of waiting for the main thread to ack them.. although I don't know why the browser isn't going ahead and executing the action because it is predetermined if the event is a browser shortcut. See https://cs.chromium.org/chromium/src/third_party/WebKit/public/platform/WebInputEvent.h?type=cs&sq=package:chromium&rcl=1481775657&l=318
,
Dec 20 2016
The only ones we can ack early are the ones that can't be overridden by the page. That's a short list and is not all browser shortcuts. On the following page, try cmd+l (prevented) and cmd+w (not prevented). http://plexode.com/eval3/#s=aekVQXANLVQMbA28PQkVFJldGT1UtSlRVnEZTCQhMRlqMWE8IDQFgCUYKAVw9TwEBRFBPVFBNRg9NUEimqKpQrAgKHLe5wVFTRpudJUZHQlZNVQnMt17MA14A Certainly for the preventable ones, we can avoid even going to the renderer (I think we do today already?). For the non-preventable ones, if we made the compositor thread knew that focus was in a non-key-handling location, then it could ack on that thread instead of going through the main thread.
,
Jan 6 2017
,
Jan 7
cc still doesn't know about the focused element. But it will soon for related changes such as keyboard threaded scrolling. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by ajha@chromium.org
, Dec 12 2016