From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020205 BuildID: 2002020511 If a page defines accesskeys for some elemets (e.g., <a href="./blah.html" accesskey=N), these can override the UI access keys, causing inconsistent behavior. I believe the problem may be that I have my accelerator key switched to Alt, rather than Ctrl. I would expect that this would cause the accesskey modifier to switch to Ctrl, or at least to be overidden. Reproducible: Always Steps to Reproduce: To see the problem in action, set you accelerator key to Alt (18) and go to the included URL. Actual Results: Browser advances to the "Next" html page. Expected Results: Browser should open a new window.

keyboard navigation

You can get around this if your accelkey is Ctrl, which is the default on Windows. It can still conflict with Alt keys, but you can get to the menus by pressing Alt first, and then the letter separately. You can customize your accelkey if it's currently set to ALT. See http://www.mozilla.org/unix/customizing.html#accelkey. Does this solve your problem? I can't think of any other way to get around this.

Aaron, the user _has_ customized the accelkey and set it to alt so that accel commands will not conflict with keyboard navigation commands in textfields. It seems we do something special so that ctrl-n will not trigger an "n" accesskey. We should be doing it for accel-n, not ctrl-n (s/n/whatever/).

My bad. Forgive me, I had my brain switched around. Resummarizing. Would it help the user if they could customize their in-page accesskeys to use Ctrl instead of Alt? I think that would just conflict with the Emacs-style commands they use. Does anyone have a suggestion for this? There are only so many modifiers on the keyboard.

*** Bug 145910 has been marked as a duplicate of this bug. ***

Would it help to simply use whatever the menu key is for accesskeys? Granted, that would mean that turning off keyboard menu access would also make access keys not work...

*** Bug 157873 has been marked as a duplicate of this bug. ***

raising severity, since according to bug 157873 our _default_ accelkey is ALT on some platforms. On these platforms, this issue is present all the time for all users. I feel strongly that accesskeys should just use the menu accelerator key all the time, as they do in the default Windows setup.

Correcting Boris a bit. Alt is not default accelkey in initial setup for BeOS Mozilla, but it is platform default. But majority of users immediatelly switch Mozilla setup to use it, because it is pain to use Ctrl, when you're used to use Alt everywhere.

it would help if the w3 didn't design silly things like this. the cat's out of the bag and we have to live with this insanity. while a page is focussed (and not a text area), what does shift-<randomkey> do? given our foolish approach of not assigning single characters to actions ala links/lynx, perhaps we can at least consider destroying shift-<randomkey>... it's true that if you happen to be in a text area, this is of no use, but what we really need is a way to be in a text area and press some key so that typing will no longer be accepted as key input for the textarea. i've always proposed escape and indicated that this system would allow us to use <tab> to insert real tab characters, but that's always rejected. so again i'll suggest escape as a straw man in hopes that something like this might go somewhere.

From discussion with bz and hogarth in #mozillazine: - When accel is set to Alt (BeOS by default, Linux used by an emacs lover), access should become Ctrl by default. - When access and emacs-modifier are the same, access should be disabled when focus is in a textarea.

> but you can get to the menus by pressing Alt first, and then the letter > separately. Not on UNIX. No way to get there without a mouse. freshmeat.net, a popular UNIX software site has accesskeys for their navigation menu. I'm not able to use my bookmarks there, since alt-b launched the B accesskey link. Very not cool. Why not use shift for accesskey triggering... or no mod?

Reassigning to Akkana, since this is sort of a UNIX accesskey problem. Note that we now have a pref "ui.key.generalAccessKey" for the accesskey accelerator (which we should advertise in the customizing doc).

I'm confused about a couple of issues here: (1) It isn't really a linux bug, right? It's just more obvious on linux and OS/2 because people on those platforms are more likely to set accel=alt, which means that more xul/xbl bindings will be on alt, which means there's more likely to be a conflict. But couldn't a page define an access key of alt-right and conflict even on windows? (2) It looks like the closest thing we have to a consensus is Jesse's comment 11; but Aaron's comment 13 says that there's already a pref holding the access key modifier, which makes comment 11 no longer relevant (unless we take comment 11 to mean that we should eliminate ui.key.generalAccessKey and instead decide the access key based on what the accel key is). If we have a pref for ui.key.generalAccessKey now, is the remaining problem to decide what the default setting should be on linux and OS/2? And/or to fix the customizing page to suggest a reasonable setting for it for people who change their accel key to alt?

