Closed Bug 380637 Opened 17 years ago Closed 7 years ago

Should web pages be restricted from being able to override the browser's keyboard shortcuts?

Categories

(Core :: DOM: UI Events & Focus Handling, enhancement)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla58
Tracking Flags:
Tracking Status
blocking2.0 --- -
blocking1.9.1 --- -
firefox58 --- fixed

People

(Reporter: billhigg, Assigned: enndeakin)

References

(Depends on 2 open bugs, Blocks 2 open bugs,
URL
)

Details

(Keywords: access, ux-mode-error, ux-trust, Whiteboard: [games:p3][parity-chrome])

Attachments

(6 files, 13 obsolete files)

pageinfo-dialog.png
(deleted), image/png
phlsa
: ui-review+
Details
Part 4.2 - menu accesskeys should check for shortcut override permissions
(deleted), patch
masayuki
: review-
Details | Diff | Splinter Review
Part 1.4 - add preference to prevent pages from overriding keyboard shortcuts
(deleted), patch
Details | Diff | Splinter Review
Part 2.4 - add site permission to block override keyboard shortcuts
(deleted), patch
Felipe
: review+
Details | Diff | Splinter Review
Part 3.2 - move reserved check into ContentUtils
(deleted), text/plain
Details
Part 4.3 - menu accesskeys should check for shortcut override permissions
(deleted), patch
masayuki
: review+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: 1.8.1.1) Gecko/20061204 Firefox 2.0.0.1

