Issue metadata
Sign in to add a comment
|
Keyboard shortcuts also captured by HTML5 content
Reported by
jivan....@gmail.com,
Jan 9
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36 Steps to reproduce the problem: To provide some examples where YouTube is the culprit: 1. Play a HTML5 YouTube video. 2. Press CMD+L to put focus on the omnibox. 3. Observe that focus is put on the omnibox (as expected), but that the YouTube video also captures the "L" keystroke and thus advances the video by 10 seconds. Another example: 1. Open a second tab, and play a HTML5 YouTube video in that tab. 2 Press CMD+1 to switch to the first tab. 3. Observe that we switch to the first tab (as expected), but that the YouTube video also captures the "1" keystroke, and thus seeks to 10% of the way through the video. (This example is reproducible with all of CMD+1..9.) 1. Play a HTML5 YouTube video that has closed captions. 2. Attempt to copy some text to the clipboard from that page in which the video is playing using CMD+C. 3. Observe that the text is copied to the clipboard (as expected), but that the YouTube video also captures the "C" keystroke, and thus toggles the video's captions. These examples are only reproducible when the HTML5 content would normally be able to capture keystrokes, i.e. for a YouTube video, when that webpage has focus (as opposed to when another Chrome UI element such as the omnibox has focus). What is the expected behavior? See examples above. What went wrong? The HTML5 content captures keystrokes that are solely intended for Chrome itself. Did this work before? Yes Unknown; working at least as recently as Chrome 69. Chrome version: 71.0.3578.98 Channel: stable OS Version: OS X 10.14.2 Flash Version:
,
Jan 9
Thanks for filing the issue: @Reporter: Could you please provide sample Test File/URL that reproduces the issue which help in further triaging the issue in better way. Thanks!
,
Jan 9
Chrome is working correctly here. Chrome allows sites to redefine almost all hotkeys, otherwise online advanced editors wouldn't be possible. The only protected shortcuts are Ctrl-N, Ctrl-T, Ctrl-W (also with Shift), Ctrl-Tab, Shift-Esc and their analogs on MacOS. And of course those that the OS intercepts itself also can't be redefined by js. Related: bug 33056 , bug 119881. The sites you've reported should fix their bugs. For some reason js developers forget to check the modifier keys. P.S. Quoting https://crbug.com/25756#c128 : Most keyboard shortcuts are sent the the web page for first dibs. If the page doesn't handle it, the browser checks for an accelerator and does the action. We have a few keyboard shortcuts that aren't sent to the page (this includes non-windows NPAPI plugins and pepper plugins) to ensure that it's at least possible to exit the page with the keyboard if it's misbehaving, but I don't remember these offhand. [...] Some users think that the list of stuff we send to the page is too large when there is a poorly-designed page or plugin. Some web developers think the list is too small because they're writing games or IDEs or whatever and want to make it behave the same across platforms. No choice will make everybody happy, and I think we're unlikely to make big changes in this area after having the same behavior for so long.
,
Jan 10
I can confirm this bug with Chrome 71.0.3578.98, I can't reproduce this issue with Safari 12.0.2. Tested it with this URL https://www.youtube.com/watch?v=ublchJYzhao But I can't reproduce it on Chrome 71.0.3578.98 with Vimeo: https://vimeo.com/237860783
,
Jan 10
P.S. to my comment. While Cmd+[number] and Cmd+L don't work, Cmd+t works. Very confusing.
,
Jan 10
I think c#3 explains that. I would suggest filing feedback with YouTube, since this is WAI on the browser side. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by susan.boorgula@chromium.org
, Jan 9