Get bug of UNCO list since there seems to be an issue here...

This is _really_ bad IMHO, users can't do anything with a keyboard on a page like that, and context menu doesn't work regardless of user choice... Ctrl-W, Alt-F4, Ctrl-Tab, etc. all don't work.

Not appropriate to "block" a branch security fix release for an old bug like this. Even if we had a trunk fix it may not be appropriate to take on the branch because it may cause some legitimate pages to stop working, and on the branch we couldn't add any UI to let users override the defaults.

Yeah, this is pretty bad, but I'm not holding the release on this old bug.

Not blocking the first alpha on this. Smaug, we should decide one way or another here for beta1 IMO.

With all the problems users have with plugins stealing keyboard shortcuts, this bug is actually being considered? See bug 78414 for background information if you're not familiar with what I'm referring to.

Not blocking on this after all, while it does seem important to fix this it's not critical to fix it for 4.0 IMO.

Smaug, any reason that patch can't be taken? Would be real sweet to fix this bug, it's probably the most power given to any web author yet (consider a mouse-less user, I don't think there's any good way for him to get out of the trap in the url field, aside from killing the process via ctrl-shift-esc).

I like that whiteboard. A way to please everyone. An app tab where you put the Web page you trust, where she has special rights. And in normal tab, I keep control over the Web page.

There's no way for a web developer to know which keybindings are in use by each browser. CTRL+S might be save, but on the Mac OS X, it is Command+S, unless the user has gone into their system keyboard preferences and mapped it to something else. Something related would be to allow webpages to intercept "Refresh". Not just the keybinding(s), but the action in general, including if the user presses the "Refresh" button on the toolbar. The way that browsers refresh by default is very inefficient and many web pages can do it more efficiently (e.g., refreshing your gmail inbox).

Oops, I suppose it's called "Reload" by the browser, although if the webpage handled it it would be more of a refresh than a reload.

Many websites or webapps(for example twitter website) hijack the keyboard strokes as keyboard shortcuts in their web page. And in many cases some of the shortcuts conflict with the system-based keyboard shortcuts. Since firefox enable user to "disable javascript to hijack context menu" at: Tools/Options/Content/Enable Javascript Advanced/Disable or replace context menus Why don't you add the feature to "disable javascript to hijack keyboard shortcuts"? Just a checkbox at: Tools/Options/Content/Enable Javascript Advanced/Catch keyboard events