Just to be clear, I don't think it's possible to create an accesskey for anything other than a printable character keystroke. You can't do <button accesskey="VK_RIGHT" .. /> Also, IE exhibits this problem if you have a page using an accesskey of D. If you do this then Alt+D no longer highlights the URL bar in IE: <html> <input type="checkbox" id="cb1" accesskey="d" /> <label for="cb1">abcd efg</label> </html> In IE you can't type Alt, let it go, then type D to highlight the URL bar, the way you might if it was a menu item. That's also our fix for accesskey conflicts with menu items such as _F_ile. > to fix the customizing page to suggest a reasonable setting for it for people > who change their accel key to alt? What would be a reasonasble setting?

Hey, people, i'm wondering, why not set programmatically "ui.key.generalAccessKey" = "ui.key.menuAccessKey" ??? Those mentioned above situations usually happen when/if people change swap "ui.key.menuAccessKey" and "ui.key.accelKey". So it seems logical to have this binding.

This needs a policy. Moving out until we decide what to do.

Sorry, but that translates into "the way we do it happens to work on Mac and Windows, so why bother changing anything?"

I'll note that, ironically, I first came across this bug when I couldn't figure out why "Alt-W" was not closing a bugzilla page the way I knew it should. But as a Linux user, I can offer a workaround for this bug that I've started using as a result of the information in this bug report. I use Alt as my accelKey (addictive habit), but now use Meta for both the menuAccessKey and generalAccessKey. This leaves Ctrl free for the emacs functions. // 17 control,18 alt, 224 meta user_pref("ui.key.accelKey", 18); user_pref("ui.key.menuAccessKey", 224); user_pref("ui.key.generalAccessKey", 224); > There are only so many modifiers on the keyboard. I realize that not everyone has a working Meta key, but most *nix users do, and they are among the most likely to be using Alt as an accelKey. > Hey, people, i'm wondering, why not set programmatically > "ui.key.generalAccessKey" = "ui.key.menuAccessKey" ??? Sounds like a fine default by me. While there are still potential conflicts between these two uses, at least the conflicts will be relatively consistent across platforms, and hence likely to be avoided by page authors.

bug 179816 should allow people to use shift instead of ctrl/alt/meta

Someone mentioned that this wasn't a problem on Windows. It is. If an accesskey conflicts with the menu (or Alt-D for the address bar in Phoenix), then the menu just doesn't work. To fix this, why not have the focus cycle between the conflicting elements each time the access key is pressed? This is what happens, for example, when more than one item in the same menu use the same accel key.

This bug is a major problem for gtk+ embedeers. In gtk+ apps, alt is use to activate menus, and ctrl is used for keyboard shortcuts ala ctrl+N == New Window. In Gtk+ as you probably know menus get all keypresses first and we have no way to change that so this creates a problem for us. Any chance that shift or perhaps super can be used as a modifier for embedders in this case?

Punting this back to Aaron (sorry!) Comment 21 says this isn't just a linux issue, and even if it were, it sounds like we need someone who can dictate a general policy on what to do about the problems with page access keys. (I'm not really sure there is a solution in general.) I don't see any consensus on any fix that I could offer for this bug. Dave Bordoley: for embedders, can't you use the pref to use meta for the accesskey, as Nathan suggests, or work on bug 179816, to allow using shift? At least that would offer a solution for users on distros/windowmanagers that don't block the meta key or use it for something else.

This bug and bug 179816 are virtually the same, both taking the form "Accesskeys conflict with $foo when modified key is $bar". Possibly 179816 should be marked as a duplicate of this one? http://bugzilla.mozilla.org/show_bug.cgi?id=179816#c1 suggests a preference to select the modifier key, I suggest the options be: * Ignore accesskey * Use Ctrl + accesskey * Use Alt + accesskey * Use Shift+Esc followed by accesskey The latter option is used by Opera and doesn't seem to conflict with anything.

