Joanmarie Diggs Reporter
	Description • 9 years ago

Steps to reproduce:
1. Load http://oaa-accessibility.org/examplep/tabpanel1/
2. Give focus to one of the radio buttons on the "crust" page
3. Press Ctrl + Page Down to show the next tab (see "keyboard support" section)

Expected results: The next page would be shown.

Actual results: Works as expected if e10s is not enabled. Fails if e10s is enabled.

This issue is present with 44.0a1 (2015-10-09). Not sure when it was introduced.

	Bill McCloskey [inactive unless it's an emergency] (:billm)
	Comment 1 • 9 years ago

Neil, how bad do you think this is and how hard would it be to fix?

	Neil Deakin
	Comment 2 • 9 years ago

I think bug 1074971 made the next tab and previous tab shortcuts reserved so that content couldn't override them. It should be implemented this way in non-e10s as well; there's probably a bug on this somewhere.

The steps above intentionally don't work in Chrome either.

Let's ask Felipe for more details.

	:Felipe Gomes (needinfo for replies!)
	Comment 3 • 9 years ago

Ok, so after some code archaeology I found out what's happening. Bug 1074971 indeed meant for this shortcut to be blocked from pages, but it actually had no effect because the commands Browser:PrevTab and Browser:NextTab from browser-sets.inc are not used.

The code that actually handles Ctrl+Tab/PgUp/PgDown is here: http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/tabbox.xml?rev=d6793bb3e45b#161
And by it calling .preventDefault() it prevents the event from being sent to the child (in e10s only), and has the same effect as reserved="true"

So, about this bug, although it was implemented "accidentally", restricting the main browser shortcut keys has been a long requested feature that is now supported in e10s. So this new behavior is desired. It's only a small set of keys that can't be used, listed in bug 1074971 comment 11.