Open Bug 1201744 Opened 7 years ago Updated 5 years ago
Dn keyboard shortcut intercepted by site handler for Pg Dn (affects You Tube)
Starting recently, in YouTube, I found that when pressing Ctrl-PgUp or Ctrl-PgDn to switch tabs, Youtube interprets the PgUp or PgDn and seeks in the video. It should not be possible for a site to intercept Ctrl-PgUp and Ctrl-PgDn, and *especially* not when it's looking for PgUp or PgDn. Note that YouTube's keyboard shortcuts depend on what has the focus. To reliably reproduce this, you'll need to first use the mouse to seek in the video by clicking on the seek bar. Then try PgUp or PgDn to confirm that they seek by one minute. Then try Ctrl-PgUp or Ctrl-PgDn to switch tabs, and notice that the YouTube video seeks by one minute. That shouldn't happen.
Can somebody reproduce this since https://bugzilla.mozilla.org/show_bug.cgi?id=1203059 landed?
Can you still reproduce, Josh?
Yes, I can still reproduce this with Firefox 45.3.0, on multiple YouTube videos. Note that to reproduce, you may need to first manually seek in the video by clicking on the seek bar. After doing so, hitting Ctrl-PgUp to change tabs also seeks the video by 1 minute, in addition to changing tabs.
(In reply to Josh Triplett from comment #3) > Yes, I can still reproduce this with Firefox 45.3.0, on multiple YouTube > videos. Thanks for confirming. Can you try in 48 or later (https://beta.mozilla.org/ would work)?
Yes, I can reproduce this with Firefox 48.
Thanks, Josh. I too can reproduce with non-e10s in 48 but if I force e10s on (https://wiki.mozilla.org/Electrolysis#Force_Enable) I cannot reproduce. I'm using https://www.youtube.com/watch?v=WxHr_a0s8EI as a test video, obviously. Masayuki, is it expected that bug 1203059 is only fixed in e10s (that bug seems to indicate that but I'm not 100% clear on that).
@overhold: That video got blocked. I'd suggest selecting something that won't, such as https://www.youtube.com/watch?v=aqz-KE-bpKQ .
Ctrl+PageDown/PageUp are handled by normal event handler in chrome: https://dxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/tabbox.xml#161-162,168-169,227 So, they are not "reserved" by chrome (currently, UI developers need to use XUL <key> element for reserving specific key combination). I.e., these key combinations should be handlable by web contents. The reason why the keys are consumed by chrome only in e10s is, all keyboard events listeners in chrome are run before dispatching them into content process. So, yes, the e10s mode's behavior is unexpected. That will be fixed by bug 1257617.
Seems like there are two separate issues here. First, a keyboard handler looking for PgUp or PgDn shouldn't intercept a keystroke of Ctrl-PgUp or Ctrl-PgDn. That might be a site-specific issue; worth checking the handler code to make sure. Second, sites shouldn't be able to intercept chrome navigation keys at all, such as Ctrl-L, Ctrl-K, Ctrl-R, Ctrl-F, Ctrl-PgUp, Ctrl-PgDn, and similar. I've seen similar issues on other sites, such as intercepting Ctrl-F for the site's own "find" function (breaking Firefox's find-in-page), intercepting Ctrl-R and preventing refresh, etc.
You need to log in before you can comment on or make changes to this bug.