(In reply to diyism from comment #56) > Why don't you add the feature to "disable javascript to hijack keyboard > shortcuts"? Just a checkbox at: > Tools/Options/Content/Enable Javascript Advanced/Catch keyboard events I support this! Also being a fan of key binding customisation (emacs rules ;-)), I'd like to be able to remap any key binding...

I do agree that allowing the user to regain control is becoming increasingly important as web developers increasingly hijack standard browser keys without regard for usability implications. My personal pet peeve is replacing / (find as you type) with focusing a search box, which is not at all the same thing and is completely wrong. We can't just say “we'll just have to leave it up to web developers to be responsible,” because they won't! A preference (even a hidden one) to prevent keyboard events, or even to allow catching of keyboard events as long as they don't override an already-taken key would be very welcome. Ideally one would be able to have finer-grained control over the process, but that would probably be best left to an extension. But having a simple built-in global preference along with the others in Javascript advanced settings would really make sense, IMO.

Now I encounter a weird variant of the bug, on Win Vista, in Firefox 14.0.1, on the page http://fr.scribd.com/doc/120088889/Communique-de-presse-manifestation-du-dimanche-13-janvier-2013 , when I press Ctrl F. Instead of getting the Firefox search, I get the page's search.

That's not so much "a weird variant of the bug" as it is "this bug exactly". :) (I see the same behavior in Nightly, ver 21.0a1, FWIW)

I've just logged a bug where some sites overwrite browser's keyboard shortcuts and someone there pointed out to this issue/feature. So I put my comment to this behaviour unfortunately there: https://bugzilla.mozilla.org/show_bug.cgi?id=933470#c3

Ctrl+0 (reset zoom) is overridden by a YouTube embed to go to the start of the video.

I'd vote for a customizeable (dynamic) list of shortcuts, too. BTW, this would also help users using non-qwerty layouts (one of whom am I). Also, I'm just a user, not ff-developer..

(In reply to Vasya Novikov from comment #84) > I'd vote for a customizeable (dynamic) list of shortcuts, too. BTW, this > would also help users using non-qwerty layouts (one of whom am I). I didn't think of this. You're right, the list of reserved sequences should be different with other OS languages. Can you please save the following to a .html file, open it in Chrome or Chromium, and tell us if the browser prevents the page from trapping the keystroke combinations used in your language to: 1. Select all, 2. Save page, 3. Close tab? In Firefox this blocks everything. <html><head><title>Keypress trap test</title></head> <body onkeypress="return false;" onkeydown="return false;"><h3> This page contains JavaScript that attempts to trap all keypresses. If your browser indiscriminately allows Ctrl-sequences like Ctrl+W to be trapped by JavaScript, you will be unable to use them to close this window or navigate away from it. </h3></body></html>

Whenever a site attempts access, perhaps an "allow this site to override browser controls?" prompt (with a whitelist similar to the plugins implementation). I absolutely agree that sites should never be able to override browser controls by default.

(In reply to Paul from comment #88) > 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. Mmh, shouldn't it be the other way around? I mean Mozilla can and should do better than Google -- in a way, this discussion already proves it ;-) But, I guess that might be acceptable as a temporary... hack, while crafting a better solution.

Ctrl+Shift+P doesn't work when signed in at https://mail.yahoo.com/ on Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0 ID:20140320030203 CSet: e84a391b604b

Google has recently taken over Ctrl-Page Up/Down in Google+, further heightening the need for a way to override this behaviour. It severely limits my usability of the browser, requiring me to use the mouse merely to switch to another tab, and stops me in my tracks if I'm switching over multiple tabs and come across one that happens to be Google+.

I, too hold a similar state of frustration to others here. The behind the scene key bind/map update ability becomes a means to an end of user control via vendors that are trying to mandate user behavior as far making us actually be exposed to the commercials that have been placed into stream program content. More prevalent with the "free" access mode, but certainly not limited to it. Thus, a threshold was recently surpassed as I view streamed programs, and the ability go to another tab to do something, during commercials, or escape out of the browser all together has been taken from me, then the time has come! (Try watching a movie at crackle.com or a 'TV' program at abc.com, or nbc.com). Quite frustrating. And, I have the same request that was made in Comment 75. What is the URI to script which "enables customization of overrides per particular url or simply disabling all sites to never override"? The browser is mine!!!!!!!!!!! I am the master of it, irregardless! Unless I have specifically allowed a particular action such as a remap then I want a solution to regain control. When a blinking vendor thinks that it's ok to go behind the back of the browser owner, and subvert their wishes, then 99% of the time it's because they are intent on doing something with which the user does not agree! Thus, the proposal that was discussed in comment 76 ("adding a check box next to the javascript options in Settings for allowing/preventing sites from hooking a keystroke") holds more promise as a working solution. Yes, there really needs to be 'untouchables', especially one which gives back keyboard control to the OWNER/USER of the browser. But, it makes alot more sense not to let the behind the scenes override to be allowed in the first place! As "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?" (comment 90) I'd have to say that the ability to override should absolutely be placed into the purview of the user; thus, should they not be viewed with a whole different set of respect? i.e. Shouldn't the ability to update/remap behind the scenes involve some form of encryption at the UI level before such adjustments can be attempted? Unless the user has stipulated/agreed to adjustments then they should NOT BE allowed to transpire. Period! Thus, a dual-mode update solution, similar to a 'vi insert mode', that would allow firefox to keep all the browser combinations safe (re: comment 93), and which requires the encryption key before access to update mode is starting to make a whole lot of sense, don't you think? Because, "we need some API which exposes all the reserved keyboard shortcuts to web apps." (comment 36) this becomes quite reasonable, once their ability to be changed HAD TO BE reviewed, and approved, by the user. i.e. readonly availability, until/unless change approved.

I agree with both the usability and security concerns--usability in the sense that as long as web pages can override shortcuts, it becomes completely unpredictable what will happen when any key shortcut is pressed in the browser, and security because it may become possible for a page to hijack a shortcut and fool a user into entering sensitive data in a non-chrome widget. Not to mention the annoyance of pages that replace useful functions with completely unrelated, useless ones (e.g., replacing / for “find in page” with focusing a search box which has nothing to do with searching within a page--and it's sad that this particular thing has become almost universal now). By the way, I once looked into CAPS as a workaround (revoke access to registering shortcuts), but unfortunately CAPS is nearly useless because IIRC it throws exceptions when a script attempts to perform a restricted action, which pretty much *breaks* most sites I've tried it on. It would have been much more useful if it could be configured to instead appear to perform the action from the script's point of view, without actually doing so. After all, scripts generally aren't going to have their own exception handling on operations that don't normally throw exceptions.

Hi all, I want to add some "process comment" if you will to this bug. I tried to find if that is frowned upon in this bug database or not, but could not find, so I will just do it. This bug is now over 7 years old. It is about web pages overriding (stealing, hijacking) browser shortcuts. Sounds pretty serious to me. And it is. I can not see this as anything else than "programming evil"; "lower" SW layers should not steal from "higher" SW layers. The OS does not redefine the on/off button to mean print, a Virtualbox VM does not redefine right CTRL to mean Change Wallpaper, a browser must not redefine PrintScreen. And just as well, web pages should not redefine any of the shortcuts defined higher up in the hierarchy. The only exception should be when the system owner expressly allows it. As I see it, webpages want to do this for two reasons: by the misguided but alas already mainstream thinking that webpages can or should be general GUIs for interactive programs, or because they want to restrict the owner of the system doing things that the owners have the right to do (they are, after all, owner of the system!). Now I can understand the practical issue with suddenly taking away shortcuts from webpages that steal and have been using shortcuts to good effect for a long time already. But even so it is still "evil" by the above description; it should first be expressly allowed by the owner. The logical way out is to offer configurable option to the owner of the system. ANY option. The implementation of course does matter, but the importance of how to implement it _absolutely pales_ in comparison with the importance of actually solving this, in whatever way. We really should get rid of the situation where right-click does what the webpage says it should do (shutdown the system, haha?), instead of the standard actions as defined by the browser, and as therefore rightfully expected and demanded by the owner. As remarked before, this bug is now old, not even six, but SEVEN YEARS OLD. I have been subscribed to this bug for quite a while, I have seen discussions on if and how to solve it come and go, but it all doesn't matter. How can a bug that so obviously must be solved quickly, and for which a sufficient number of simple and possible resolutions have been proposed grow THIS old without action? I do not believe in it anymore, I will wait a while for any more comments, but I believe nothing will happen, and I think later on I will unsubscribe from this bug and just continue to suffer. Suffer from a browser that is as a whole quite good, but still allows web pages to abuse me, as the owner of my system, by taking away "save image as..." and other standard browser functions from the right-click menu. Cheers :)

Peanut gallery observation: We could always ask keyboard manufacturers to add a web-meta key... :)

@all: - Please visit https://bugzilla.mozilla.org/page.cgi?id=voting/user.html&bug_id=380637#vote_380637 - click the check box there - and confirm that vote with 'change my votes' ...so that this issue finally becomes important enough to be fixed :)

(In reply to sku1d from comment #107) > @all: > - Please visit > https://bugzilla.mozilla.org/page.cgi?id=voting/user. > html&bug_id=380637#vote_380637 > - click the check box there > - and confirm that vote with 'change my votes' > > ...so that this issue finally becomes important enough to be fixed :) Oh thanks, didn't know! Who the **** thought of NOT putting that vote option in the actual bug page? :D Maybe that will offer a glimmer of hope,, I voted already...

That's off-topic and the button to change votes _is_ on this page.

There is widespread discontent (among keyboard users, anyway) over this keyboard shortcut hijacking behavior. See for instance: https://news.ycombinator.com/item?id=3092100 It's a genuine issue, though, with two valid sides. There's good reason to allow page-content pseudo-apps to define their own keyboard shortcuts; see, f.i.: https://code.google.com/p/chromium/issues/detail?id=33056 (primarily web-app programmers; includes assertions such as "Chromium and Chromium OS's goal to allow for a desktop-like experience in web-based applications" and "Chrome has no right to override a web app."). Other groups have given this some good, careful thought; see the Chrome devs' discussion here, e.g.: https://code.google.com/p/chromium/issues/detail?id=5496 (discussion is framed within a different context, but well worth the read) --- The problem seems to be that before, web browsers were web browsing applications, and spreadsheet editors, video players, and games (etc.) were separate applications for their own unique functions. Now web browsers are becoming both applications and application-containers for the spreadsheet, video, and game pseudo-applications running within them. That forces the question of which "application" should own the keyboard shortcuts. No wonder there's a clash here. It's a problem inherent in the evolving nature of software - and apparently a problem of one application (the browser) trying to be too many things at once. This issue is touched on by sphakla in comment #83. Ideally, some kind of sub-container solution would seem optimal. Have a main web browser, whose primary function is focused on traditional website interaction (i.e., to _browse_ the _web_), but have it launch a separate window / process - essentially a different container - for web-applications: for those websites whose content functions primarily as remote-served applications. An "App Mode" window or something. That would separate the two into their own domains / spaces, making the keyboard shortcut issue moot. (Hypothetical typical user: "So I can't CTRL+TAB between tabs in my YouTube / online-spreadsheet / Flash game window? I can't use CTRL+T to open a new tab? Well, okay; that's expected behavior for the 'App Browser.' But I'm still able to navigate web pages with CTRL+TAB normally in my 'Web Browser' window? Okay; everything's good, then!") ^^^ Absent such a solution, or at least while waiting for same: Because of the increasing ambiguity over the role of the web browser, it seems that that the best solution would be to implement a per-site permissions system, as Michael White suggested in comment #69. However, such a system would need to be disabled by default, so that power users can opt in for per-site control of keyboard shortcuts, and so the vast majority of users (non-power-users) will not be bothered, inconvenienced, or confused. [What bugs me most is that while using CTRL+TAB, a page pseudo-app will steal the focus and disable the tab-switching function of CTRL+TAB. What would make more sense to me is to allow the pseudo-app to usurp the keyboard shortcut _only_ when the pseudo-app has been selected explicitly by the user, either by mouse click or a specific navigation shortcut that toggles focus between the container (tab) and the contained (pseudo-app).] -K

I agree. Anything that adds additional HTML tags/data or API calls to JavaScript to handle shortcuts or a new sub-container window system would need to be thoroughly discussed and planned out in a full RFC. It seems that the next steps to begin to resolve this issue are to consolidate this issue's list of suggestions and concerns, combine that with other ideas and research done around this and similar topics and turn that into an RFC for the entire web community. I don't think anyone involved in this thread expects a 6 month turn-around either. Anything that is big enough to remain open for seven years is not a task to be undertaken lightly. At the same time, if no one ever tries to implement a solution we won't even have a chance to improve upon a first try implementation. Software is all about starting somewhere even if it isn't perfect and then moving forward from there.

Note that web-apps may also be broken by extensions, user styles, blocked font download, etc., not just by keyboard shortcuts used by the browser. So, if a web-app / sub-container window system is defined, the whole browser environment should be considered, not just the keyboard.

I'm glad the discussion here seems to have moved away from "reserve a few non-bindable keys" to a broader approach. "App Mode" and "Browser Mode" is an apt distinction. I know that, even in the last few months, more and more sites are hijacking even the arrow keys and page-up/page-down, which totally destroy expected navigation. Some sites that used to have their own opt-out of the hijack no longer have that (Duck Duck Go, for instance) unless you again revert to disabling all JavaScript. This has been demonstrated in all the discussion above to be an important, critical bug to work out, from all fronts: user expectations, privacy, security and so on. I can't believe there's not been anything official to fixing it yet in all this time.

This doesn't need a spec. Many posts have been approaching things from the wrong perspective. Compare it to the a more benign example: Was there a spec for "block popup Windows" before that was implemented? It also seems that some people are inappropriately interpreting this as a "feature request". It's not. It's a core usability problem. It's a giant user annoyance. It's a security hazard. And has it been reviewed by the accessibility team? It's certainly an accessibility issue.

It's not quite as benign as the example you provided *. Also that specific case could have used a bit of a better API in my opinion. The popup blocked behavior implemented by the browser is not always very obvious and to this day there are times that things trigger that popup blocker when it should not trigger. Allowing the site to know that a popup was blocked would allow the site itself to alter its behavior to account for this. * See my soon to be posted reply to comment 129

Dialog, analogous to geolocation information requests: "This site wants to create keyboard shortcuts. [permit] [decline] [see more details]" Where see more details shows precise what it wants to do. There's zero reason to let the site know whether or not its requests for keybinding were allowed by the user.

What the heck is this talk about creating a spec before doing anything about this? This just sounds like you are trying to avoid the issue. Block a website from stealing shortcuts or not. If you want to make a separate spec for some workaround that isn't flash/java (what a lot of developers had done before going the HTML/javascript route), go ahead and do that, but that should be separate from a simple block this or all websites option. The interface for this doesn't have to be more complex than what we already have for blocking cookies. I'm tired of going to a website where I down-arrow intending to move the page down a line or two just to have it open a messaging page and pressing page-down opens the next chronological article. Dealing with each an every developer's personal preference for website UI (instead of our own) is fracturing the UI for everyone. It **** people off to no end when they are filling out a long form, but the wrong keypress that they didn't know the developer had hooked reloads the page or loads another page... all that time wasted filling in that form is frustrating especially when it was some developer's arbitrary whim that screwed it all up. white: > I don't understand why you are so adamant that the > site cannot or should not know a boolean value saying I suspect some people would say "It's none of their GD business. Quit violating my fraking privacy." I'm agreeing with bobbuun's last comment (#136) on this one. white: > 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. \Oh great\! More pop-up floating divs to have to deal with. :( white: > Anything that adds additional HTML tags/data or API calls > to JavaScript to handle shortcuts or a new sub-container > window system would need to be thoroughly discussed and > planned out in a full RFC. That needs to be a separate issue from this bug. white: > 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. But, what about the users' experience when websites hooking all these keypresses screws their experience because they have no idea what keypress will arbitrarily blow everything up. It's getting to a point where the average *experienced* user is starting to feel like those old grandmothers afraid of computers because they are afraid of formatting or breaking the computer by accident. That ruins the entire internet experience, not just some one-off website. It would be better to create a consistent set of shortcuts to be used by all developers rather than them grabbing established keys for their own whims... *that* would need a new spec, but that should be completely separate issue from this bug. That issue is not this issue. The API idea is a separate issue from this bug's issue. Don't muddy the water or try to change the topic if you want this issue resolved sometime this next decade. ←("next decade" comment is a comment on how long it has taken for any progress in this bug). travis: > What if a site steals the arrow keys? I've already run into that, mentioned above, so I can vouch for your concern on that particular part of your statement being a real one. travis: > 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. I don't think anyone has suggested that the dialog had to show up every single time. In fact, doing so would suggest that the keypress has been hooked already, but the dialog is to prevent the hook. Once the user has said "don't allow hooks on this website" (if it is set to ask for each website) then that setting applies to the website. Why ask about the website if it does not apply to the website? With me, and cookies, I have it set to just deny for all websites by default. If I come across a website where I want cookies for it to be enabled, I then click a button to allow it to ask about this site wants to set a cookie, and I allow it permanently or just for this session. Once I make my choice, I switch back to denying everything automatically and I don't worry about again. I'm happy with that. With keypresses, we have no choice in the matter. The UI is hijacked and we are screwed at that point. travis: > 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. I think we are on similar pages on this.

General note: Even today most keyboard shortcuts like the arrow keys can be hijacked by the site if the developer wants to. This entire thread is discussion around how to allow the site/application to handle the few and ever-changing set of shortcuts normally trapped by the browser and never sent to the site at all. The application would still have the option to allow them to pass back up to the browser level just as it does for all other keyboard events that it currently can trap. Also keep in mind that one reason this is an issue is that different browsers trap different shortcuts and this would allow a site to keep its own shortcuts standard across different browsers. To achieve that, all browsers would need to have some way to allow this and that is why there has been a push to propose solutions to the W3C. travis: > 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. I agree that there should be a global setting to control this. I just do not see making this the only level of control being a feasible first step in resolving this issue. I think that if the global setting is on, there should be a list of sites that have requested use of it with a checkbox by each one so the user can uncheck to disable/disallow that site to have such control. I think this is very important because there will be power users that want many/most sites to have that control and then there will be that one site they go to where the developer made shortcuts that mess everything up. I don't think it is healthy for the web if that power user is not able to go disable the advanced shortcuts for that one site that is misbehaving. Providing only a simple on/off would penalize the sites that did it right and would penalize that advanced user by making them choose all or nothing. busi: > It would be better to create a consistent set of shortcuts to be used by all developers rather than them grabbing established keys for their own whims.. I would like to see your proposal for this one. ;) On general principle I don't believe that is feasible or advisable. There are far too many different types of software applications out there to make any single set of common shortcuts mean the same thing across all of them. This is something that a software designer/developer needs to use their expertise along with user feedback to decide on. Sure, that will mean people make poor choices for the shortcuts but it also lets them make really good ones too. Many games use W, A, S, D or other nearby variants for directional control. Left-handed mouse users generally switch it to the other side of the keyboard. While I believe the browser can trap all of those keys already I just want to point out that using letters for directional control is far from standard unless you're playing certain types of games. Beyond that, switching tools, weapons, vehicles, etc. are all things done by "random" shortcuts and in many desktop games you can reconfigure all of it to your own liking. Why should advanced applications built to run in a browser not be able to have the same level of keyboard access as their desktop counterparts? As a web based software developer, I do not see web applications as something entirely different from full desktop applications. I just view the browser as a rendering & execution platform for the web application software.

Actually, I see this thread as discussion about preventing this hijacking. Should we split this in two bugs, one security/accessibility bug to prevent the actual hijacking that is still happening, and another bug, a feature request to introduce a way in which web applications can introduce non-clashing key bindings?

Nuno: > Actually, I see this thread as discussion about preventing this hijacking. Sort of... Based on the original post I think it's more about how to allow it and then by necessity it morphed into the current discussion which is a bit more centered on how to go about allowing it without being overly burdensome on the user. The original post on this thread says: > 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 :-)

(In reply to Nuno Silva from comment #142) > Actually, I see this thread as discussion about preventing this hijacking. > > Should we split this in two bugs, one security/accessibility bug to prevent > the actual hijacking that is still happening, and another bug, a feature > request to introduce a way in which web applications can introduce > non-clashing key bindings? Most of us here seem to as well, with a few people focusing on the web developer side of it. Preventing the hijacking is a here-and-now fix that needs to be done. The feature request for web developers/getting a spec is something else, something for later. If you'll allow a little (but not much!) hyperbole, it's getting to the point where I can't browse the web with the keyboard at all; where I have to mouse 100% of the time.

Speaking of hijacking... It looks like this discussion thread has been hijacked from the original poster's request. This post was about allowing more keyboard access to developers, not less. However, to get right on point here: > Preventing the hijacking is a here-and-now fix that needs to be done. It is not a bug that allows this so-called "hijacking". The ability for the site to receive keystroke events for almost everything has been around for a long time. In recent years browsers have begun adding their own new shortcuts thus adding new "standard" behaviors that users have come to expect. It is no wonder that this has caused conflicts and issues. Countless existing sites and applications already leverage these long-existing keypress/keydown/keyup events and blocking all key events from reaching the site would break them all. If anyone is expecting this issue to be resolved simply by blocking all keystrokes from reaching the JavaScript layer of the site then they will likely be quite disappointed as that is not at all what this thread is about.

> Speaking of hijacking... It looks like this discussion thread has been hijacked from the original poster's request. More than what the OP intended, there have been at least two topics focused in this discussion here, that is why I proposed the split into two, separate bugs. Perhaps we should do that? > Countless existing sites and applications already leverage these long-existing keypress/keydown/keyup events and blocking all key events from reaching the site would break them all. Even nowadays, I'd guess that at least 90% of the sites I end up visiting define no keystrokes, or don't use javascript at all. In most sites that define keystrokes, but are not actually web applications, these keys are just shortcuts for things the user can already do in some other way. Only web applications, not web pages, will be greatly affected by a major block on shortcut hijacking. And even then, they can just try another keystrokes, instead of the ones that are used by commonly used web browsers. (I agree this won't be perfect, but it's still possible.) Even if Firefox allows this hijacking, we are still in a situation where the site has no guarantee that it will ever get the keystroke, as other things in the operating system or desktop environment may be handling these keystrokes with higher priority. > It is not a bug that allows this so-called "hijacking". I consider it a bug if an email flag is changed in a webmail interface because Firefox allows the site to hijack browser key combinations. (See the OWA example I mentioned waaay above.) I also consider it a bug if I can't reliably use the browser interface (what if control-Q sometimes does not quit the browser?). > If anyone is expecting this issue to be resolved simply by blocking all keystrokes from reaching the JavaScript layer of the site then they will likely be quite disappointed as that is not at all what this thread is about. Preventing the hijacking is not the same as blocking all the keystrokes. Preventing the hijacking means that the javascript layer won't get stuff like Control+Q, when that is a keystroke used by the Firefox UI. But nothing would need to be done about keystrokes that are *not* used by the UI.

> Preventing the hijacking is not the same as blocking all the keystrokes. Preventing the hijacking means > that the javascript layer won't get stuff like Control+Q, That clarifies things a bit. However, the browser already prevents some of these from passing down to the site - or at least it did when this topic began. The reason for this topic was to request functionality in the browser that would allow the site to receive more of those currently trapped shortcuts. If the browser is not trapping enough of them from the perspective of the average user that seems like that is in fact a separate issue from this one and should be reported as a separate usability/accessibility thread. That would allow this thread to continue to be a developer level feature/functionality request. Nuno: > Even nowadays, I'd guess that at least 90% of the sites I end up visiting define no keystrokes, > or don't use javascript at all. In this case it sounds like the chances of your running into a site blocking important shortcuts for closing, quitting, navigating are actually pretty slim.

> The reason for this topic was to request functionality in the > browser that would allow the site to receive more of those currently > trapped shortcuts. That's what the first comment says, but that's not what the summary says. It is also not what the rest of the comments in this bug report seem to imply. This looks, and indeed is, a discussion on "Should web pages be able to override the browser's keyboard shortcuts?". > If the browser is not trapping enough of them from the perspective > of the average user that seems like that is in fact a separate issue > from this one and should be reported as a separate > usability/accessibility thread. That would allow this thread to > continue to be a developer level feature/functionality request. It is not a separate issue, it is closely tied to the original text in the bug report. Threads probably don't belong here, though, as this is a bug tracker, not a mailing list. Sadly, I don't know if there is any easy way to "transfer" this discussion to a developer mailing list, without leaving a large number of people behind. If anything, this should maybe depend on two bugs, like I mentioned above. Given how much was already said here on both topics, I'd argue against removing the usability, accessibility and security concerns away from this bug. >> Even nowadays, I'd guess that at least 90% of the sites I end up >> visiting define no keystrokes, or don't use javascript at all. > > In this case it sounds like the chances of your running into a site > blocking important shortcuts for closing, quitting, navigating are > actually pretty slim. Slim enough to catch me off guard when it happens. Were it more frequent, I'd probably not even use the keyboard with Firefox anymore.

I think that is a very fair and accurate assessment. As far as next steps I think that Mozilla should not block any additional keyboard shortcuts until they implement a new way for users to give sites permission to access to at least what is currently available. Until then blocking any additional shortcuts would break existing site functionality in a backwards-incompatible way without a way for the developer to work around it short of completely changing which shortcuts they are using.

Right now it also seems that some of the shortcuts are not easy to hijack, and so some web applications use workarounds. I am not aware of the details, but I think that both Google Instant and Outlook Web Access have some invisible textbox that is focused. This would at least be in line with the original text of the bug report, according to which a workaround involves some text input field. If this is correct, then Firefox devs have no choice other than being incompatible with something: if nothing is done, keystrokes are already hijackable, and that is incompatible with Firefox's own UI; if the workarounds are prevented, that is incompatible with web applications. There is *no* course of action that is not going to break anything. Right now, it'd be good to ensure at least some consistent behaviour, by making sure that the same UI keystrokes *always* do the same thing. Several ways to achieve this while still allowing the web applications to hijack browser keystrokes have been already discussed above, including two-mode systems (like vi's insert mode or pentadactyl's pass-through mode), and cookie-like question dialogs.

(In reply to Michael White from comment #141) > Why should advanced applications built to run in a browser not be able to > have the same level of keyboard access as their desktop counterparts? The answer is in the question. A Web app runs in a browser. The browser is a desktop application, and already has some keyboard actions. So these keyboard equivalents are unavailable to the Web app. This is logic. A browser has windows and tabs. So the Web app cannot have its own Apple N / Ctrl N, Apple T / Ctrl T keyboard actions.

Hi all, As a longtime Firefox user, the tab and basic keyboard navigation are critical to me, and usability around tabs (and some loyalty) is a main reason I don't shift to other browsers. From a software engineering perspective I would say: I don't care how much functionality a web app or site has - it is running inside the browser. The navigational aspect of the browser should be uniform across windows and tabs - its main job. I find it intolerable that I have 20 tabs open in a window and can Ctrl+Tab through them until I hit some page that intercepts the keybinding. This is the browser not allowing me to control its layer of concern in my opinion. I think you should keep a minimum of keybindings reserved for navigation (and saving - the original issue) and not allow the application layer to override them - as stated earlier - System -> Browser -> Application should be a precedence order for a consistent experience. If you want to allow users to give permission for a web app to override then that is fine - but the default should be browser control. As we get more into the realm of the browser as OS this is even more important. Do not allow your power users to be blown about by the winds of app developers fancy .. Thanks very much for thoughtful consideration. Thanks for giving this issue your interest..

Personally I find it extremely annoying if web pages are allowed to override scroll keys (PageDown, PageUp, Left, Right, Up, Down), or history navigation keys (Alt-Left, Alt-Right) or whatever they want, and I am really missing a switch in firefox to disable these overrides, preferrably per-site. IMHO, web pages with such overrides are broken by definition, and I do not care at all if such a page has a "usability problem" because it is not allowed to prohibit me from using my browser in the way I want; or if allowing to make the web browser unusable causes "support issues". It should be optional to let web pages know whether they are allowed to override whatever they want. Otherwise it will be the same as with cookies: there will be "warning pages" saying that this blog page needs absolute control over keyboard, harddisk, and bank account, otherwise it is truly impossible show the blog even if it just says that Sunday was a rainy day. As soon as some big CMS have such a warning function, not giving permission to override will disable most web pages.