Josh Triplett Reporter
	Description • 9 years ago

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.

	Mike Taylor [:miketaylr]
	Comment 1 • 8 years ago

Can somebody reproduce this since https://bugzilla.mozilla.org/show_bug.cgi?id=1203059 landed?

	Andrew Overholt [:overholt]
	Comment 2 • 8 years ago

Can you still reproduce, Josh?

	Josh Triplett Reporter
	Comment 3 • 8 years ago

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.

	Andrew Overholt [:overholt]
	Comment 4 • 8 years ago

(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)?

	Josh Triplett Reporter
	Comment 5 • 8 years ago

Yes, I can reproduce this with Firefox 48.

	Andrew Overholt [:overholt]
	Comment 6 • 8 years ago

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).

	Josh Triplett Reporter
	Comment 7 • 8 years ago

@overhold: That video got blocked.  I'd suggest selecting something that won't, such as https://www.youtube.com/watch?v=aqz-KE-bpKQ .

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)
	Comment 8 • 8 years ago

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.

	Josh Triplett Reporter
	Comment 9 • 8 years ago

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.