Shift+Esc is used for launching Ava Find (the fastest search tool I've ever used). See www.avafind.com I would definitely go for the first option (Ignore accesskey). Webmasters should know better than to override browser mnemonics. Prog.

*** Bug 179816 has been marked as a duplicate of this bug. ***

As comment 21 mentions, this is a problem on Windows and a big problem for me, as I use Alt+letter for menus and accessing the address bar, but here in Bugzilla I feel more or less disabled as only a few menus work and I can't go to the address bar with Alt+D (which I often do). Internet Explorer 6 uses Alt+Shift+letter for web page access key, and that works fine. Couldn't Mozilla do that also?

I'm sorry about saying that Internet Explorer 6 works fine regarding the access keys. It doesn't. Alt+Shift+letter does work in IE, but Alt+letter does the same thing, and you can't reach some of the menus in IE either, on Bugzilla's show_bug.cgi page. But still, would it be a solution (in the Windows version at least) to use Alt+Shift+letter for access keys and reserve Alt+letter for menus and address bar (Alt+D)?

*** Bug 217442 has been marked as a duplicate of this bug. ***

*** Bug 217559 has been marked as a duplicate of this bug. ***

I can't believe there's even any debate about this. It's simple: a *web page* must not ever be able to disable standard keybindings in the *browser itself*. The web page must not be allowed out of that sandbox. If the author of some crufty bit of HTML thinks that Alt+N should do some random thing, they're welcome to think that -- but the browser I'm using had damned welll better continue to think that Alt+N means "New Navigator Window". There is *absolutely no way in hell* some page downloaded off the net should be able to change that, even temporarily. That's just crazy talk. This is a completely separate issue than the question of whether menubar shortcuts or text-area keybindings get priority. That's an important detail, to be sure, but that's a behavior of the *UI of the browser*. What I'm talking about here is the absurdity that some random web page can break the global UI of the browser by making standard keybindings break -- keybindings that have not changed in nine years.

I have three modes of navigation, personally: 1) Keyboard + mouse (left hand on keyboard, right hand on mouse) 2) mouse only (left hand on coffee cup or phone, right hand on mouse w/occasional trips to keyboard) 3) Keyboard only (both hands on keyboard) I switch from mode to mode throughout the day based on what I'm doing. Whenever an application forces me from one mode to another, I get upset. When I'm in Bugzilla and in keyboard-only mode, I'm forced to abandon it. Why? Because my favorite Firebird keyboard shortcut - Alt-D - is hijacked by the "Bug ###### depends on:" textbox. My particular favorite solution of the suggested is the focus-cycle method. However, it also makes sense to have a preference. There are multiple sensible options such as a preference to turn off HTML accesskeys, or a preference to have browser accesskeys take precedence over HTML accesskeys, or go in rotation, or whatever. As this is probably a low-traffic issue, I'd be content to set it in user.js or something - I personally don't care if a GUI is not created. However, I consider this annoying enough to vote for.

This is not a real solution, but this problem no longer bothers me, because I have The Proxomitron (http://www.proxomitron.info/) installed with a simple rule: Matching Expression: accesskey="d" Replacement Text: This removes all Alt-D access keys from all HTML pages I visit, locally at my machine. The program is installed as a proxy on localhost. I have similar rules that makes quick fixes of interface issues that bothers me in Bugzilla (or any other HTML system/web sites I use). I just thought that some of the listeners to this bug might be interested in this temporary "solution" that you can implement immediately for yourself, if you use Windows. There are similar tools available, also for Mac and Unix, see a small list at http://www.proxomitron.org/ .

Would it be possible to sidestep the issue entirely by implemeting accesskeys like typeahead find (they are functionally similar in that they take the user to a different point in the document). One could define a new modifier such as # (like ' for links and / for full text), so that # d would take the user to the next element with accesskey="d". It seems clear that no set of modifier keys is going to satisfy eveyone on every platform. I have suggested this on netscape.public.mozilla.accessibility and initial feedback seemed positive.

Hi, I am writing ASP software which requires lots of data entry...so naturally some of our customers like accesskeys. Right now, the use of accesskeys works like a charm in internet explorer and almost useless in mozilla. I am a Linux user and our software is developed and runs on Linux & mozilla, so don't take that statement lightly. I'll explain what needs to be done to make access useful in mozilla. Since we are an ASP our software has a ton of access keys. The main reason they are useless in mozilla is because 1.) The menu gets priority, so F,E,V,G,B,T,W,A,H, and a few others are out of the question (although occasionally they do work) and 2.) You cannot have the same access key used repeatedly throughout a page because mozilla automatically loads the first one it finds The solution is in the problem? Allow cycling between items with the same access key like in Explorer. But go beyond explorer and allow cycling to the menu item top. So for example, you have a "Search" button with accesskey="S", a "Save" button with accesskey="S" and a menu item, say "S-Mozilla Menu." When the user presses "Alt-S" go to the search....they press "S" again while holding Alt....then go to the save, and finally go the S-Mozilla menu. I'm not advocating priority of one over the other....just allow them all to work. I would however suggest priority to the HTML access key because you can't change those...you can always change browser settings. Another thing....it needs consistency. Right now, if I hit "Alt-A" the "Add-CC" input element gets selected. However, some of our pages use "Alt-A" and the browser does "Select All."

I am in complete agreement w/ <a href="#c31">Jamie Z's comment</a> that a _web_page_ MUST NOT be able to override an user agent's, Mozilla's in my case, key bindings. The behaviour that happens is highly irritating. Nothing makes me curse Mozilla than this issue. I avoid the pages that specify key bindings. Pavlov, bell, dog. In the meantime, i could use a workaround if anybody happens to know. - Parv

Following up to self ... I assigned "generalAccessKey" a key that my window manger happily eats up. I was actually going for highly rarely used key, which turned out to be the "menu key" originally assigned to bring up root menu in FVWM. That is not the best solution in case i want to use the web page assigned key bindings. But for a workaround, it is dandy. (Mozilla 1.6.b,1 (Alt is "accelKey" & Ctrl is "menuAccessKey"); FreeBSD 4-Stable; FVWM 2.5.8) - Parv

What really sucks is that standard keybindings come in both "Ctrl" and "Alt" form, which leaves nothing for something like the accesskey specification which has no way of knowing which browser is gonna be using what. A double modifier, like "Ctrl-Shift-A" might be safest. However, despite any earlier commments, I'd like to backup the earlier suggestion supporting a "look-ahead"-style. Hit some key or pair of keys, and then you get into "access-key" mode, cycling between the various HTML elements by pressing a single key. 1. Consistency: this style is probably going to be known by "keyboard users" anyways since the type-ahead feature is very usefull. 2. Does not conflict with any app/system level key bindings. Which should just face it, there is no keyboard modifier that is "available." Are there any disagreements to this? If not, let's do it.

> However, despite any earlier commments, I'd like to backup the earlier > suggestion supporting a "look-ahead"-style. Hit some key or pair of keys, > and then you get into "access-key" mode, cycling between the various HTML > elements by pressing a single key. It could be a setting in Preferences, i.e. the user could decide whether she wants a combination of access keys of her own choice, or the "look-ahead" style.

(In reply to comment #36) > In the meantime, i could use a workaround if anybody happens to know. See comment 33 for a Windows workaround.

Reply to comment 40... It seems you missed my following comment #37, in which i proposed my own workaround. You need to be thanked, however, since the Proxomitron page lead me to Privoxy (supposedly based on Internet Junkbuster; to used on FreeBSD). I am about to configure/test it.

*** Bug 242345 has been marked as a duplicate of this bug. ***

I tried implementing something like my suggestion in comment 34 as a Firefox extension. See http://forums.mozillazine.org/viewtopic.php?p=669099 if it sounds useful. It has a few limitations detailed in the thread. No seamonkey support at the moment but that might just be a case of writing an appropriate install.js.

*** Bug 254633 has been marked as a duplicate of this bug. ***

Come on guys, this issue is 4 years old. Close it please or at least raise its priority.

*** Bug 262359 has been marked as a duplicate of this bug. ***

junk@bbs.darktech.org: thank you for volunteering to fix it yourself. hurry up.

timeless, bite me :) I'm going to write a letter to Google right now and ask them to add alt-accelerator keys to their main page. I bet once your mailboxes are flooded with thousands of requests you'll care more :) I agree 100% with comment #31: I can't believe we're even debating this issue. We all pretty much know what the *expected* behavior is from the end-user's point of view. First disallow web-pages from hijacking browser shortcut keys. Then, if you really care, spend the extra time to come up with a better solution that remaps webpage shortcut keys so they do not collide with the browser ones. But instead of waiting years on a usability fix, patch it already! It's called incremental software development :)

you clearly haven't seen my mailbox. 1 - 100 of 142045 Older › Oldest » You are currently using 436 MB (44%) of your 1000 MB. you're also totally offbase. i do care. i have an internal bugzilla install which is even *worse* than the bugzilla.mozilla.org install. however, if i cared enough i'd fix the bug i filed or set ui.key.generalAccessKey to 0 (for each of my 100 or so profiles or builds).

Can we not patch the codebase ship with a default of ui.key.generalAccessKey=0 until a more comprehensive solution is found (in the spirit of incremental development)?

*** Bug 276690 has been marked as a duplicate of this bug. ***

1. I agree with J. Zawinski in #31, parv in #36, Gili #48: it is a case of page authors taking the page out of the sandbox and interfering with control of the application, and that's not OK. 2. An accesskey can submit a form or change form values. Therefore this is a data-loss bug. I haven't seen a "real world" case, but see: https://webspace.utexas.edu/swh/www/x/testpage.html It is easily done and probably exists somewhere. It could even have malicious potential. There are lots of unsuspecting keyboarders relying on longstanding shortcuts. 3. The focus-cycle proposal (#21, 32, 35) would be a second choice: if accesskey only focuses and still requires Enter to complete action, that would at least avoid page replacement or data-loss actions when the user is just trying to take some action in the current page. However, accesskeys would still be intruding on basic UI functionality (#31, 36, 48), placing an impediment in the way of access to a menu, for example. Why not set some non-conflicting combination such as a character key as accel for accesskey, as J.Graham in #34 suggests, *and* make it only focus on accesskey, requiring Enter to complete an action. Barring something like this, I second Gili's #50 until there is a consensus on a real solution.

*** Bug 277805 has been marked as a duplicate of this bug. ***

(In reply to comment #53) > *** Bug 277805 has been marked as a duplicate of this bug. *** Thx. I have to say it's amazing how many copies of this same bug have been filed (apologies for mine, I could not find a duplicate myself). Almost 3 years worth. A great example of how this bug interferes with normal activities: scroll to the bottom of this page, select some text, and hit alt-E to bring up the edit menu. Bam. Back up to the top of the screen. I can't see how this is acceptable functionality, especially if we (the general we) want Firefox to be an alternative for people tired of browser hijackings while using Internet Explorer. Do we need some sites out there to create spoofed/fake bookmark menus before this gets fixed?

This adds the option to disable in-page access keys. This is a preliminary patch, tested on Windows XP using Firefox version "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0" It needs additional keys, perhaps a different set for different platforms. Also, it would be nice if it could make the change without having to restart the browser (it's my first patch, don't know how to do that just yet). It might not belong in Accessibility, either, but FWIW I've seen many people connect the concept of accesskeys to disabilities.

*** Bug 234625 has been marked as a duplicate of this bug. ***

*** Bug 278074 has been marked as a duplicate of this bug. ***

*** Bug 312738 has been marked as a duplicate of this bug. ***

*** Bug 322796 has been marked as a duplicate of this bug. ***

I plan to alleviate/fix this issue in bug 340902. Comments and reviews to plan and code in that bug would be most welcome.

This patch requires bug 340902 to be fixed.

Not blocking 1.8.1, although this is a very bad bug. Any of these proposed solutions probably needs a good bit of trunk testing since they all have their own disadvantages, and we've been living with the problems of this solution for a while. (Although I did file a bug on another way of doing accesskeys that wouldn't have any of these problems; don't have time to find it now during the triage meeting.)

Comment on attachment 226623 [details] [diff] [review] change accesskey modifier from Alt to Alt+Shift (resp. from Ctrl to Ctrl+Shift) This patch has been included in bug 340902 which fixes this bug at least mostly (only if you modify the value of ui.key.generalAccessKey or have ui.key.chromeAccess == ui.key.contentAccess web pages continue to override browser shortcuts).

Wasn't this bug *completely* fixed by bug 340902? We now provide prefs to configure separate key combos to different functions, it's now the responsibility of the user to change them so that they don't conflict (unless he desires). The default setting is of course that they don't conflict. Simon, are there any remaining issues that I'm missing?

No, you're not missing anything, this bug is indeed completely fixed with the new defaults. The fact that content still wins over chrome if generalAccessKey is changed or if chromeAccess equals contentAccess would be a different bug - if anybody cares at all.

Simon, By default, will content able to override Mozilla shortcut keys? If so, I don't consider this bug to be fixed.

(In reply to comment #66) > By default, will content able to override Mozilla shortcut keys? No. *** This bug has been marked as a duplicate of 340902 ***

(In reply to comment #67) > (In reply to comment #66) > > By default, will content able to override Mozilla shortcut keys? > > No. > > *** This bug has been marked as a duplicate of 340902 *** > Not? Then how come that pressing Alt-d, Alt-b still focuses form elements on this page, instead of giving the browser-hotkeys higher preference?

(In reply to comment #68) > (In reply to comment #67) > > (In reply to comment #66) > > > By default, will content able to override Mozilla shortcut keys? > > > > No. > > > > *** This bug has been marked as a duplicate of 340902 *** > > > > Not? Then how come that pressing Alt-d, Alt-b still focuses form elements on > this page, instead of giving the browser-hotkeys higher preference? > Ah, i didnt read carefully enough before. I have to set some values in about:config manually. When i read 'default' i thought upgrading to a new version where this was fixed, would implement this 'default' automatically. (In reply to comment #68) > The fact that content still wins over chrome if generalAccessKey is changed or > if chromeAccess equals contentAccess would be a different bug - if anybody > cares at all. I actually do care. Why isn't it the other way around by default; chrome > content? But i guess this fix has to do. (Kinda similar to plugins > chrome issues) Anyway, sorry for posting in a 'duplicate' bug.