I have a DOM/ECMAScript application where I want to submit a form when the user presses the Ctrl-S keyboard shortcut.  However this is challenging since Firefox has already claimed 'Ctrl-S' for its "Save Page As" function.  I found a hacky way to override Ctrl-S but it requires that Firefox be focused within an input text box or textarea (see this thread for more details: http://groups.google.com/group/mozilla.dev.tech.javascript/browse_thread/thread/347b7c622079932c ).  I've observed that Gmail has a similar problem binding Ctrl-S to its 'Send Email' function.

This bug is to address allowing DOM/ECMAScript developers to bind to Ctrl-S and effectively override Firefox's Ctrl-S binding in all circumstances (i.e. whether focus is in an input box or not).

I realize this opens up other usability issues (e.g. surprising users who expect Ctrl-S to result in the 'Save Page As' dialog) but I think it's at least worth some discussion and consideration.

I also realize that my Ctrl-S issue is just an instance of a more general issue - namely that there's a potential for conflict whenever a DOM/ECMAScript application wishes to use a keyboard shortcut that the browser's already reserved.  But I thought I'd focus on the concrete problem instance rather than prematurely generalizing the issue :-)

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Attached file not so hacky (obsolete) (deleted) — 
Why not do it this way?
But yes, there is always the usability issue whether browser's 
keyboard shortcuts should be used or webapp's ones?
There's no bug here, the separation of chrome/content including having
separate keyboard commands is by design.  An arbitrary web page should
NOT have the power to override well-known application commands.
Commands that often also are desktop-wide and therefore deeply etched
into the user's mind to mean ONE thing only.

It's bad UI design to have CTRL+S mean "submit" on some pages and
"Save Page As" on other pages, it's confusing to users.

Also, I wouldn't rely on hacks like the one Smaug provided.
I consider that a bug to be honest. It shouldn't be allowed.
Severity: normal → enhancement
Whiteboard: [wontfix?]
> There's no bug here, the separation of chrome/content including having
> separate keyboard commands is by design.  An arbitrary web page should
> NOT have the power to override well-known application commands.

Ok, point taken.  Question: how do you define the set of 'well-known application commands'?  Any application command for which Firefox provides a keyboard shortcut?  Any Ctrl-* command?  Some other heuristic?
(In reply to comment #3)
> Also, I wouldn't rely on hacks like the one Smaug provided.
> I consider that a bug to be honest. It shouldn't be allowed.
> 

That is not a hack, but maybe we should change that functionality.
Though, if we have always supported that, I'm pretty sure
changing that would break sites. Depends also what IE does.
Tested using Konqueror and Opera, and Konqueror didn't do anything and Opera opened the save-as dialog.


(In reply to comment #5)
> That is not a hack, but maybe we should change that functionality.

+1 for not letting web content take over browser shortcuts.

This is currently possible for both <accel> and <chromeAccess> (i.e. Ctrl and Alt) key combos. I've seen a few sites taking over Alt key combos through JavaScript since we've changed the content accesskey modifier to Alt+Shift.

> Depends also what IE does.

IE7 either opens the "Save As..." dialog or simply swallows the event if Save As... isn't available. IE however lets through events for Ctrl key combos which aren't defined anywhere.

Suggestions (in order of potentially breaking stuff):
1. Make accel/access key events non-cancelable for web content.
2. Only pass those events to web content when they weren't handled by chrome.
3. Never pass those events to web content (so that content authors don't lose time fiddling around with which combos might possibly be available).

Unfortunately, such a change would effectively leave content authors once more with only <contentAccess> (i.e. Alt+Shift) as only possible accelerator...
Attached patch make app handlers have "higher priority" (obsolete) (deleted) — — Splinter Review 
if we want to change how app's keybindings are handled, something like
this is needed; moving key event handlers from bubble phase of the
system event group to capture phase of the default group.
Attachment #264764 - Attachment is obsolete: true
But are there cases when inside browser the default handling should be
prevented?
Or maybe the right solution is to fix bug 329119
My point in comment #4 is that currently it's not clear to me which keyboard
shortcuts I may override and which I may not.  It's fine to say that I
shouldn't override Ctrl-S, but as long as it's possible programmatically,
someone's going to do it (because they didn't happen to read this thread).

So I'd say publish a clear policy on which keyboard shortcuts page apps may and
may not use, and then absolutely prevent page apps from using browser-reserved
keyboard shortcuts, perhaps even triggering an exception if the page app tries
to connect to the reserved keyboard shortcut.
(In reply to comment #11)
> So I'd say publish a clear policy on which keyboard shortcuts page 
> apps may and may not use, and then absolutely prevent page apps from 
> using browser-reserved keyboard shortcuts, 

But how could this be done. Extensions can always add some new
keyboard shortcuts, like DOMi adds Ctrl+Shift+i

> perhaps even triggering an exception if the page app tries
> to connect to the reserved keyboard shortcut.

No exceptions, they can easily break web apps.
Attached patch v2 (obsolete) (deleted) — — Splinter Review 
This is something we might want to use. If there is an event listener
for some keybinding, it doesn't get dispatched to the content because 
stop propagation is called on default event group when event is still
being processed in chrome. stopProgation is per event group, so
system event group handling works normally.
Attachment #264765 - Attachment is obsolete: true
(In reply to comment #12)
> (In reply to comment #11)
> > So I'd say publish a clear policy on which keyboard shortcuts page 
> > apps may and may not use, and then absolutely prevent page apps from 
> > using browser-reserved keyboard shortcuts, 
> 
> But how could this be done. Extensions can always add some new
> keyboard shortcuts, like DOMi adds Ctrl+Shift+i

This is actually making my point; I'm not sure it's feasible to say "Page apps
can't override browser-owned keyboard shortcuts" because this would require
Firefox to explicitly reserve a set of keyboard shortcuts, which is very hard
to do if your goal is to be an extensible platform.

This is why it's my (humble) opinion that Firefox should explicitly allow page
apps to override normal browser keyboard shortcuts and it's up to the page app
designer to shoulder the burden of usability.  As page apps get more and more
sophisticated it seems both shortsighted and infeasible to make a blanket
statement that "Page apps may not override browser-reserved keyboard shortcuts
but we can't provide an exact list of which keyboard shortcuts a page app may
not override because we may decide to reserve a new one in the future and any
particular extension may also reserve a new keyboard shortcut".
(In reply to comment #14)
> This is why it's my (humble) opinion that Firefox should explicitly 
> allow page apps to override normal browser keyboard shortcuts and 
> it's up to the page app designer to shoulder the burden of 
> usability. 

I don't have a strong opinion here. I just made those patches while 
reading the code to understand what could be done *if* we decide to
prevent web apps to override browser's key bindings.
This is IMO more a usability issue than a technical issue.
It is the usability of web apps vs. usability of the browser.

(In reply to comment #15)
> It is the usability of web apps vs. usability of the browser.

Are you worried that a page app will override a keyboard shortcut and people will think Firefox has a bug because it doesn't perform the typical Firefox action?
(In reply to comment #14)
> Firefox should explicitly allow page apps to override normal
> browser keyboard shortcuts

We've just recently changed away from this attitude WRT accesskeys - and IMO for good reason: people should be able to rely on the shortcuts they're used to, no matter what content they're viewing (the contrary might be considered bad usability on behalf of the browser).

I'd rather make it easier for JavaScript to react to <contentAccess> key events (i.e. independently of the actual modifier combo, since that might vary) and think about a better default for <contentAccess> than is Alt+Shift.
Blocks: 147447
OS: Windows XP → All
Hardware: PC → All
Summary: problems connecting events to the Ctrl-S keyboard shortcut → Should web pages be able to override the browser's keyboard shortcuts?
Whiteboard: [wontfix?]
(In reply to comment #6)
> Suggestions (in order of potentially breaking stuff):
> 1. Make accel/access key events non-cancelable for web content.

Not very useful for anyone IMO.

> 2. Only pass those events to web content when they weren't handled by chrome.

Blurs the distinction between content/chrome.
Also, a content author probably wants to know a priori which
key combos are taken (which is impossible because of add-ons).

> 3. Never pass those events to web content

Yes. I consider it a bug that we do.
(In reply to comment #16)
> Are you worried that a page app will override a keyboard shortcut

Yes, there are malicious sites out there that are taking advantage of
inexperienced web users (phishing)...  Having a clear distinction
between application UI and web page content is important.
(In reply to comment #17)
> I'd rather make it easier for JavaScript to react to <contentAccess>

I agree with that, how about an onaccesskey attribute?

> think about a better default for <contentAccess> than is Alt+Shift.

A lot of thought has already gone into finding a key combo that doesn't
clash with chrome or the window manager.  I honestly don't think
there is a better one.
Comment on attachment 264778 [details] [diff] [review]
v2

What if the page has its own <key>s? Which wins then?
Depends on: 382011
Blocks: eviltraps
Assignee: events → nobody
QA Contact: ian → events
Version: unspecified → Trunk
Another wide-spread example of such a behavior is Google Spreadsheet. It overlays a couple of our browser shortcuts so something like bookmarking the page (Ctrl/Cmd+D) and reloading the page (Ctrl/Cmd+R) is not possible.
Status: NEW → ASSIGNED
blocking2.0: beta1+ → beta2+
Firefox should reserve shortcuts for closing tabs, switching tabs, and opening menus.  Sites that break these are either buggy (e.g. Twitter) or malicious.

But we should probably let web apps preventDefault most other shortcuts.  A word processor needs to override Cmd+{BIUS} to keep users from going insane.
So we need some API which exposes all the reserved keyboard shortcuts to
web apps.
I don't think it's crucial for web apps to know which keyboard shortcuts they can't override.
(In reply to comment #37)
> I don't think it's crucial for web apps to know which keyboard shortcuts
> they can't override.

How about plug-in-based web apps? (Relevant to the morass of discussion over on bug 78414, which has been going nowhere fast ever since I cc'd myself to it.)

If not, any solution acceptable in this context seems as though it ought to be acceptable in that context, too.

cl
Chromium reserves "tab and window management commands". Interestingly, they chose to do this not primarily because of malicious and buggy sites, but because of responsiveness concerns with slow or hung renderers.

https://code.google.com/p/chromium/issues/detail?id=5496
https://code.google.com/p/chromium/issues/detail?id=33056
I believe the current thinking is that we'll let web apps override any shortcut — since they have more of an "installation" flow, and if they're going to replace desktop apps — they have to be capable of this.

As for shortcuts for any web page, I think the approach where we reserve the shortcuts that we can't allow them to break (New tab/window, focus URL bar, etc), and let them override the others.

Faaborg probably has more input on this, since he's working on our web app strategy these days.
What is the difference between "web apps" and "web pages"?
>What is the difference between "web apps" and "web pages"?

they are both built using the same set of universal web technologies, but web apps are granted some additional privileges by default, things like access to the full set of keyboard shortcuts, or the ability to go full screen without prompting the user.  We can afford to give them these privileges by default because the assumption is that they are running from a trusted context (either created by the user, or brought in through some sort of store).

For the purpose of this bug, the answer is yes, web pages should be able to override all keyboard shortcuts, but only if we detect that they are in an app tab, or running as a separate app in the OS (similar to http://prism.mozillalabs.com/, see bug 605222).
(In reply to comment #43)
> For the purpose of this bug, the answer is yes, web pages should be able to
> override all keyboard shortcuts, but only if we detect that they are in an
> app tab, or running as a separate app in the OS (similar to
> http://prism.mozillalabs.com/, see bug 605222).
Why is App Tab any special? User doesn't give any special permission to the
web page when (s)he clicks "Pin as App Tab.".
>Why is App Tab any special? User doesn't give any special permission to the
>web page when (s)he clicks "Pin as App Tab.".

We may decide to show a tab modal permissions dialog when the user creates an app tab, if the application has a manifest file asking for specific permissions.  That's all whiteboard level ideas at this point though.
My vote would be for another checkbox added to the "Advanced Javascript Settings" dialog (which currently allows the user to prevent sites from moving/resizing popup windows, raise or lower windows, or disable/replace context menus) to allow the user to choose between application accessibility and site functionality.

That way, I wouldn't have to swear at Google Docs every time I tried to reload, open the bookmarks sidebar, open a new tab, etc. This morning I was on some video game review site that actually overrode Ctrl-PageUp and Ctrl-PageDown (and probably all other keys), which was the last straw.

Since this has been open for five years and I don't understand the Firefox code well enough to write a patch, I'm going to try a blunt-instrument approach using Greasemonkey as well.
Blocks: 777081
No longer blocks: 777081
Depending on how it's implemented, fixing this could also fix bug 78414.
Blocks: PluginShortcuts
Blocks: 825425
Keywords: ux-mode-error, ux-trust
Vlad, wondering if you have opinions on this bug from the games perspective...
Mmm.  Yes, from a games perspective, web pages really should be able to override any/all browser shortcuts, with some definite exceptions (escape), and maybe some others (control-w).

In fullscreen mode, the page should be able to override everything except for escape.  Same thing in pointer lock mode (which will be available separately from fullscreen soon; currently you can only lock in fullscreen).  For regular pages though, I would like to see everything overrideable, but perhaps with a pref for people who find that annoying.  (We already have the Advanced JavaScript prefs window ;)

I think *not* allowing web pages to override browser shortcuts entirely is doomed though; the browser just uses too many.  So it's a question of figuring out where to draw the line.
The line is really that the browser UI becomes unusable if you can't trust any keyboard shortcut to work. Take, for example, StackExchange.com: try writing an answer and either hitting control+L to get to the URL bar or control+K to get to the search bar. You can't.

This gets worse when using the expected UI keystrokes inside an interactive Javascript web page can lead to data loss because instead of the UI command, the page catches that keystroke and uses some other command the user may as well as not know about. For example, Outlook Web Access, the webmail interface for Microsoft Exchange: http://help.outlook.com/en-ca/140/bb899480.aspx#inbox — if the focus is on the page, Control+Q won't trigger anything other than "mark message as read" (I'd say this classifies as data loss if you had an old message selected in a big inbox and you had it marked as unread for the explicit purpose of keeping track of it)

There is also Control+R, which is supposed to reload the current page. Or reply to the message, if you're in MS OWA and you happen to have the focus on a message, of course.

Designing an "interactive web app mode" where there is a single, unoverridable shortcut that gets the user out of that mode would perhaps be the best way to implement web application shortcuts without rendering Firefox's UI unusable with keyboards; In any other way, I think we can say Firefox's UI does not offer keyboard interaction. Comment 17 sums it pretty much: if the shortcuts are there, they should work.

Also, consider the security implications, we had the file picker text box locked because scripts could be able to change its content: and now, with this, a page is effectively allowed to steal keyboard input and do something instead of the browser, I wonder if there isn't some room for an attack where a combination triggers some dialog or reaction similar to what the Firefox UI would do, then enticing the user to enter personal data, as he trusts the shortcut and everything looks normal in the interface they are seeing.
(In reply to Nuno Silva from comment #66)

> Also, consider the security implications, we had the file picker text box
> locked because scripts could be able to change its content: and now, with
> this, a page is effectively allowed to steal keyboard input and do something
> instead of the browser, I wonder if there isn't some room for an attack
> where a combination triggers some dialog or reaction similar to what the
> Firefox UI would do, then enticing the user to enter personal data, as he
> trusts the shortcut and everything looks normal in the interface they are
> seeing.

You are right. Imagine that a wicked site overrides Ctrl T. I am on such a site, and I press Ctrl T, expecting to see my defined home page. But the wicked site shows me something that looks like my home page. I think I am in my trusted home page... Imagine that my home page is my inbox or my bank's site... Let the wicked site enjoy !
After reading through the entire thread, I think there is a consideration missing.

The application (JavaScript) could simply be allowed to request advanced permissions from the browser for such things as keyboard shortcut overrides. If the user has never allowed that specific site to access those things, the user could simply be prompted with a notification bar or similar system asking them to confirm that they would like to allow this site to access these advanced systems much in the way that they can allow or deny a popup either for the current session or forever.

A simple listing dialog like the saved password management screen would likely suffice as a management interface for the sites with enhanced access permissions.

A window level property or method could be used to detect the status of this access and an event could be triggered if the user changes that status after the page is loaded (i.e. when the user clicks allow or deny)

This puts the control back into the hands of the user without completely robbing applications of the ability to add useful enhancements to their advanced web applications.

The line between desktop app and browser app is quickly becoming blurred further and further and we need to continually re-evaluate our take on topics as the world's view and understanding of the technology at hand changes.
Blocks: 748198
Expanding my response from #69:

After some discussion around the office this morning we have also come up with the following:

- GPS (Location) Services on mobile devices use a prompt system like this to get permission before apps can access any location data.

- It is possible (probable?) that power users are the ones using/needing shortcuts and other users do not even use browser shortcuts. If this is the case then power users can be expected to understand what it means to allow the web application to handle keyboard shortcuts.

- Webkit (Google Chrome & Safari) already allows the JavaScript to override some browser level shortcuts, though (unfortunately) this does not include some like metaKey + S.
Also, the Mac version of Firefox allows JavaScript to override some browser level shortcuts. (Cmd + B for example)
My personal power-user and minimal UI development experience tells me that @{Micheal White} is right. For me, it all boils down to usage flexibility and intuitiveness. 

Most probably lambda-users will never bother (or even now) about shortcuts configuration. Nevertheless, the dreadful "mad monkey syndrome", where inadvertent keystrokes play havoc with some important Web applications (risk of data loss!), should be taken into account.

That said, here is my sketch of solution:

1. catch by default all keyboard input, irrespective of where it's generated (plugin, addon, JS, etc.);

2. if a shortcut conflicts with browser's native ones, raise an alert, prompting users for 
switching to shortcut hijacking mode wherein the browser gives up (some of) its native shortcuts. This implies that a super-escape shortcut be available and immutable, with proper API advertisement. The prompt window should sport the customary remember-my-choice check-box for session vs permanent effect, and might also allow to open an advanced config window showing all application shortcuts susceptible of overriding, formatted as a check-box list; 

3. whenever a user accepts or declines the shortcut hijacking, AND remember-my-choice is checked, the browser records this in appropriate domain-based 'about:data' records and doesn't ask any more for the same domain;

4. any emergency exit, via super-escape, from a shortcut-hijacked session should prompt the user for restoring the hijacked shortcuts. Here again, a remember-my-choice check-box would discriminate between temporary or permanent action;

5. optionally, whenever a permanently overridden shortcut is acted upon, a minimally invasive visual clue should appear, f.i. as a small flashing icon/text in the status bar. 

IMHO, that would allow users (even lambda ones!) to learn progressively about apps/plugins/addons's shortcuts. Moreover, having the browser always in control of keyboard input would improve security, though there'll be inevitably some performance loss...
(In reply to sphakka from comment #72)
> 2. if a shortcut conflicts with browser's native ones, raise an alert,
> prompting users for 
> switching to shortcut hijacking mode

Do we have stats on how many websites try to register conflicting shortcuts? It might surprise/annoy users if browsing to web pages that previously appeared to work now have multiple prompts. Especially if the conflict involves obscure shortcuts you never use.

> Moreover, having the browser always
> in control of keyboard input would improve security, though there'll be
> inevitably some performance loss...

Probably fine, since most keystroke-latency-sensitive apps (i.e. games) use single-key shortcuts, and hence their shortcuts would not conflict with the browser (so complicated logic for whether to pass the shortcut can be skipped).
(In reply to replicator.snail from comment #73)
> (In reply to sphakka from comment #72)
> > 2. if a shortcut conflicts with browser's native ones, raise an alert,
> > prompting users for 
> > switching to shortcut hijacking mode
> 
> Do we have stats on how many websites try to register conflicting shortcuts?
> It might surprise/annoy users if browsing to web pages that previously
> appeared to work now have multiple prompts. Especially if the conflict
> involves obscure shortcuts you never use.

Please note that there are also platform-dependent keystrokes and UI-dependent keystrokes, for example, see Pentadactyl.

It might surprise/annoy some users, but it also annoys some users if they cannot use a page because there are shortcut conflicts.
I have read through above and am still not clear if there is a patch proposed which enables customization of overrides per particular url or simply disabling all sites to never override. Can someone link me to this code if it is already in process? Thx.
Problems with some of the above suggestions:
• Websites override platform keystrokes, not just browser keystrokes, so checking for conflicts with browser reserved keystrokes is inadaquate.
• Websites override non-US keyboard layout keystrokes which is more-or-less the same problem as above (many non-US keyboards use ALT and CTRL combos for non-English characters and diacritics).

Allowing sites to override keystrokes (particularly the above) opens users to data loss (something I have experienced multiple times), as well as phishing (the problems I get reports of are users thinking they have a virus/malware on their system trying to phish for bank logins, and it turns out to be sites hooking system and browser keystrokes).

The best proposal I have seen above is adding a check box next to the javascript options in Settings for allowing/preventing sites from hooking a keystroke. Personally, I think this should be prevented by default with a per-site white-list option, and an option by websites to request (from the user's opt-in by confirmation box) being white-listed.

This is both a security and a usability issue.
Blocks: gecko-games
Whiteboard: [games:p?] → [games:p2]
It's been seven years and 17 duplicate bug reports; perhaps it's time for a decision.

I don't think we can disable all JavaScript overrides via an option, it would be obscure and cause support issues.

And what we currently do, allowing all overrides, breaks the Law of Least Astonishment.

Does it seem reasonable if we agree on a small set of core functions that can't be overridden, and allow all others? Unusually, Chromium seems to get this right; it doesn't let Ctrl+W get blocked, for example. I would suggest Ctrl+Tab, Ctrl+±, Ctrl+R, Ctrl+S, and Ctrl+W as a minimum. Thoughts?
(In reply to Paul from comment #82)
> I don't think we can disable all JavaScript overrides via an option, it

I actually like the idea of an all-or-nothing master switch, provided that any single shortcut (or binding) can be reconfigured: it would be good for the masses, and power-users could instead go to "about:config" and tweak whatever they like. I think that a master switch would be *safer* than having only some immutable binding [*]. However, I'd personally accept

> would be obscure and cause support issues.

Why? It's just a matter of proper placement under "Preferences > Privacy & Security" From a plugin developer's perspective a master switch would be perhaps make it easier to handle and document to the end user how to unlock custom shortcuts. Conversely, forbidding some of them tout court might preclude interesting possibilities in Web apps. From a lambda user perspective, it wouldn't change much as they mostly use the mouse pointer; also, a complementary mechanism like that I proposed in Comment #72 might help users getting a grip on it.

However, if something must be really made untouchable, I strongly suggest that it be an *escape* sequence to give back keyboard control to the browser (Ctrl+ESC, or ESC+ESC, f.i.), a kind of panic button ;-)

On a more general line, expanding on Comment #72, I see here an architectural challenge surfacing more and more as the complexity of interactions between a Web app/plugin/add-on and their hosting browser increases. The issue seems to me a matter of control hierarchy and delegation: even if the browser (the master) might choose to delegate some functions to an app (the helper), it doesn't imply that an helper is free to override any master's prerogatives *without* its consent. That is, in a "well educated" system, helper components should ask permission to operate in master mode: this should happen at helper installation or at first landing on a (supposedly respectful [!]) Web page, with f.i. a pop-up providing the list of shortcuts susceptible of being overridden plus the customary "Remember my choice" tick box; the choice would be accessible via 'about:data'.

[*] IMHO, bindings, per se, are *not* core functions; "core" is the mechanism that handles them. So an hard-coded binding is... well, a bug.
[!] A page that check what it's allowed to do and advertises what it'd like to do.
The page should/must not be able to detect user's detailed settings, compare bug 572650.
(In reply to [:Aleksej] from comment #85)
> The page should/must not be able to detect user's detailed settings, compare
> bug 572650.

I guess you're referring to my definition of "respectful" page. That's reasonable -- indeed, I wasn't sure of the first claim in the definition. So it should only "advertise what it'd like to do".
(In reply to sphakka from comment #83)
> I actually like the idea of an all-or-nothing master switch

How about this as a solution: we copy Chromium's implementation as the default (reserve a (language-specific) set of keystrokes), and give users a switch that enables JavaScript to trap all keystrokes.

This won't step on many web developers' toes, because Google has already beaten them into submission for us; and we'll still enable power users who have a need for it (e.g. for web-based terminal emulators) to cede control to JavaScript.
(In reply to Paul from comment #82)
> 
> I don't think we can disable all JavaScript overrides via an option, it
> would be obscure and cause support issues.

What is obscure about it?

> And what we currently do, allowing all overrides, breaks the Law of Least
> Astonishment.
> 
> Does it seem reasonable if we agree on a small set of core functions that
> can't be overridden, and allow all others? Unusually, Chromium seems to get
> this right; it doesn't let Ctrl+W get blocked, for example. I would suggest
> Ctrl+Tab, Ctrl+±, Ctrl+R, Ctrl+S, and Ctrl+W as a minimum. Thoughts?

Restricts the list of shortcuts to the official firefox UI, and risks not being consistent even across the firefox UI shortcuts.

I'd say it'd not make the situation any better. Right now, the situation is already a game of chance, and a list of preserved key combinations does not solve that *and* introduces another similar game, this time "is this combination protected or not?".
(In reply to Paul from comment #87)
> the list of reserved sequences should be different with other OS languages.

That's actually more than I thought about.

I'm using either a Russian locale (it has default English bindings) or a colemak layout. The last one is a layout, not a locale(language), so it has default English key bindings, too.

So the question is still open for people using German/Spanish/.. languages.
If we only blacklist a small number of combinations, what is the use of letting pages assign actions to key combinations, as there is no way for the page to be consistent across locales and firefox interfaces? (The page would have to either find a combination that works for any imaginable layout, or come up with alternate combinations on the fly, or it would simply not work.)

If there is some dual-mode design (kind of like pentadactyl's pass-through mode or vi's insert mode), this would allow firefox to keep all the browser combinations safe while still allowing users to interact with the page directly (just not at the same time).

If you're afraid this may look too complicated, perhaps label it "Web application mode", and make that an umbrella for some things that suit more web applications than web pages. And maybe add a button for it somewhere in the UI.

But please don't reject ideas to solve this on the grounds that "settings are too complicated".
Controversial though it may be, it is Mozilla policy to reduce rarely-used settings, like when the options to prevent GIF animations or to disable JavaScript were removed from the settings dialog.

Although reserved keyboard shortcuts would not be consistent across locales, they *would* be largely consistent across browsers: ours and Google's. It's OK to adopt the sensible decisions of the market leader, just as they did many times when we were king. We can still one-up them by providing an about:config setting to permit JavaScript to override all (or no) keyboard shortcuts.
I really hate web sites taking over common shortcuts (such as ^N in email to create a new message when I really wanted a new window or ^C "copying" in a web app instead of to the OS).

A couple of suggestions:
1. Have duplicate events. ^N would normally be a new window but could have an event tied to it but [CTRL]-[SHIFT]-N would ALWAYS be new window, etc. 
2. Only allow keyboard event triggers on shifted characters, so binding an event on ^N would require a SHIFT before it'd work. This could be some other modifier, too.
3. Have a way to unload bound events easily, like a bookmarklet.
I use EMACS key-bindings in gtk (Firefox on Ubuntu 14.04), and web sites sometimes can overwrite it. It's been suggested the order is  priorities: System > Website > Firefox, IMHO gtk shortcut keys (e.g. move to the end with Ctrl+E) is a system level event, how could it be overwritten in Websites?
There seems to be another another, yet simple solution, which has already been proven in other fields: What if we just define exactly ONE hotkey to switch the focus between browser window and website. Think of it in that way, how the windows key works. To make things visually clear the browser component and the website should alternately get highlighted, so the user has more than a selected address bar as focus indicator. 
As hotkey I would suggest something in combination with CTRL, because the accesskey attribute in the html5 standard just interfaces with ALT/Apple-keys. [^`] (CTRL+[the key above TAB]) would look intuitive to me.
It seems that the opinion of the silent majority is that while sites that redefine standard keys is frowned upon, Firefox cannot break these sites.  I generally agree with this view, but think that users   should be allowed to "opt-out".

There are several standard ways to surface an opt-out on the UI -- a mode switcher hot-key, an IE-style information bar, a keyboard icon which appears to the left of the "favorites" star in the location box.  Any one of these solutions works.

Opting-out would no-op redefinitions of standard hotkeys; the related JavaScript functions would succeed without errors, but not set the hotkeys.

Yes, opting-out may break websites, but that's a decision for a user to make -- just like denying Flash permission to run.

Also: we celebrated the 6th birthday of this issue last month.
I would like to add my two cents here. I just came from a discourse forum site that hijacks your Command+F shortcut to search the site rather than allowing the browser to search the page. From my a site is allowed to intercept ANY keyboard shortcut. I just created a web page intercepts any Cmd+KEY short cut, including New Tab, New Window, Change Tab, Close Tab, Switch to URL bar, Find, Bookmark, etc. This is foolish to allow this, without any prior notification, or approval from the user.


1. Fresh idea for this discussion: This seems like the kind of issue that would have detrimental effects for accessibility. If someone were blind or seeing impaired, and was dependent on the keyboard and some type of voice over system, they could very easily become unable to use their computer anymore if the webpage over rides their browser's shortcuts, even if intended to be helpful, and especially if intended to be malicious (over-riding close window).  


2. Novel attack idea: User performs New Tab + Paste + Enter, while looking at the keyboard. Site captures New Tab, shows New Tab Page, and puts cursor into a text box. When the enter button is pressed, user is sent to destination through a proxy/sent to phishing site and the user might never think to check the URL.  Any page could have replaced these commands with their own malicious, sneaky ones.


3. Rehashing old ideas: Web page designers may think they can override shortcuts to help people. However, the outcome of hijacking Cmd+F is that users looking to search the page are unable to do so and become annoyed, and every one else is neither affected nor benefited, since they would never discover the feature. Allowing such a short cut to be hijacked is only bad for users.

I would be in favor of some type of "App Mode" where the site can take over a user's keyboard similar to how a site can access full screen now. But until then, a swift action should be taken on shortcuts that could easily be hijacked to steal data/deceive users precisely because on their own familiarity and trust in Firefox shortcuts.
Does anyone know if there is a workaround for this issue, such as a third-party extension, to prevent websites overriding keyboard shortcut controls? I am noticing that more and more websites are taking advantage of this "feature" to remove my control over the browser.
Addons can always listener events in capture phase, in which case they get the event before
web page has accessed it.
Blocks: 933470
(In reply to Bastiaan Jacques from comment #110)
> Does anyone know if there is a workaround for this issue, such as a
> third-party extension, to prevent websites overriding keyboard shortcut
> controls?

https://addons.mozilla.org/en-US/firefox/addon/free-control/ is an add-on that prevents pages from intercepting the tab-switching Ctrl-PgUp and Ctrl-PgDn shortcuts (via bug 949020).   If someone wants to make an add-on that works around this bug more generally, that might be a good starting point.
Whiteboard: [games:p2] → [games:p2][parity
Keywords: access
Whiteboard: [games:p2][parity → [games:p2][parity-chrome]
Depends on: 1052569
Twitter accidentally broke loads of keyboard shortcuts today. (bug 1052538) Fortunately, they're aware and should have a fix out by tomorrow. This should not have been possible, however. Can work on a patch to prevent this please be renewed? Overriding Ctrl+S might be debatable, but blocking most shortcuts without even overriding them to something else is not acceptable and needs to be not allowed on our end.

For large-scale keyboard rebindings that are needed, e.g. games or full-featured office applications, simply prompting in a doorhanger seems reasonable. (so long as there's an easy shortcut to exit, of course) Most sites should have no reasonable need for this, though.
Wow! That's a privacy breach. For instance, if I type Ctrl-S, I certainly don't want the web site to know (at least by default) that I save the page. And if some well-known extension defines a particular shortcut, I don't want the web site to know that I'm using this extension.

The user should give explicit permissions for specific web pages that need to get any key event (BTW, this corresponds what Michael said in Comment #69), possibly with a user-defined list of key events that must not be passed.

Depending on what is done, this could also solve the related bug #276295 on type-ahead find (a.k.a. find as you type).
I like the idea that my feature suggestion from #69 should be disabled by default so that it is targeted more toward power users.

I also like the take on use of a sub-container. I'm not sure how well non-power users would take to it but it seems to have good potential. If implemented well so that it really felt like a separate desktop application had opened up I think non-power users may actually like it quite well. This one could go pretty far if allowed - ability to define OS/Window level menu bar items, large dock / start bar icon, custom loading screen, etc.

@Klint - I appreciate the obvious thought and effort you spent researching this issue and I hope others will also.

@Mozilla - This is an issue that needs active attention from you as an organization. We (the development and user communities) need and deserve your feedback on what you like and don't like about the mass off suggestions and ideas that have been laid on the table for the past SEVEN YEARS. Please do not continue to ignore this issue and instead help to forge the way and lead the browser market forward into the next phase of web application and internet use!
This is really an issue which needs to be fixed on a spec level
(since this should be sorted out in all the browsers).
Well, at least in case something like comment 69 should be implemented.
So, please bring this up either in WhatWG or W3C (Webapps WG).
All excellent points, and thanks for the replies.  Michael, I'm just a user with minimal coding experience in the distant past; I'd be grateful if you could take this (particularly the subcontainer idea) forward to WhatWG or W3C (Webapps WG) as Olli suggests.  Definitely a longer-term thing and not a quick fix, but I think it's well worth considering for its potential benefits.  (Including some sandboxing benefits for the sake of security, if I'm not mistaken.)

Thanks,
Klint
Hi Klint,

I'm not sure what steps submitting to WhatWG to W3C would take but I will look around and see what I can dig up.

@Community / @Mozilla - if anyone reading this thread has already submitted to one or both of those organizations please join in and assist with this process. I have extremely limited time for this sort of thing but I will do what I can.

@Mozilla - it seems like this sort of submission would be exactly the type of thing Mozilla would assist with to get things going. Any help you can provide on writing this up and submitting it will be greatly appreciated.
Feel free to send the proposal to me before sending it to whatwg - if you want some feedback.
(the mailing list, whatwg@whatwg.org,  for the specifications can be found in http://www.whatwg.org/mailing-list )
Ollie, how does one get this recategorized from "enhancement" to something that might have a better chance of getting looked at before another 7 years pass?
The state of that 'importance' field doesn't matter here at all.
We can improve some stuff within browser (like making sure certain shortcuts can't be overriden),
but those cases need separate bugs and need to be handled case by case I think

For a better solution we need a spec, and that needs to be done either in WhatWG or in W3C, not
in this bug. And once there is a reasonable stable spec draft, that can be implemented.
Why does there need to be a W3C spec to do this? Comment 69 seems to suggest an approach that's entirely over-engineered. What's the point in an API that lets the site request to override Ctrl+W?

Let the site steal everything, like it can today. I press Ctrl+W. Firefox notices that 500ms later, the tab remains open, suggesting that the site didn't bubble Ctrl+W through. Firefox pops up a doorhanger telling me that the site stole Ctrl+W, with an option to always process this shortcut without sending it to the site.

Obviously the specific UI for this needs to be designed carefully, and this is no easy task, but in my mind, requiring a WhatWG/W3C spec is the wrong way to go about this: it's not up to the site whether to cooperate, so no API and no spec are needed. The site does not need to even know that I've configured my browser not to send Ctrl+W to it.

Same goes for a number of other important browser shortcuts.
(In reply to Roman from comment #129)
> Let the site steal everything, like it can today. I press Ctrl+W. Firefox
> notices that 500ms later, the tab remains open, suggesting that the site
> didn't bubble Ctrl+W through. Firefox pops up a doorhanger telling me that
> the site stole Ctrl+W, with an option to always process this shortcut
> without sending it to the site.

I don't want to do that for every site and every shortcut. There should be an option to make Firefox catch these shortcuts for every site, with a whitelist of specific sites that are allowed to get them.
> Let the site steal everything, like it can today. I press Ctrl+W. Firefox notices that 500ms later,
> the tab remains open, suggesting that the site didn't bubble Ctrl+W through. Firefox pops up a
> doorhanger telling me that the site stole Ctrl+W, with an option to always process this shortcut
> without sending it to the site.

That would be annoying for a lot of shortcuts.  What if a site steals the arrow keys?  Then if I try to scroll, I'd have to confirm a dialog box for every single press, unless there's a “Don't ask again” option.  And would this option apply globally, to the site, or to that specific keypress?  And then there'd have to be a UI to manage previous selections, yes?  That doesn't sound much simpler than Comment #69's approach.  And I've seen all too well the Firefox devs' hate of having what they consider extraneous GUI knobs.

Also, if you always allow Firefox and the site to simultaneously act on a keypress, it wouldn't necessarily help.  If I press / for find-as-you-type, and a site decided to make / completely change the content of the page or load a new page, that would still render the find-as-you-type key useless.

Personally, I could live with a single checkbox (or even just a hidden pref) for globally forbidding sites to register keys used by the browser.  If someone needed finer-grained control, perhaps an add-on could be written.  Or, someone mentioned a sort of focus-changing or “escape” key, which with care could be implemented in a non-intrusive way that requires little to no UI configuration, I would think.
This all needs a spec - it doesn't necessarily need to be an "API", but some spec, how this all
should work, so that web app authors can write code which works in all the browsers.
If one browser blocks certain shortcut keys in some case, and other browser other shortcut keys, 
web pages are forced to have UA specific code paths. That is not how the web should work.

One option for the API would be something like
partial interface KeyboardEvent {
  bool isUAShortcutKey();
}
(In reply to Roman from comment #129)
> Why does there need to be a W3C spec to do this? Comment 69 seems to suggest
> an approach that's entirely over-engineered. What's the point in an API that
> lets the site request to override Ctrl+W?


Comment 69 was not calling for a W3C spec. It was throwing out an idea to be molded by Mozilla and the community into something that would work for developers, average users and advanced users and everyone else besides. Tackling something this fundamental is not something to be thrown together overnight by one person.


> Let the site steal everything, like it can today.

It cannot steal everything which is why this thread exists in the first place. Different browsers allow different sets of shortcuts to be captured by not everything is available. This is exactly the type of fragmentation that allowed IE to take its browser in the wrong direction for so many years.


> Obviously the specific UI for this needs to be designed carefully, and this
> is no easy task, but in my mind, requiring a WhatWG/W3C spec is the wrong
> way to go about this: it's not up to the site whether to cooperate, so no
> API and no spec are needed.


In theory it doesn't have to be a W3C or WhatWG spec. However, as you can see Mozilla has not taken action on this for 7 years which means they really do not have any interest in being the Microsoft on this issue. They are almost certainly waiting for an accepted specification before they invest the development hours and resources that it will take to implement something. This benefits them by saving redevelopment time if a spec. were to later come out and force them to change to match that specification. It also benefits users because I know that significant change in UI can be disorienting to users and cause friction. Mozilla does not want to lose user base just because the UI and/or behavior of the keyboard shortcut overrides changing made users frustrated or confused. Lastly Mozilla does not want that API or behavior to change later because developers will get frustrated at them like they do with IE because it will work differently in different browsers or because they have to support the legacy way for X years before they can drop support.


> The site does not need to even know that I've
> configured my browser not to send Ctrl+W to it.

The site absolute needs to know. A web applications designer can actually tweak the UI/UX based specifically on whether or not the site is allowed to use those shortcuts or not. There will be many benefits to specifically exposing that information to the site so that designers/developers can have their applications react to that and provide the best user interface accordingly. The specific benefits depend on the application and how the designer/developer chooses to help the user in that scenario but one example might be that the interface shows little keyboard shortcut hints to the user if they have chosen to allow this behavior but hides them if they chose not to allow the site to override those keyboard shortcuts. This sounds minor but if you show the hints to everyone and then they don't work for a user who forgot what option they chose, then that user will get frustrated and send in a bug report about the site closing when they hit ctrl + w.

---

In summary, there are several good options thrown out there and we need to get this out to a wider audience before a decision is made. You nailed it when you said "Obviously the specific UI for this needs to be designed carefully, and this is no easy task,...".
> There's zero reason to let the site know whether or not its requests for
> keybinding were allowed by the user.

I don't understand why you are so adamant that the site cannot or should not know a boolean value saying "your app (does/doesn't) have keyboard shortcut control". Please provide some additional information to back up your opinion. I'm certainly open to seeing things differently but I need a good reason to change my mind.

That simple boolean flag allows the developer to adjust application behavior and UI to the situation. For very advanced applications that require that kind of interaction (games, etc.) I can see the developer wanting to show an alert to the user explaining that the application will have reduced functionality or may function incorrectly due to their decision to disallow keyboard shortcut overrides. This helps usability by making sure the user is aware that a decision they made may be affecting their own experience and that same alert could provide a link to steps to change that setting.

In my opinion not providing this one data point eliminates the ability to enhance the user experience around keyboard shortcuts in simple ways and sometimes its the little things that are important.
(In reply to Michael White from comment #135)
> (In reply to Roman from comment #129)
> > The site does not need to even know that I've
> > configured my browser not to send Ctrl+W to it.
> 
> The site absolute needs to know. [...]

I don't think that's possible: What if the site uses a shortcut not used by Firefox, but caught by the user's window manager? If the site cannot know that, you haven't solved the problem.

IMHO, this bug should just be fixed without a spec. A spec could come later, but needs cooperation of the window manager / the OS.
I think there may be a misunderstanding of exactly what I believe the site should know about. I do not think the site needs to be alerted every time something above it traps a keyboard shortcut (OS/browser, etc.).

I do think that when the page loads, the site can request access to extended keyboard shortcut functionality and then the browser just replies with a boolean result indicating whether the user has granted permission or not. The first time the user visits a site asking for that control the site would prompt the user for an answer but after that it would not bug them again. (There could also be a global setting to turn on / off for all sites - much like browsers asking to remember passwords)

On future visits the browser would just reply with the stored response from the user.

Most sites would probably not leverage this functionality but advanced sites, web applications, web based games, etc. could all take advantage of it.

If this feels over-engineered to anyone please make a new suggestion that simplifies it but does not take control away from the end-user.

I do feel this solution *could* be implemented without a spec. but I also believe that Mozilla has reasons for waiting for a wider community acceptance of such a solution before implementing. I also believe that those reasons for waiting will probably result in less chaos for web developers for years to come and I am definitely on board for that.
Flags: sec-review?
Flags: a11y-review+
I would expect the system to behave as follows: web pages can listen to any shortcuts but if those are consumed by the browser or the operating system itself they'll just never see those, similarly to how I can configure a system-level hotkey that masks one of the browser shortcuts and the browser never sees the keypress. In Firefox I would assume that the chrome will first see all keypresses and if one isn't bound to anything, only then it gets dispatched forward to the content. But I might be wrong here.

In the meanwhile, could we at least have some global or per-site preference for this in about:config? It is most irritating that a website can actually trap Ctrl-N and prevent you from creating new windows. I have a case where I could first press Ctrl-L or Ctrl-K to activate the URL bar and then hit Ctrl-N but hey, the web page traps L and K too for its own purposes.

I don't think a W3C spec is needed to solve the immediate problems: once Firefox supports some overrides that keeps the users happy, then there's all the time to figure out a perfect hierarchy for the event flow for all browsers and work to make it a specification.
(In reply to Michael White from comment #140)
> I do think that when the page loads, the site can request access to extended
> keyboard shortcut functionality and then the browser just replies with a
> boolean result indicating whether the user has granted permission or not.

I agree that there needs to be default functionality where the website can detect and adapt to disabled shortcuts. That being said, power users *need* to be able to override this behavior (through about:config at an absolute minimum).

I've just encountered a web app that, through lazy design and a misguided attempt to prevent users seeing their code, disabled both the context menu and *all* browser keyboard shortcuts. I guarantee that if the developers of this app were able to easily detect that hooking keyboard shortcuts were disabled, their immediate response would be to put up a blocking page with instructions explaining that the site cannot be accessed until the user changes such-and-such a setting in their browser.

Given the sever usability problems this bad behavior causes, I don't think we want to encourage that sort of behavior without some way around it for the users that know what they're doing.
Chrome had (has?) a setting, which allows to get a contextmenu by double-rightclick.
In Firefox Win, I was in a webmail, and I pressed Alt S, for the menu History. My window disappearead! In fact, the e-mail I was writing has just been sent by accident! My e-mail was all right, but this kind of accident can be very bad.

The menu bar of the window had the "s" underlined on the menu History. This means: 
"Press Alt S to unroll the menu History." 
I pressed Alt S. 
And Firefox has failed. 

1) Firefox did not unroll the menu History.

2) Firefox made an action decided arbitrarily by the author of the Web page. Nothing told the user about this. Here, the action was sending an e-mail to several people. With the action may come data loss, privacy breach..., you name it. Here, I noticed that an action occurred, and I (after wondering) found out what occurred. But the accidental action may occur even without the user knowing.

This is a security issue. 
Imagine an admin installing security updates on a server. He presses Alt S for the menu History and this activates a button "Skip this update"... The admin may even be left in ignorance of what "he" did.

This is really a problem. 

There is an easy way to solve the problem: honour the native keyboard commands, they have priority.

Then, more elaborate solutions can be designed, to allow Web pages to use some keyboard commands.

Thank you.
Its a question of focus and how its handled. Take this bugzilla page and press ctrl-a. Either the textarea has the focus and you select the text, or the page has the focus and you select the whole page. 
And then there are global shortcuts: Press Alt-s and the history menu will open (here).
This behaviour is the same for all normal programs, the user expects some shortcuts to be local (ctrl-a/c/x/v) and others to be global (alt-f4). Then he expects neutral keys to work only on textwidgets. For example its a difference if you press "n" in a textbox or without focus on twitter, without a focused element it opens a compose tweet "window". The problem here is, that the user cannot know which page requested which shortcuts, but on the other hand he cannot know which shortcuts the browser might use. the History menu for example opens for you on alt-s, i get focus on the urlbar, i guess because of german locale with "_C_hronik" menu.
So the shortcuts should either go to the browser or to nothing at all, but not "if the browser has another locale we send the shortcut to the website". Then you again hit alt-s and send the mail, just because you did not expect the other browser locale.

I think for any special handling the page should request access to the keyboard via a doorhanger notification, just as it needs to ask for location, etc.
When the page does not need the features so bady, that its worth to annoy the user, it should avoid capturing the keyboard.
(In reply to Bastiaan Jacques from comment #110)

> Does anyone know if there is a workaround for this issue, such as a
> third-party extension, to prevent websites overriding keyboard shortcut
> controls? I am noticing that more and more websites are taking advantage of
> this "feature" to remove my control over the browser.

The (life-saving) extension QuickJS may help you : 
https://addons.mozilla.org/fr/firefox/addon/quickjs/?src=search 
This extension helps us to quickly turn on and turn off JavaScript. Turning off JavaScript often - always ? - turns off the hijacking of keyboard command.
There is a bug in the bug.

In Firefox Mac, I press Apple N or Apple T. 
This is expected to create a new window or a new tab. This fails, because of a plug-in or video. 
But the menu File blinks in blue, as if the menu item had been triggered. 
This is inconsistent.
Facebook comment (oddly, not the main post) input fields now break Ctrl-K behaviour because they have implemented emacs-like editing shortcuts (I think?). This is annoying or worse, depending what the behaviour in the web application happens to be; the browser's global shortcuts should trump anything the JavaScript tries to do. The whole point of them is to avoid having to use the mouse to change focus.

At minimum a doorhanger is necessary when shortcuts are going to override built-ins.
Using the latest versions of Firefox and this is still an ongoing issue on Twitter. The site hijacks all keyboard shortcuts: Ctrl+W, Ctrl+T, number keys — almost everything (Ctrl+L still works). Only mouse input can be used.

There used to be a userscript that prevented this behavior on sites like Google, but it has since stopped working with more recent updates in the past year.

At the very least it shouldn't be possible to hijack browser shortcuts with modifiers such as Control, Alt, Shift.
I think we all can agree that the ability to override keyboard shortcuts is an important and useful feature.  Yes, it does provide web pages with the ability to be seriously annoying but it's not a show-stopper.  If it were, users would be complaining a *lot* more and a lot louder about this.

Now consider how much of a show-stopper it is for web applications that *need* the power to override things like Ctrl-T and Ctrl-W.  Consider a web-based terminal emulator or a remote desktop application:  Without the ability to override keyboard shortcuts users would be in for one hell of a surprise when they Ctrl-W to switch viewports in vim only to find that their browser tab just closed; potentially losing all their work!  The same thing would happen to a user that tried to close a window inside of a virtual desktop only to find that their whole session just got disconnected due to the tab being closed.

So from a user perspective web pages that override these shortcuts *in a bad way* are merely annoying but the inability of web applications to override certain shortcuts is most certainly a *usability nightmare*.
> So from a user perspective web pages that override these shortcuts *in a bad
> way* are merely annoying but the inability of web applications to override
> certain shortcuts is most certainly a *usability nightmare*.

There are similar counter-examples where a web page can cause another *usability nightmare* by hijacking browser shortcuts. For example, Jira likes to grab Alt-1/2/3/... for changing tabs and there are webpages that grab Ctrl-L/Ctrl-K for focusing the url/search bar.

A simple toggle to whitelist/blacklist this behaviour per site would solve these problems for good. Is it possible to implement this as an add-on?

(The fact that Joe Average isn't complaining doesn't mean it's not a real problem. Heck, he uses IE and doesn't even know it, and is pretty happy with it: that's a way low bar for any competing browser.)
You're implying, such webapps would be vitally important for most users.

Let's look at the terminal emulator. Look at ConnectBot for Android, which has a onscreen ctrl-button, because android just does not have such an mechanism. This would be a good option for the website, too. Webapps are just not native, this means i expect them to be sandboxed and not to interfere with my OS.

Hijacking Ctrl-w is like html5 fullscreen video without asking first. And it can be handles in the same way: Display a doorhanger notifaction "VM-Controlpanel wants to bind all ctrl-shortcuts to the webpage. allow/allow once/deny".

I guess for an addon it would be an race to unbind / prevent binding the keys via Javascript, which means the addon would break on each website, which does it in a slightly different way. Of course frameworks like jquery could be covered, but less frequently used frameworks or own implementations could cause trouble, while the feature could just be handled at browser level, where the actual used api is located.
Sorry for the "advocacy" post, but this isn't just Ctrl+X keyboard, but even as simple as the arrow keys. There's nothing more jarring than trying to use a Google search, and it hijacks the arrow keys not to scroll the page, but to move a result-to-result cursor instead... Or the New York Times hijacks Page up/Page Down to use their own animation library (that smooth scrolls...) rather than letting the browser/OS respect my "no animations, no smooth scrolling" settings.
I think what's going on here is there's a divide between folks who view the web as "pages" and those who view it as an application platform.  Since pretty much all applications have their own keyboard shortcuts it makes sense to allow each *web* application to define their own as well.  Even if it means that some developers will make unintuitive choices.

When Google.com overrides your arrow keys you're not really having a problem with the browser or the JavaScript framework that allowed such behavior.  You have a problem with Google's decision to override those keys.  In fact, the "problem" you're having is just your opinion...  It differs from Google's.

To get the best of both worlds I think browsers should allow web applications to override whatever shortcuts they please with a mechanism for users to revert them or to choose their own.  A site or page-specific keyboard shortcut manager, if you will.

As a developer I would *love* such a feature!  It would mean that I no longer have to write my own keyboard shortcut management interface (if I wanted users to be able to set their own).  It would be doubly-awesome if users could bind keystrokes to not only other keystrokes but to execute arbitrary JavaScript with an API available for developers to provide easy-to-use lists of commonly-used functions to users (within the interface).  So as a developer I may bind the down arrow key as "nextArticle()" but in the user's keyboard shortcut interface they would see a descriptive item instead, "Next Article" along with some other options that the developer has provided.

I'm totally OK with the ask-once, "This site wishes to override some keyboard shortcuts.  Allow/Deny" but I think a keyboard shortcut manager would be better.  Users already get prompted for too many things.
I am a bit curious, why anybody thought of letting pages override stuff like context menu or shortcuts. But now it's there.
To avoid users from saying "Browser X does not ask me questions on google" it could just be a little indicator icon in the URL-Bar, which pops up a doorhanger on click (do you want to disable keyboard access? click here to rebind the shortcuts [shows list of keys and if provided by the page descriptions of the function]).

The problem i am having with google, twitter, etc. is, that i do not find it awesome when they invent their own navigation, when i have my working navigation for all pages the same and should now adopt navigation, which is defined by the sites, where each site has different UX ideas.

There are some concepts to avoid this, for example chrome had (they removed it) the function to override the context menu on right click, but double-rightclick opened the chrome context menu instead of the site's context menu implementation. For Keys it would be more like some (site-)setting "disallow overriding keyboard shortcuts".

And it would be great to make it configurable. I really like the "n" function on twitter, but really dislike the blocked ctrl-w. Either display what the site uses and allow to choose from, or have rules like "no shortcuts with ctrl, but everything else".
(In reply to Riskable from comment #167)
> I think what's going on here is there's a divide between folks who view the
> web as "pages" and those who view it as an application platform.  Since
> pretty much all applications have their own keyboard shortcuts it makes
> sense to allow each *web* application to define their own as well.  Even if
> it means that some developers will make unintuitive choices.

It has to ask to hijack my screen (go full screen), or to use my webcam. Look at the huge, well-recognized uproar when the browser takes over the speakers without permission (ie, auto-playing audio/video). Shall the browser allow a page to capture the mouse within its confines as well? A page should absolutely never, in any way, be able to override the user, browser or OS without confirmation.
There may be another UX issue:
I guess the pages cannot override certain shortcuts like Alt+F4 for closing the window (which may be important for the evilscripts meta-bug, when a page tries to prevent closing).
But on Linux and OSX (at least there it was possible some time ago, no idea if its still possible) you can change the window manager. And for example some tiling window manager might use vim-keybindings for control.
I guess most will support alt+f4 in their default config, but for example "ctrl-x up" (whatever x is) might be "switch to upper pane". When a webpage captures this, this prevents the user from navigating to other windows without closing the browser window or changing the tab (can ctrl+pgup/pgdown be redefined?).
So some hard coded list of not allowed shortcuts may be not enough depending on the environment of the user.
It would be sad, if such power users would switch away from the most extendable browser, just because it messes with their desktop.

Personally i tried tiling WMs some time ago, but do not use it anymore. But i know some of the issues, especially on windows without WM-Decoration and so on.
(In reply to alex from comment #170)
> I guess most will support alt+f4 in their default config, but for example
> "ctrl-x up" (whatever x is) might be "switch to upper pane". When a webpage
> captures this, this prevents the user from navigating to other windows
> without closing the browser window or changing the tab (can ctrl+pgup/pgdown
> be redefined?).

IIRC, if a window manager takes a global shortcut, no other apps see it--the WM always gets it first. So, no web page (or even Firefox itself) would be able to use it for something else.

(In reply to bobbuun from comment #169)
> (In reply to Riskable from comment #167)
> > I think what's going on here is there's a divide between folks who view the
> > web as "pages" and those who view it as an application platform.  Since
> > pretty much all applications have their own keyboard shortcuts it makes
> > sense to allow each *web* application to define their own as well.  Even if
> > it means that some developers will make unintuitive choices.
> 
> It has to ask to hijack my screen (go full screen), or to use my webcam.
> Look at the huge, well-recognized uproar when the browser takes over the
> speakers without permission (ie, auto-playing audio/video). Shall the
> browser allow a page to capture the mouse within its confines as well? A
> page should absolutely never, in any way, be able to override the user,
> browser or OS without confirmation.

My opinion has been that apps running within a browser window are subordinate to the browser, period, and I agree that they should be restricted. The Web was built before the concept of “web apps” was conceived, and I never really felt that the Web was a particularly good vehicle for “apps”, anyway--to this day, their UX and performance still lags sorely behind that of native desktop apps. If an app really needs this much control over the system (and we're dealing with /untrusted/ data here, remember), I always felt that a different platform should be used, or perhaps some new system that allows apps from the Web to run in their own spaces without conflicting with the browser windows themselves should be designed. Though this is of course well outside the scope of this bug.
A bug which sends out notifications for every change to over a hundred people is not the best place to have discussions like this. (though, the way the bug is summarized, it's not as out of place as usual) I suggest taking it elsewhere, and please avoid re-arguing points verbosely, as it's not all that productive.

----------

My opinion: We really should standardize a 3 tiered system to deal with this problem. There is no one-size-fits-all solution for this. The different scenarios need different permissions:
1) Standard webpage  => override basic keys, but no modifier combo overrides (alt/ctrl/meta/etc)
2) Standard web-app  => override all keys except for those that directly control the browser
3) Immersive web-app => override everything; special permission required (à la full screen)

User permission should be required to go from #1 to #2 or #3, but #2 should be able to be remembered for entire domains easily with a less scary user prompt. Most pages don't need everything, some need shortcuts (within reason), and things like games often work best with access to (almost) everything.

This probably needs to be addressed at the standards level, not here. This is not to say that we shouldn't be doing something here first; the ability to trivially override core browser shortcuts needs to be gated behind something, as the current situation is a mess.
(In reply to Simo Melenius from comment #164)
> A simple toggle to whitelist/blacklist this behaviour per site would solve
> these problems for good. Is it possible to implement this as an add-on?

This would be the middle ground that would solve most problems for users experiencing usability-breaking problems. There needs to be such a manager, even if in the form of an addon, just like there are other permission managers for various content such as Javascript, cookies, etc.
Interesting url for issues with sites capturing your keys: https://medium.com/medium-eng/the-curious-case-of-disappearing-polish-s-fa398313d4df#.uz7whex5a
(In reply to theryanhollis from comment #106)
> I would like to add my two cents here. I just came from a discourse forum
> site that hijacks your Command+F shortcut to search the site rather than
> allowing the browser to search the page.

I don't know which forum you were referring to, but ironically Mozilla's own Discourse platform does this, too.

E.g. https://discourse.mozilla-community.org/t/planning-the-future-of-complete-themes/5306/
Very Annoying: Ctrl-Shift-T to reopen closed tabs doesn't work on twitter. You need to use the menu (hidden by default in recent mozilla, because err ui must look like chrome).

I guess we should search, which functions are only available via shortcuts and not accessible at all on sites like twitter.
Whiteboard: [games:p2][parity-chrome] → [games:p?][parity-chrome]
From games perspective the current ability to override keys has been adequate. Some people have asked to be able to override esc key to not take out of fullscreen mode, but instead to take into game menu. That is not likely to happen.

In current state pages can override Ctrl-S, F5, and Ctrl-F, STR: https://dl.dropboxusercontent.com/u/40949268/code/overridden_keypress.html

Comment 0 (from 2007) reads as if it's asking to add support for overriding Ctrl-S. By above STR that is possible today, so I am going to mark this bug as resolved. Reading the comments, there's a lot of conversation about how much a page should be able to override, but those are better discussed in spec forums, or as separate bug items with specific asks if they are contrary to comment 0.
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Whiteboard: [games:p?][parity-chrome] → [games:p3][parity-chrome]
There are at least some bugs that are about *preventing* sites from overriding keypresses that are marked as duplicates of this bug. Among them are, for example, bug 980777 and bug 1053430.

If the meaning of this bug has suddenly changed, maybe those bug reports should be updated accordingly (reopened?).
So, this is resolved fixed. What does this mean, please? What's the verdict?
(In reply to Jukka Jylänki from comment #177)
> From games perspective...

This bug isn't just about the games perspective. eg:

(In reply to Nuno Silva from comment #178)
> There are at least some bugs that are about *preventing* sites from
> overriding keypresses that are marked as duplicates of this bug. Among them
> are, for example, bug 980777 and bug 1053430.

While a resolution isn't clear, I don't think were at the point where this should be closed.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I have never been subscribed for a bug nearly as annoying as this one. I feel there were thousands complaining about this serious usability issue, but no developer cares. That really reminds me of big companies with support hotlines, which are there to calm people down instead of helping them. Also I really found myself asking how many trolls must be working for mozilla nowadays. But it might be more realistic to believe, that these kinds of problems arise in over engineered software, where developers join and write spare code just for the sake of being mentioned somewhere on the website and for being one of the guys "behind" the **famous** software. This often goes along with little inspiration like "lets do it like chrome does it" and I have already stopped using firefox for that reason. The only thing firefox can still do better than chromium is, that it does not cache http error pages, which is poison for web developers. But I am sure that now that I have said that there is a troll willing to implement it as well. For me: No problem. There are many good browsers out there. Firefox used to be one of them, but that was the other day.
(In reply to Mark Hammond [:markh] from comment #180)
> (In reply to Jukka Jylänki from comment #177)
> > From games perspective...
> 
> This bug isn't just about the games perspective. eg:
> 
> (In reply to Nuno Silva from comment #178)
> > There are at least some bugs that are about *preventing* sites from
> > overriding keypresses that are marked as duplicates of this bug. Among them
> > are, for example, bug 980777 and bug 1053430.
> 
> While a resolution isn't clear, I don't think were at the point where this
> should be closed.

I did not mean the resolution from "the games perspective", but from the perspective of comment 0, where support for this was asked. In the STR in comment 177 I noted that the missing support has been implemented.

Nuno has a good point of the duplicates, and I'd rather prefer closing this and reopening one of those for discussion (bug 980777 seems like a good candidate), because since comment 0, the implementation status has flipped to the opposite, from not being able to override to being able to override, which is not well reflected in the title of this bug, comment 0, or the long wall of comments. I think it would serve better to open one of the bug items asking to remove support to override, since that would better reflect the current status from its comment 0 onwards. However I guess it's ok to me either way.

(In reply to Shahar Or from comment #179)
> So, this is resolved fixed. What does this mean, please? What's the verdict?

I don't know about the verdict, but currently Firefox and other browsers do allow overriding these keys, opposite to what the implementation status was in 2007 when comment 0 was posted.
(In reply to Jukka Jylänki from comment #182)
> (In reply to Mark Hammond [:markh] from comment #180)
> > (In reply to Jukka Jylänki from comment #177)
> > > From games perspective...
> > 
> > This bug isn't just about the games perspective. eg:
> > 
> > (In reply to Nuno Silva from comment #178)
> > > There are at least some bugs that are about *preventing* sites from
> > > overriding keypresses that are marked as duplicates of this bug. Among them
> > > are, for example, bug 980777 and bug 1053430.
> > 
> > While a resolution isn't clear, I don't think were at the point where this
> > should be closed.
> 
> I did not mean the resolution from "the games perspective", but from the
> perspective of comment 0, where support for this was asked. In the STR in
> comment 177 I noted that the missing support has been implemented.

I agree this bug is ambiguous - but nothing has landed here, so "fixed" just adds to the ambiguity.
 
> Nuno has a good point of the duplicates, and I'd rather prefer closing this
> and reopening one of those for discussion (bug 980777 seems like a good
> candidate),

Almost all dupes are "the site stole my keystrokes" - if we nominate one of those dupes as the "canonical" one, we really should then update all the other dupes currently pointing here (or they confusingly get pointed to a "FIXED" bug). IMO, it's much easier to just adopt this bug as that canonical bug and update its title accordingly
Sure, that works as well.
Summary: Should web pages be able to override the browser's keyboard shortcuts? → Should web pages be restricted from being able to override the browser's keyboard shortcuts?
In contrast to reports in comment 182, I observe that Firefox 49.0.1 does *not* seem to allow override of Ctrl-N, Ctrl-W, and Ctrl-T, which I think changed recently.  (I'm not sure when.)   I use these keys inside a terminal emulator (tty.js) and it presents a usability issue for me if they *cannot* be overridden.

1. Could someone summarize the current state of play and thinking?

2. Aggressive/angry comments (such as comment 181) are not useful to anyone, especially if they don't clearly state a position.  (Is #181 for or against preventDefault?  I can't tell.)  This is clearly an emotional issue, with arguments on both sides, as evidenced by the 185+ comments.  I politely recommend that we keep the discussion respectful.
Whatever will be the new default, give us an about:config option to tune it.

Something like
allowOverrides(bool) "true"
overridePrevented(string) "ctrl-t,ctrl-w"
I will come back to this, because my comment was mentioned in #185. Having feelings about this topic is nothing I would decline. This issue was first reported back in 2007 and is still not solved. There have been many good suggestions in this thread and even today I find my suggestion from 2014 (see #101) to be still a valid option, but nobody ever cared. So to answer your first Question is: The current state of this discussion seems to be, that nearly everything has been said about the topic itself and essentially the list of comments have become so long, that no developer will ever have the time to read them all again in order to make a sane decision based on all of our ideas. That is somehow sobering, but also reveals, that this issue isn't the only one we are facing. It is the ratio between developers and users and that a bugtracker gets used, which isn't exactly the right tool for the job we used it for, because the comment section of a bugtracker does not help much in finding a consent. I am quite sure, that we would be much better off if we had something like stackoverflow for this discussion.
I'm from the Google Chrome team and am trying to figure out what's going on here as it would be helpful to synchronize.

From what I can tell, the keyboard shortcuts used to be capturable in Firefox, at the start of 2016, but now they aren't, but I can't find when this change was made, or what the rationale was at the time. This thread has a lot of discussion but I don't see any links to commits or an official Mozilla stance on "we changed it because of reason X".

I think it makes sense to allow all shortcuts other than Esc to be captured in Fullscreen mode, but not allowing the site to capture browser shortcuts outside of fullscreen. This should help with the gaming use case, but keep the browser useable outside of fullscreen.
This was done in bug 1074971 for tab and window management commands when multi-process support was added so that a slow or hung content page would not prevent these commands from working. I don't think anything different or special applies when in fullscreen mode.
I'm confused about whether this bug addresses the issue of:

a) Preventing websites from overriding users' keyboard shortcuts
b) Ensuring keyboard shortcuts work in full screen mode
c) Allowing websites to override some keyboard shortcuts that they cannot (ex ALT-F4)

My interpretation of this issue, and my desire for a fix, corresponds to a).

I'm with Alex in comment #186.   Give us an option in about:config and those of us who use it will gladly deal with the consequences (I.E. potentially impaired website).   I'm even fine with a simple on/off switch for letting websites set keyboard shortcuts.

Another suggestion is to assign priorities.  For instance, if I set ALT-SHIFT-X as an OS-level shortcut, then I should having the option or preventing a website from hijacking it and instead allow a website to only use a keyboard shortcut if it has not yet been assigned.
If you set ALT-SHIFT-X as an OS-level shortcut, I suppose that the application (e.g. Firefox) won't see it because it won't receive the corresponding event. The problem concerns the application's own keyboard shortcuts.
Here's a concrete example:

I have Tab Groups installed and set to CTRL-ALT-E to show my open tabs in a grid view.  Whenever I'm in a tab that has Jira open, Jira will hijack CTRL-ALT-E, preventing me from viewing my tabs.   There's no way to override this.
(In reply to Vincent Lefevre from comment #192)
> If you set ALT-SHIFT-X as an OS-level shortcut, I suppose that the
> application (e.g. Firefox) won't see it because it won't receive the
> corresponding event. The problem concerns the application's own keyboard
> shortcuts.

No. OS level level key input is being hijacked, as well. For example, my keyboard layout in Windows (common for people who write in non-English languages) uses CTL-ALT combinations for several characters (for example: č, ß, š, and many others), but I have had a number of websites hijack key combinations which has resulted in rather unexpected actions occurring while typing text, included unexpected *public* posting of data that should *not* have been. Even though many of these combinations are CTL+ALT combinations, the actions will get triggered on some even if their site is looking for a CTL only combo (poorly programmed key input testing by the website designer, apparently).
(In reply to busi.bugzilla from comment #194)
> No. OS level level key input is being hijacked, as well. For example, my
> keyboard layout in Windows (common for people who write in non-English
> languages) uses CTL-ALT combinations for several characters (for example: č,
> ß, š, and many others), [...]

OK, but these are not OS-level shortcuts. This is a keyboard input method. It seems that no-one mentioned this problem yet. I think that this makes the problem even worse as the application may not be aware of how some special characters are entered. If I understand correctly, there are probably no problems under Linux as the ISO_Level3_Shift modifier is used for that, while it is not part of the modifiers considered by Firefox if https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Attribute/modifiers is still valid. But this may be a problem on other OS.
This is embarrassing, the bug has been rolling on for years.

All we need is a about:config toggle to disallow web pages' ability to override browser shortcuts should the user choose to do so.

For example, Jira has made me almost avoid alt-1, alt-2, etc. all together(!) in switching tabs because Jira will hijack those for its own purposes and I've switched Jira views too many times instead of switching to tab #2.

There needs to be no discussion about what the "correct" engineering solution should be or whether pages should see if the browser allows/disallows certain keys because by making it an about:config toggle, the responsibility is shifted to the user itself. If a web page doesn't work with the shortcut override disallowed the user will just have to toggle the setting. This simple feature alone would've shrunk the comments and agony in this thread down to 1%. This is akin to disabling flash/autoplay/javascript/3rd-party stuff which all isn't necessarily communicated to the web page itself. Some pages don't work with those disabled so users will just enable flash/scripting/cookies for those sites. There's no problem for the browser nor the websites. The user is in control. Newbies won't disable anything and everything works as intended.

All the better, if the shortcut override disallow toggle consisted of a global default value for allow/disallow, and a per-site specific override then the user can either disable shortcut overrides by default and explicitly enable for certain sites that s/he feels important, or allow shortcut override as today but explicitly disable them for problematic web sites.
+1 to comment #196, even though I would have put it more diplomatically.

By giving responsibility to the user for toggling the config, which by default would set to allow the current behaviour, all questions of proper engineering are put aside.  If this breaks a particular site's workflow, then the user toggling the feature has noone to blame put themselves.   Also, any affected website's company has no cause to complain, since 99% of their users will be using the website's recommended workflow.

What is to be gained is that power users with specific workflows will now have the flexibility they desire.

BTW, it is possible to disable keyboard shortcuts in Jira:

https://confluence.atlassian.com/jiracoreserver072/using-keyboard-shortcuts-829092599.html

Also, here's a good article on this overall subject:

http://www.ghacks.net/2014/08/15/how-to-prevent-websites-from-hijacking-keyboard-shortcuts/
Maybe disallowing SHOULD be the default, to pressure the sites in not stealing important shortcuts.

A common example is ctrl-f, which is often deliberately overriden by the site.
They then focus their search function, which searches for other pages, while the users wanted to search in page. Even when the self implemented search function would search in page, it's not the function the user wanted to use and i would think users knowing the search shortcut are familiar with the default search and a site hijacking it violates the principle of least surprise. And the only workaround is to active find in page via the edit-menu (hidden by default in recent firefox versions).

I think there possible should be some rule about which shortcuts are reserved. Like Shortcuts using ctrl (i guess that's the shortcuts of most browser features) can never be used by websites, while they can rely on alt (without ctrl). Using Alt-1 to switch to the first tab can then have an option "do not allow sites to hijack" or should be moved to Ctrl-Alt-1.

Most annoying examples:
- Disabling tab management: ctrl-t / ctrl-w
- Disabling search: ctrl-f
- Some sites are interfering with features like unicode-input
Keystroke trapping websites interfere with accessibility extensions like Vimium and Vimrc.  These extensions are important for people trying to mitigate the effects of RSI symptoms by avoiding use of the mouse, but sites that try to mimic native applications by trapping keystrokes (e.g. Office 365 Outlook) inadvertently put their users at greater risk.

Per #196, please let folks toggle this feature off!
After following this bug report and the Chromium equivalent for *years* I think there's only one conclusion to draw:  There's no consensus.  Allowing websites to override default keyboard shortcuts can hurt usability but *not* allowing them to override default shortcuts *also* hurts usability.  Whether or not it hurts or helps is entirely based on context (the site/app).

Example where overrides hurt usability:  Regular web pages (not apps) that override Ctrl-F.  Annoys the hell out of me!

Example where preventing overrides hurts usability:  Remote desktop and applications that embed a terminal.  It is SO incredibly frustrating to type Ctrl-W in vim and suddenly have your browser tab close!

I think the only way to make this work for *all* situations is to make it user-configurable.  Not only user-configurable but configurable on a per-site basis.  That would ensure that *all* use cases are covered and when someone has an issue you can just point them to the settings in question.
I agree that a per-site configuration would be necessary. But a global on/off switch would still be a big improvement if this is easier to implement as an urgent fix.
(In reply to Vincent Lefevre from comment #201)
> I agree that a per-site configuration would be necessary. But a global
> on/off switch would still be a big improvement if this is easier to
> implement as an urgent fix.

The existence of a switch would also open the door for extension authors to provide a more nuanced interface for controlling it (a la NoScript), would it not?

If the Firefox dev team just makes the basic functionality available, the rest of the community can worry about making something that works well for various user interests. Last I checked, that was one of Firefox's core strengths.
(In reply to Jason Brown from comment #202)
> The existence of a switch would also open the door for extension authors to
> provide a more nuanced interface for controlling it (a la NoScript), would
> it not?

I was also wondering something like that, in particular whether it is possible to automatically change the config when the active tab changes.
Twitter has currently broken their JavaScript for some configurations which can make CTRL+F and CTRL+R inoperable for no good reason: https://bugzilla.mozilla.org/show_bug.cgi?id=1331631

I find this absolutely baffling that this is even allowed. I haven't seen a single site with a legitimate use for CTRL+F and CTRL+R, all of them either block it for malicious reasons or to provide some sort of inferior alternative that doesn't actually do what I wanted to do.

Can we at least block the most basic standard shortcuts per default from being overridden??
Please do not block any shortcuts! 
Web site development moving on. Thanks to spa and other techniques it is now possible to write large application like sites. We build such a application and ctrl+f and ctrl+r are bound to filter dialogs within this site.
A user on such site likes to use the shortcuts like they use them in desktop apps. So as many as possible shortcuts should be boundable and overrideable by the developer. 

Also think about different browsers. There are some others... Every browser brings some standard shortcuts that developer can not override. The intersection of possible shortcuts is not so big. 
Since FireFox > 47 many of the ALT+[..] shortcuts no more usable (Bug#1333459). A big problem for us, because on our site ALT+[..] allows the user to navigate through the application (jump to fieldsets, labels and so on).

I prefer a per-site configuration as well!
(In reply to carsten.kroeger from comment #205)
But this is EXACTLY the behaviour, why we're here discussing the bug. We DO NOT want your website to disable shortcuts, which have a way they should work.

An opt-in method for the site to request shortcuts (best with a white-list option to allow only certain of the shortcuts) would be a good solution, but stop overriding well-known shortcuts like ctrl-r or ctrl-f. They already have a meaning.
One idea I just came up with is to have Firefox run in two modes, with a switch between them triggered either by a button in the browser UI and a keyboard shortcut that all websites would be prohibited from using themselves (ex CTRL-ESC):

1) Website keyboard shortcuts enabled (all keyboard shortcuts the website enables would override all other shortcuts except CTRL-ESC)
2) Website keyboard shortcuts disabled (no keyboard shortcuts are overridden by the website)

Firefox's UI would very clearly indicate which mode it would be operating in via a very strong visual cue, and the switch between the modes would be near instantaneous.

This way the website developer gets to preserve their own "desktop-like" user experience, even for things like CTRL-F/CTRL-R, but the user can easily toggle the behaviour.

This way both website devs and browser users will be satisfied?
Maybe this can go into a feature request: An app like mode for webapps?

Some time ago we had "mozilla prism" as a Browser with minimal chrome, which opens external links in the system's default browser. (Google) Chrome as an app-mode as well. And such a mode doesn't have a need i.e. for ctrl-w (because the window has no tabs) and should behave like a desktop application anyway.

This would benefit quite a few websites, which try to provide a whole application experience.
An app mode (preferably one where I get to say "No" if I don't want to run something in app mode) would be HIGHLY preferred to the current wild west nonsense going on with sites:

- blocking CTRL+F or replacing it with an inferior floating fancy badly readable unnecessary dialog (like the forum software used by let's encrypt or forum software)

- blocking CTRL+R like twitter.com's web interface due to a site bug

- messing around with the clipboard, adding advertisement **** when I copy stuff

- ...

Sites can currently mess way too much with my browsing experience, and while I see the benefit for a few select web apps, I really don't see why any random website should be allowed to ruin my day so consistently.

TL;DR: +1 app mode (if it comes with a permission dialog for sites asking for it), -1 allowing this nonsense per default
I got tired of this problem. This patch adds a preference to prevent pages from overriding shortcuts. It uses the reserved key handling that was added previously by 1074971/1154183

That means that when the preference is enabled, all shortcut keys will be reserved by default. You can set reserved="false" (or "true") on a <key> element to force disable/enable it, ignoring the preference. We might want to do this for certain keys on a case by case basis.

This only handles keys for which a shortcut is defined. It doesn't currently handle alt accelerators preventing web pages from blocking accessing to the main menu. In e10s, this is prevented anyway currently due to 1333459. This could be done as a followup patch.

Note that when a key is reserved, the events for that key are not sent to the web page.
This part adds UI to Page Info -> Permissions to prevent pages from overriding shortcuts on a site by site basis.

Try/Test builds are at https://archive.mozilla.org/pub/firefox/try-builds/neil@mozilla.com-0f9d20902a4aac74be9e77ada80092f8baa3f44e/
♥♥♥♥ Neil Deakin ♥♥♥♥
I'm sorry but if you trust a website enough to not only be on it but to save it (Ctrl + S) or copy from it (Ctrl + C) you have to trust that it is OK for it to override keyboard shortcuts.

In the day and age where most websites are built like apps rather than for apps, they need that extended functionality. For example we had alt+s to submit your reply to a support ticket. Why? It mimics the behavior of outlook when sending emails (Our other method of support) and made people a bit more productive when replying to many tickets, not needing to waste extra tabs to clear the text fields or mouse movements. Additionally, it was nice to have! People have the right to nice things!

Now, for one reason or another, when we press alt+s, the history menu comes up and the form submits. It's just annoying, but removing it would become an issue for our team.

I accept that some people want to block it, and for them perhaps putting an 'opt-in' blocker of shortcut overrides either in the preferences, via the URL bar popdown or in the advanced settings (about:config) would make the most sense. You could further enhance this by having a whitelist that doesn't get blocked or (when it isn't enabled) a blacklist that is explicitly blocked from accessing keyboard shortcuts.

Again, I re-iterate that I do not believe disabling this functionality BY DEFAULT is the right approach as it severely hurts developers abilities to extend user interaction.
I guess the best would be a (cross-browser) standard in some way, defining what to do with shortcuts. You cannot grad ctrl without restricting important functionality, you cannot grad alt without interfering with menus ... so it would either need some key to get first into "keys are now used on the webpage" mode or some other key to be used (maybe windows/super key?), which isn't overloaded that much. Or another option: All grabbing all keys (except esc and F11) in fullscreen mode, ask if keys are allowed to be grabbed (and restrict some important ones like ctrl-w, ctrl-t, ctrl-pgup, ctrl-pgdown, ..., which are commonly used to leave the site (either close it or open a new one or go to the next one)) otherwise.
(In reply to Tarquin Macey from comment #213)
> In the day and age where most websites are built like apps rather than for apps, they need that extended functionality.

Most websites I go to are not intended to be built like apps.

> For example we had alt+s to submit your reply to a support ticket. Why? It mimics the behavior of outlook when sending emails

Not all people use Outlook, and certainly not Linux users. Moreover, other websites support form submission, so that this introduces an inconsistency between websites (and possibly not following the UI of the apps used by the user). For consistency, the websites should provide the semantics, and the browser should provide the shortcuts (possibly chosen by the user).
(In reply to Vincent Lefevre from comment #215)
> (In reply to Tarquin Macey from comment #213)
> > In the day and age where most websites are built like apps rather than for apps, they need that extended functionality.
> 
> Most websites I go to are not intended to be built like apps.

Facebook, Twitter and any other social or otherwise engaging website (not news or article based) are pushing the emphasis on giving their functionality to both desktop and mobile users alike. Their structure almost takes on what would typically be seen as app-like functionality.
The web is growing, both in the way it looks and how it functions. Look at jQuery, Bootstrap and even PHP and how they have evolved the past 5 years alone.

> 
> > For example we had alt+s to submit your reply to a support ticket. Why? It mimics the behavior of outlook when sending emails
> 
> Not all people use Outlook, and certainly not Linux users. Moreover, other
> websites support form submission, so that this introduces an inconsistency
> between websites (and possibly not following the UI of the apps used by the
> user). For consistency, the websites should provide the semantics, and the
> browser should provide the shortcuts (possibly chosen by the user).

I'm sorry if you feel like I'm suggesting that we all standardize submit forms to instead use alt s. I was in fact giving an EXAMPLE of such a use, internally within our organization, of how the hotkey is used. We use other hotkeys but this is the one that is affected by recent changes which lead to this bug.

My original point stands that we should be able to determine hotkeys for visitors to OUR websites. If they are against it, they SHOULD be able to blacklist websites from using said functionality OR disable it globally (and whitelist exceptions)

You mentioned chosing shortcuts by the user; That is a good idea also. However websites need to be able to dictate the defaults. Otherwise a user is expected to, upon first visit on a website, start keybinding shortcuts to buttons? That makes no sense.

This bug/suggestion/topic/debate/idea/etc... is important because this enables a higher level of customization from developers for their users and can allow them (us) to provide assistive technologies as well, for example the older clients that we server prefer to use an alt+k combo to open up a certain page that would otherwise require they go via a different route - before you answer, sometimes it isn't plausible to simply move or add hyperlinks.
I think the browser is not your app. If you want to build an app, do so.
But there is potential to use an extension. Build some extension, which adds the navigation, it can even add some navigation to the browser chrome.

For firefox there is an opportunity to make this extenable:

- Disallow pages to override such shortcuts
- Allow sites to specify a set of shortcuts, they would want to use
- Allow the user to accept it or redefine some of the shortcuts.

For this, there should be a set of standard commands like SAVE_MESSAGE POST_PUBLICLY, DELETE_ITEM and so on. The user can customize this browser-wide, so he doesn't need to change the SAVE_MESSAGE shortcut on each new app-website, but only once. Custom shortcuts like _facebook.com_LIKE_ITEM would remain non-global and you can override the global-shortcuts on a per-site basis via the menu when clicking the favicon.

The would help, because you for example want to use alt-s, while the typical Mac uses alt primary as Alt-Gr.
You may be able to remap ctrl to the inifity symbol on the mac without creating too much confusion, but there are still places where the user actually wants to use ctrl.

It's easier to keep the browser consistent (which has one company behind it), then the websites of thousands of companies.
+1 to Comment #217.

This is how popular Java IDEs Eclipse, IntelliJ and NetBeans do it.  They allow their users to override keyboard shortcuts liberally.  I've done some heavy customizations to my Eclipse keyboard shortcuts because, for instance, I'd rather hit ALT-T to start a unit test than ALT-SHIFT-X T.

All browser users should enjoy the same freedom to customize.
(In reply to Tarquin Macey from comment #213)
> I'm sorry but if you trust a website enough to not only be on it but to save
> it (Ctrl + S) or copy from it (Ctrl + C) you have to trust that it is OK for
> it to override keyboard shortcuts.

I rarely want to step in but for the sake of security what you said is just completely bogus.

The reason people can "trust" websites for functionality and information retrieval is precisely because they can trust the browsers to keep the websites from jumping out of their cage: that the browser will actually enforce sandboxing the website inside the browser's renderer view, and this very much includes things like keyboard shortcuts.

Now, if a user wnats (or a majority of users want) to give a trusted website (or all websites) more privileges and let the site act in application-like way that is perfectly fine, and browsers should support that as well.

But there's a huge difference in being able to trust the browser to keep websites sandboxed and being able to trust a website enough to let it take over parts of the browser chrome. They are by no means even comparable.

> Again, I re-iterate that I do not believe disabling this functionality BY
> DEFAULT is the right approach as it severely hurts developers abilities to
> extend user interaction.

That is between the website developers and their users, not between developers and browsers. The default setting is effectively user-dependent and not browser-dependent. Browsers should support both, and users and websites should consequently expect nothing from each other. There's no single policy in this case that works for all.

Now, the main problem in this thread is that users aren't able to disable the way various websites steal their shortcuts.

Being able to do so should not be a severe concern for anyone in the majority of the cases.
Attached patch Part 3 - move reserved check into ContentUtils (obsolete) (deleted) — — Splinter Review 

        Attachment #264756 -
        Attachment is obsolete: true

        Attachment #264778 -
        Attachment is obsolete: true

    
    

    
  


  
This allows the menu accesskeys (Alt+Letter) to not be blockable when shortcut overriding is disabled.

It isn't quite complete; it doesn't handle when alt is pressed and released on its own or F10 for example. A proper solution would require 1333459 (and in turn 1257617).
Assignee: bugs → enndeakin
Status: REOPENED → ASSIGNED

    
    

    
  
Note that some pages, like the Discourse forum software for example, override Ctrl-F because they dynamically add and remove parts of the page from the DOM depending on scroll location (for performance reasons), the browsers builtin find in page feature does not work properly on such pages.

    
    

    
  
Well, that's (possibly) broken design of the website. They can use a "search with our endless scroll" feature using another hotkey. Ctrl-F is searching the current content, excluding not yet loaded content by design.

But when there is a gui to let webpages request shortcuts, you will be able to accept ctrl-f from discourse forums.

    
    

    
  


  
This version adds a test and changes to use an integer preference for compatibility with part 2.

This patch uses a hidden preference, exposes no UI, and is off by default, so we should be able to at least add this.

For part 2, it adds some UI. Do I need a UX review for this? From whom?

        Attachment #8834536 -
        Flags: review?(felipc)

    
    

    
  

      
      
      
      

        Attached image
          
        pageinfo-dialog.png (deleted)
        — 
      

    


  
This is an image of the Override Keyboard Shortcuts option added by part 2. The default is 'allow' to allow web sites to override browser keyboard shortcuts.

A build is at https://archive.mozilla.org/pub/firefox/try-builds/neil@mozilla.com-cd4a0881807c61cbc2f92b6b2eae2ca201f3f184/

        Attachment #8830379 -
        Attachment is obsolete: true

        Attachment #8834539 -
        Flags: ui-review?(philipp)

    
    

    
  
Comment on attachment 8834539 [details]
pageinfo-dialog.png

Let's do it!

        Attachment #8834539 -
        Flags: ui-review?(philipp) → ui-review+

    
    

    
  
Unfortunately, I have no idea what to do with the mass of stuff at the testing build or I would check this myself.

Can this be used to cause the slash (/) key to bring up Firefox's quick search on pages that override it like https://godoc.org/ ?

I expect doing so would break some rich text editing implementations so that typing / no longer works. Is the only option in those cases allowing all site overrides, or is more granularity possible?

    
    

    
  
> Can this be used to cause the slash (/) key to bring up Firefox's quick
> search on pages that override it like https://godoc.org/ ?

It does not, but you can prevent pages from overriding ctrl/cmd+f.

    
    

    
  
Comment on attachment 8834536 [details] [diff] [review]
Part 1.2 - add preference to prevent pages from overriding keyboard shortcuts

Review of attachment 8834536 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/xbl/nsXBLPrototypeHandler.h
@@ +48,5 @@
>  
> +enum XBLReservedKey : uint8_t {
> +  XBLReservedKey_False = 0,
> +  XBLReservedKey_True = 1,
> +  XBLReservedKey_Pref = 2,

I'd rename "_Pref" to "_Unset", and add a comment explaining here that Unset keys will follow the pref ui.key.reserveShortcutKeys.

This will help make it clear that true/false keys will not be affected by the pref.

Maybe you can reinforce that in the all.js comment too.

        Attachment #8834536 -
        Flags: review?(felipc) → review+

    
    

    
  


  
Updated and fix case where the default was block.

        Attachment #8830382 -
        Attachment is obsolete: true

        Attachment #8836749 -
        Flags: review?(felipc)

        Attachment #8836749 -
        Flags: review?(felipc) → review+

    
    

    
  
Hope this change ships, as it would be easier for me than the Chrome solution (https://stackoverflow.com/a/10933700/212264) of requiring you to start the browser in "application" mode. Not sure if/how this would work with local (file:///) pages, though.

I look forward to again having a functional "emacs" mode in the popular Ace (https://github.com/ajaxorg/ace) editor (ctrl-N being a rather crucial keystroke in emacs).

    
    

    
  
The problem with Ctrl+n,t,w is, that they don't allow you to escape the site. When i hit ctrl+w and the page doesn't close, i have the impression the browser is broken until i recognonize that actually the page is broken (and the browser allows it to break it). Ctrl+n would be another one.
When i do not want to close the page and even want to still see it when i open a new one, i hit Ctrl+n to open the next in a new window. In your editor it would not only break the new window, but even do something unexpected.

Pages like twitter with their single-key shortcuts are even worse, as you start typing without having the focus right and the page starts doing random actions ... but that's another issue, as the keydown event for letters is actually an javascript feature.

    
    

    
  
I'm a little confused by this bug.

I'm seeing what looks like 2 reviewed/approved patches, is that right?
Can I ask what's holding this bug back from landing?
(Apologies if the answer is found somewhere in this long bug. I didn't read all of it.)

    
    

    
  
(In reply to Caspy7 from comment #233)
> Can I ask what's holding this bug back from landing?

Not sure, but I note that "mostly unavailable until August" changed to "mostly unavailable until September", I think.

    
    

    
  
(In reply to alex from comment #232)
> The problem with Ctrl+n,t,w is, that they don't allow you to escape

Then do nothing, and the proposed patch will not affect you at all.

    
    

    
  


  
This is updated patch that changes the preference name to match the pattern of those added by bug 1379560.

        Attachment #8834536 -
        Attachment is obsolete: true

    
    

    
  


  
This patch is similar. One thing I'm not sure I like is using a general flag to indicate if the customization is done or not (ui.key.customizedBlockShortcutKeys) It is used as an optimization to avoid checking the permissions every key event but means you would need to set both preferences if you didn't go through the UI. Maybe it isn't needed?

Felipe, I know you reviewed this a while back but I changed it enough that I think another glance would be good.

        Attachment #8922053 -
        Flags: review?(felipc)

    
  

        Attachment #8922053 -
        Attachment description: Part 2.2 - add site permission to block override keyboard shortcuts → Part 2.3 - add site permission to block override keyboard shortcuts

    
  

        Attachment #8836749 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Part 3 - move reserved check into ContentUtils (obsolete) (deleted)
        — 
          — Splinter Review
      

    


  

        Attachment #8832875 -
        Attachment is obsolete: true

        Attachment #8922056 -
        Flags: review?(felipc)

    
    

    
  


  
The test still fails on some Windows so I'll continue to investigate that.

        Attachment #8832878 -
        Attachment is obsolete: true

        Attachment #8922057 -
        Flags: review?(masayuki)

    
    

    
  
Comment on attachment 8922050 [details] [diff] [review]
Part 1.3 - add preference to prevent pages from overriding keyboard shortcuts

Although, I didn't receive request of review for this...

>diff --git a/dom/xbl/nsXBLPrototypeHandler.h b/dom/xbl/nsXBLPrototypeHandler.h
>--- a/dom/xbl/nsXBLPrototypeHandler.h
>+++ b/dom/xbl/nsXBLPrototypeHandler.h
>@@ -50,16 +50,24 @@ class KeyboardShortcut;
> #define NS_HANDLER_TYPE_SYSTEM              (1 << 6)
> #define NS_HANDLER_TYPE_PREVENTDEFAULT      (1 << 7)
> 
> // XXX Use nsIDOMEvent:: codes?
> #define NS_PHASE_CAPTURING          1
> #define NS_PHASE_TARGET             2
> #define NS_PHASE_BUBBLING           3
> 
>+// Values of the reserved attribute. When unset, the default value depends on
>+// the permissions.default.shortcuts preference.
>+enum XBLReservedKey : uint8_t {

nit: put the { to the next line.

>@@ -720,17 +728,22 @@ nsXBLWindowKeyHandler::WalkHandlersAndEx
>     // Before executing this handler, check that it's not disabled,
>     // and that it has something to do (oncommand of the <key> or its
>     // <command> is non-empty).
>     nsCOMPtr<Element> commandElement;
>     if (!GetElementForHandler(handler, getter_AddRefs(commandElement))) {
>       continue;
>     }
> 
>-    bool isReserved = handler->GetIsReserved();
>+    bool isReserved = handler->GetIsReserved() == XBLReservedKey_True;
>+    if (handler->GetIsReserved() == XBLReservedKey_Unset &&
>+        Preferences::GetInt("permissions.default.shortcuts") == 2) {

This kind of code is what we're getting rid of. Preferences::Get*() needs cost of accessing hashtable. It shouldn't be used a lot of times but this may meet a lot in a session. So, I think that we should cache this with Preferences::AddIntVarCache.

    
    

    
  
Ah, and so "ui.key.customizedBlockShortcutKeys".

    
    

    
  
Comment on attachment 8922057 [details] [diff] [review]
Part 4.2 - menu accesskeys should check for shortcut override permissions

>+// This test checks that Alt+<key> and F10 cannot be blocked when the preference is set.
>+if (navigator.platform.indexOf("Mac") == -1) {
>+  add_task(async function test_accesskeys_menus() {
>+    await new Promise(resolve => {
>+      SpecialPowers.pushPrefEnv({"set": [["permissions.default.shortcuts", 2],
>+                                         ["ui.key.customizedBlockShortcutKeys", true]]}, resolve);
>+    });
>+
>+    const uri = "data:text/html,<body onkeydown='if (event.key == \"H\" || event.key == \"F10\") event.preventDefault();'>";
>+    let tab1 = await BrowserTestUtils.openNewForegroundTab(gBrowser, uri);
>+
>+    // Pressing Alt+H should open the Help menu.
>+    let helpPopup = document.getElementById("menu_HelpPopup");
>+    let popupShown = BrowserTestUtils.waitForEvent(helpPopup, "popupshown");
>+    EventUtils.synthesizeKey("VK_ALT", { type: "keydown" });
>+    EventUtils.synthesizeKey("H", { altKey: true });
>+    EventUtils.synthesizeKey("VK_ALT", { type: "keyup" });

I wonder, doesn't just a call of |EventUtils.synthesizeKey("H", { altKey: true });| fire Alt keydown/keyup too? IIRC, I implemented the test API so.

>diff --git a/layout/xul/nsMenuBarListener.cpp b/layout/xul/nsMenuBarListener.cpp
>--- a/layout/xul/nsMenuBarListener.cpp
>+++ b/layout/xul/nsMenuBarListener.cpp
>@@ -271,66 +271,27 @@ nsMenuBarListener::KeyPress(nsIDOMEvent*
>     // the mozaccesskeynotfound event before handling accesskeys.
>     WidgetKeyboardEvent* nativeKeyEvent =
>       aKeyEvent->WidgetEventPtr()->AsKeyboardEvent();
>     if (!nativeKeyEvent) {
>       return NS_OK;
>     }
> 
>     nsCOMPtr<nsIDOMKeyEvent> keyEvent = do_QueryInterface(aKeyEvent);
>-    uint32_t keyCode, charCode;
>+    uint32_t keyCode;

I believe that nsMenuBarListener should retrieve WidgetKeyboardEvent first and each utility method should take it instead of nsIDOM*Event. However, it's okay to keep current code. I'd like to rewrite with WidgetKeyboardEvent in a lot of places.

> #ifndef XP_MACOSX
>-    // Also need to handle F10 specially on Non-Mac platform.
>-    else if (nativeKeyEvent->mMessage == eKeyPress && keyCode == NS_VK_F10) {
>+    // Need to handle F10 specially on Non-Mac platform.
>+    if (nativeKeyEvent->mMessage == eKeyPress && keyCode == NS_VK_F10) {
>       if ((GetModifiersForAccessKey(keyEvent) & ~MODIFIER_CONTROL) == 0) {
>         // If the keyboard event should activate the menubar and will be
>         // sent to a remote process, it should be executed with reply
>         // event from the focused remote process.  Note that if the menubar
>         // is active, the event is already marked as "stop cross
>         // process dispatching".  So, in that case, this won't wait
>         // reply from the remote content.
>         if (nativeKeyEvent->WillBeSentToRemoteProcess()) {
>@@ -347,18 +308,45 @@ nsMenuBarListener::KeyPress(nsIDOMEvent*
> #ifdef MOZ_WIDGET_GTK
>           // In GTK, this also opens the first menu.
>           mMenuBarFrame->GetCurrentMenuItem()->OpenMenu(true);
> #endif
>           aKeyEvent->StopPropagation();
>           aKeyEvent->PreventDefault();
>         }
>       }
>+    } else

If you return with NS_OK before |else|, you don't need this else block and can save the indent level.

>+#endif // !XP_MACOSX
>+    {
>+      nsMenuFrame* result = GetMenuForKeyEvent(keyEvent);
>+      if (result) {

And same here, you can return if result is nullptr.

> ////////////////////////////////////////////////////////////////////////
> nsresult
> nsMenuBarListener::KeyDown(nsIDOMEvent* aKeyEvent)
> {
>   InitAccessKey();
> 
>   //handlers shouldn't be triggered by non-trusted events.
>   bool trustedEvent = false;
>   if (aKeyEvent) {
>     aKeyEvent->GetIsTrusted(&trustedEvent);
>   }
> 
>   if (!trustedEvent)
>     return NS_OK;
> 
>+  nsCOMPtr<nsIDOMKeyEvent> keyEvent = do_QueryInterface(aKeyEvent);
>+  uint32_t theChar;
>+  keyEvent->GetKeyCode(&theChar);
>+
>+#ifndef XP_MACOSX
>+  if (!mAccessKeyDown) {
>+    if (theChar == NS_VK_F10) {
>+      if ((GetModifiersForAccessKey(keyEvent) & ~MODIFIER_CONTROL) == 0) {

Well, I don't understand why you nested all |if|s here. Why don't you use |&&| instead?


You said, this patch still doesn't pass some tests. So, perhaps, I should review this again later.

        Attachment #8922057 -
        Flags: review?(masayuki) → review-

    
    

    
  
> This kind of code is what we're getting rid of. Preferences::Get*() needs
> cost of accessing hashtable. It shouldn't be used a lot of times but this
> may meet a lot in a session. So, I think that we should cache this with
> Preferences::AddIntVarCache.

Did you still want me to add this? I could add this just for 'ui.key.customizedBlockShortcutKeys'.


> I wonder, doesn't just a call of |EventUtils.synthesizeKey("H", { altKey:
> true });| fire Alt keydown/keyup too? IIRC, I implemented the test API so.

I expected it to work but did not on Linux. I will investigate some more.


> I believe that nsMenuBarListener should retrieve WidgetKeyboardEvent first
> and each utility method should take it instead of nsIDOM*Event. However,
> it's okay to keep current code. I'd like to rewrite with WidgetKeyboardEvent
> in a lot of places.

I thought about changing all of the menubar code here to use WidgetKeyboardEvent but felt it was too large of a project that could be done separately.

    
    

    
  
Doing:

EventUtils.synthesizeKey("H", { altKey: true });

doesn't fire the altkey down/up. The flag KEY_DONT_DISPATCH_MODIFIER_KEY_EVENT is passed to the TextInputProcessor. So I emulate this here in this test.

    
    

    
  
(In reply to Neil Deakin from comment #243)
> > This kind of code is what we're getting rid of. Preferences::Get*() needs
> > cost of accessing hashtable. It shouldn't be used a lot of times but this
> > may meet a lot in a session. So, I think that we should cache this with
> > Preferences::AddIntVarCache.
> 
> Did you still want me to add this? I could add this just for
> 'ui.key.customizedBlockShortcutKeys'.

Yes, I think so.

|handler->GetIsReserved() == XBLReservedKey_Unset| is almost always true. Then, each key press which matches one of shortcut keys wastes 1~2 msec of the main tread of the main process.

(In reply to Neil Deakin from comment #244)
> Doing:
> 
> EventUtils.synthesizeKey("H", { altKey: true });
> 
> doesn't fire the altkey down/up. The flag
> KEY_DONT_DISPATCH_MODIFIER_KEY_EVENT is passed to the TextInputProcessor. So
> I emulate this here in this test.

Ah, okay. I checked EventUtils again. My memory is just wrong.

        Attachment #8922053 -
        Flags: review?(felipc) → review+

    
    

    
  
Comment on attachment 8922056 [details] [diff] [review]
Part 3 - move reserved check into ContentUtils

># HG changeset patch
> nsXBLWindowKeyHandler::IsReservedKey(WidgetKeyboardEvent* aKeyEvent,
>                                      nsXBLPrototypeHandler* aHandler)
> {
>   XBLReservedKey reserved = aHandler->GetIsReserved();
>+  if (reserved == XBLReservedKey_False) {
>+    return false;
>+  }
>+

I don't recall this exactly, but does also avoid doing the check for keyboard combinations that do not have any reserved keys? Meaning that we will only do the full check for key combinations, with Ctrl, Cmd, Alt, etc.? (that is, not for plain letters kepresses?)

If yes, I wonder if the gate pref is necessary at all (but it certainly is a nice addition)

If no, I think we should find a way to do this. Even only for users with the pref set, checking it even for simple keystrokes is probably too much

        Attachment #8922056 -
        Flags: review?(felipc) → review+

    
    

    
  
For shortcuts, it filters out non-matching <key>s first and then will only get called when you press that key. So you need to press accel+F for example. It checks for both keydown and keypress however. For accesskeys, it matches when alt+letter matching a menu label is pressed.

So I agree that the extra preference used for optimization is probably not necessary. I'll remove it. Thanks for having me look at it in more detail so I can simplify here!

    
    

    
  


  
This addresses comments.

        Attachment #8922050 -
        Attachment is obsolete: true

    
    

    
  


  
This mostly just removes the unneeded preference for optimization.

        Attachment #8925595 -
        Flags: review?(felipc)

    
    

    
  


  

        Attachment #8922053 -
        Attachment is obsolete: true

        Attachment #8922056 -
        Attachment is obsolete: true

    
    

    
  


  
This patch fixes two issues:
 1. Fixes Windows failure described earlier which was actually just a non-e10s failure. The content was cancelling the event yet a system event listener is being used here which runs afterwards. Instead I add a capturing listener that runs similar code which always runs before content in multiprocess or single process mode.
 2. Fixes a crash in the browser_urlbarAddonIframe.js test. This test is firing a CustomEvent with the name 'keydown' so I add a check to handle this in nsMenuBarListener::KeyDown.

        Attachment #8925601 -
        Flags: review?(masayuki)

        Attachment #8925595 -
        Flags: review?(felipc) → review+

    
    

    
  
Oops, sorry for the delay to review. I'll review it today or tomorrow.

    
    

    
  
Comment on attachment 8925601 [details] [diff] [review]
Part 4.3 - menu accesskeys should check for shortcut override permissions

>diff --git a/layout/xul/nsMenuBarListener.cpp b/layout/xul/nsMenuBarListener.cpp
>--- a/layout/xul/nsMenuBarListener.cpp
>+++ b/layout/xul/nsMenuBarListener.cpp
>@@ -56,16 +56,20 @@ nsMenuBarListener::nsMenuBarListener(nsM
> 
>   mEventTarget->AddSystemEventListener(NS_LITERAL_STRING("keypress"),
>                                        this, false);
>   mEventTarget->AddSystemEventListener(NS_LITERAL_STRING("keydown"),
>                                        this, false);
>   mEventTarget->AddSystemEventListener(NS_LITERAL_STRING("keyup"), this, false);
>   mEventTarget->AddSystemEventListener(NS_LITERAL_STRING("mozaccesskeynotfound"),
>                                        this, false);
>+  // Need a capturing event listener if the user has blocked pages from overriding
>+  // system keys so that we can prevent menu accesskeys from being cancelled.
>+  mEventTarget->AddEventListener(NS_LITERAL_STRING("keydown"),
>+                                       this, true);

nit: odd indent. Please start below "N" of "NS_LITERAL_STRING".

>@@ -348,18 +315,48 @@ nsMenuBarListener::KeyPress(nsIDOMEvent*
> #ifdef MOZ_WIDGET_GTK
>           // In GTK, this also opens the first menu.
>           mMenuBarFrame->GetCurrentMenuItem()->OpenMenu(true);
> #endif
>           aKeyEvent->StopPropagation();
>           aKeyEvent->PreventDefault();
>         }
>       }
>+
>+      return NS_OK;
>     }
> #endif // !XP_MACOSX
>+
>+    nsMenuFrame* result = GetMenuForKeyEvent(keyEvent);

nit: |menuFrame|, |menuFrameForKey| or something is better. |result| is really ambiguous.

> nsresult
> nsMenuBarListener::KeyDown(nsIDOMEvent* aKeyEvent)
> {
>   InitAccessKey();
> 
>   //handlers shouldn't be triggered by non-trusted events.
>   bool trustedEvent = false;
>   if (aKeyEvent) {
>     aKeyEvent->GetIsTrusted(&trustedEvent);
>   }
> 
>   if (!trustedEvent)
>     return NS_OK;
> 
>+  nsCOMPtr<nsIDOMKeyEvent> keyEvent = do_QueryInterface(aKeyEvent);
>+  if (!keyEvent)
>+    return NS_OK;

nit: put {} for this line.

        Attachment #8925601 -
        Flags: review?(masayuki) → review+

    
    

    
  
Pushed by neil@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/814806beaaf8
add a general preference to prevent pages from overriding keyboard shortcuts. If a key doesn't specify the reserved attribute, this preference will be used, r=felipe
https://hg.mozilla.org/integration/mozilla-inbound/rev/b65525d75c01
add site-specific permissions to prevent pages from overriding keyboard shortcuts. This is done by preventing the key combination from being sent to the content page, r=felipe
https://hg.mozilla.org/integration/mozilla-inbound/rev/3a4fbb2ae022
move reserved key checking into ContentUtils so that it can be shared with menu accesskey checks , r=felipe
https://hg.mozilla.org/integration/mozilla-inbound/rev/a812659b1aa8
when an Alt+accesskey for a menubar menu is pressed, check if the user has blocked sites from overriding keyboard shortcuts, and don't send the event to the page if so. Add a similar check for the F10 key which focuses the menubar. An additional capturing keydown listener is added because the key needs to be blocked before content sees it. r=masayuki

    
    

    
  
If I understand correctly the default is going to be for pages to be /allowed/ to capture keystrokes?  With an override button per site?

Now that a decision on the issue has been taken, I wonder if the spirit of that decision will be made to extend to capturing mouse buttons, or a bit more general, modifying the expected behaviour of any input device and perhaps even output device.

I think such thinking was briefly mentioned in comment 169.

In other words, will an effort be made to extend this decision to all input and output devices: will webpages by default be allowed to modify the behaviour of any input and output device?

This would for example be very beneficial to designers of internet banking sites that want to work with facial recognition, as it would enable them to employ that functionality without having to annoy the user with asking for it.

    
    

    
  
An unintended consequence with this change seems to be that Backspace cannot be used to delete text even in native elements like textarea.

    
    

    
  
It also blocks Delete ... but Ctrl+Backspace and Ctrl+Delete both work fine.

Incidentally, what's the proper way to set the default state of blocking? I could only find the per-site preferences in Page Info -> Permissions.

    
    

    
  
Alright, so the case of preventing web pages from grabbing stuff seems to be fixed now. But I can't see where the inverse got handled, *allowing* web pages to grab stuff. Many requests were for that as well, including core bindings such as Ctrl+W. This is supported by Chrome now so Firefox should make sure they keep parity.

    
  
Depends on: 1455101

    
    

    
  
Wow, just realized that this bug I opened a while ago is now resolved. Thanks to everyone who contributed to the discussion over the years!

    
    

    
  
Is this just for backspace/delete?  I'd like the same feature but for / (which I tap for search in page, but github wants to search all of github).

    
    

    
  
Paul Bone, see 1455101.

    
    

    
  
The list of blocked keys really needs to be configurable. The user should be able to control his web browser.

    
    

    
  
I think this should also address web pages hijacking scrolling (like Google Maps, and like many pages which impose smooth scrolling) and hijacking page up/page down (like the Internet Archive has now started). This can screw with the ability to navigate web pages, and when it triggers animatons such as zooming and smooth scrolling, this can trigger migraines.

    
    

    
  
Maybe this should be augmented by a zoom-webapi, which could be separate from website zoom? So a mobile device could decide to zoom the webpage on the gesture and display +/- buttons for map zooming, a desktop device could provide an indicator about the zoom level in the UI (e.g. "map-zoom 1:1000" or "image zoomed 2.5x")

And for scrolling I absolutely agree. I always disable smooth scrolling, because it behaves different than you would expect from the mouse wheel. When then a site re-implements it, it is really annoying behavior.

+1 for a control panel of blocked keys. And blocking all ui-keys by default. As a website should not be able to alter the browser above the content area, it should not be able to intercept ui keys. Imagine a website hijacking ctrl-f and then displaying a search bar which looks exactly like the firefox ui.
Or hijacking ctrl-l and then jumping to a fake url-bar in fullscreen mode.

    
    

    
  
(In reply to Vincent Lefevre from comment #264)
> The list of blocked keys really needs to be configurable. The user should be
> able to control his web browser.

Right, I tried changing the existing setting for github so I could have '/' to do in page search like it does by default, but that broke backspace!

    
    

    
  
(In reply to MarjaE from comment #265)
> I think this should also address web pages hijacking scrolling (like Google
> Maps, and like many pages which impose smooth scrolling) and hijacking page
> up/page down (like the Internet Archive has now started). This can screw
> with the ability to navigate web pages, and when it triggers animatons such
> as zooming and smooth scrolling, this can trigger migraines.

There's a site I use to see pictures of my son while he's at daycare.  It overrides scrolling or page down or something, but it doesn't take into account any zoom or font settings I have in the browser, so the photos always end up unalligned with the pagination the site performs.  It'd be better just to use the browser's scrolling on this site.
Component: Event Handling → User events and focus handling
Depends on: 1608457

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: