Closed Bug 349716 (altshift) Opened 18 years ago Closed 17 years ago

Content accesskeys now require Alt+Shift

Categories

(Firefox :: Keyboard Navigation, defect)

Product:
Firefox
Component:
Keyboard Navigation
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
Firefox 3 alpha1

People

(Reporter: thbley, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b2) Gecko/20060821 Firefox/2.0b2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b2) Gecko/20060821 Firefox/2.0b2

Having:
<a href="javascript:alert('test');" accesskey="e">test</a>

With latest FF "Alt+e" is no longer working.
It seems now to be "Alt+Shift+e" (2.0b2 on windows).
With a default us-keyboard layout you can't hit Alt+Shift+m with one hand, but Alt+m is ok.
Maybe you can change this behaviour back to that from FF 1.5 ?


Reproducible: Always

Steps to Reproduce:
1. Create a file with <a href="javascript:alert('test');" accesskey="e">test</a>
2. Navigate to the file
3. Press Alt+e on the keyboard (no action)
4. Press Alt+Shift+e on the keyboard (action is taken)




Expected Results:  
Alt+e should work and the message with test should come up.
Version: unspecified → 2.0 Branch
We *can*, certainly, it's as simple as setting a value for ui.key.generalAccessKey or setting ui.key.chromeAccess and ui.key.contentAccess to the same value. However, you would need a little more to balance out the problems discussed in bug 128452 and bug 179816 and bug 340902 and their duplicates than "I can't press Alt+Shift+m with one hand."
Component: General → Keyboard Navigation
QA Contact: general → keyboard.navigation
Summary: Accesskeys no longer working → Content accesskeys now require Alt+Shift
Whiteboard: [wontfix?]
A lot of pages are using the accesskeys, e.g. Wikipedia
Users are used to Alt+x, all kinds of manuals are written with Alt+x ...

A bit worse: I can still access Alt+e with event listeners in Javascript:

<a href="javascript:alert('test');">test</a>

<script>
document.addEventListener("keydown",keyCapt,false);
function keyCapt(e){
  if (e.keyCode==69 && e.altKey) {
    alert('test');
  }
}
</script>
 
This produces the messagebox with "test" and when I close the messagebox, the Edit-menu appears.


My idea to solve this:

Under Tools->Options->Content->Advanced_Javascript_Settings we can add:
Allow scripts to: override alt-x keyboard mappings

If checked, accesskeys have the same behavior as FF 1.5: if an accesskey is set, it overrides the top menu, if an accesskey is not set, the top-menu opens as expected.
If not checked, Alt-e, Alt-f, Alt-v, etc. open the items in the top-menu, and unmapped shortcuts like alt-n can be used for accesskeys.

That way every user can decide on his own which behavior he likes more.
There needs to be a decision one way or another.  I would prefer that the "out of the box" behavior be moved back to Alt+x. I'm looking at something like this in Tools->Options->Content->Advanced Javascript Settings.

Content accesskeys:

[x] Invoke content accesskeys when [Alt]-x is pressed
Status: UNCONFIRMED → NEW
Ever confirmed: true
Another option is to allow the Alt key to be used whenever chrome doesn't grab the keystroke first.

I have a feeling we're going to get 20+ dupes filed on this, because there's no good way to make the change known so that everyone hears about it.
Other problems I figured out:
In Windows, Alt+Shift is the shortcut for changing the keyboard layout to a different languages. So when I'm not properly hitting Alt+Shift+x altogether, I change the keyboard layout.


Numeric accesskeys are not working:

<a href="javascript:alert('test');" accesskey="1">test</a>


On a German keyboard I get ">" with the shift-key + "<", so accesskey for ">" is no longer working because I can't use shift in the accesskey:

<a href="javascript:alert('test2');" accesskey=">">1</a>

These things may be "unusual", but they worked in FF 1.5.
The same happens in SeaMonkey trunk as well as Firefox branch, so should the product/version be updated?

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060820 MultiZilla/1.8.3.0a SeaMonkey/1.5a
Component: Keyboard Navigation → Keyboard: Navigation
Product: Firefox → Core
Target Milestone: --- → mozilla1.8.1
Version: 2.0 Branch → 1.8 Branch
(In reply to comment #6)
> The same happens in SeaMonkey trunk as well as Firefox branch, so should the
> product/version be updated?

No, it shouldn't (though if it is, it should be by someone who'll remember the "Reassign bug..." radiobutton ;).

They both behave the same because of a Core change, which allows applications to set prefs to determine how chrome and content accesskeys work. This bug was filed asking Firefox to revert to the old "content and chrome fight, and content always wins" situation. If you want SeaMonkey to do the same, then you need to file a SeaMonkey bug for that. If you want a Core change to have some other interaction, like Aaron's "content loses unless chrome doesn't care, who knows what will happen when you use any given accesskey" then you need to file a new Core bug for that.
Component: Keyboard: Navigation → Keyboard Navigation
Product: Core → Firefox
Target Milestone: mozilla1.8.1 → ---
Version: 1.8 Branch → 2.0 Branch
(In reply to comment #7)
> No, it shouldn't (though if it is, it should be by someone who'll remember the
> "Reassign bug..." radiobutton ;).

That's what you get for supposing BugZilla being too streamlined (though I'm trying to push the blame to bug 320700 or bug 212355 ;))... anyway, you're right. Sorry for the bugspam.

Instead of just reverting the behavior for Firefox, I'd rather first try to figure out (maybe in separate bugs - and most of them in Core:Keyboard Navigation)
* how to better communicate the accesskey modifier change in the first place (apart from what bug 345817 does)
* why Alt+Shift+<number> doesn't work anymore
* whether we want to - and if so how - support non-alphanumeric characters for accesskeys (might be solved by the previous issue)
* whether letting chrome take accesskeys before content would be an acceptable fix (it IMO isn't, since we'd just revert the problem that you simply can't access certain elements)
* if we could have accesskeys loop between the elements when several have the same accesskey (see e.g. bug 129268) - although this would still break access to menu elements which are currently handled separately.

AFAICT the last two points won't stand a chance for Firefox 2.0, but the first two or three might.
*** Bug 351151 has been marked as a duplicate of this bug. ***
*** Bug 351159 has been marked as a duplicate of this bug. ***
I found out that setting "ui.key.generalAccessKey" to "18" in "about:config" returns the old behavior in FF 2.0b2.
But when using the same profile with FF 1.5 and FF 2.0b2, the setting gets resetted to "-1": start FF 1.5, close FF 1.5 and start FF 2.0b2.
(In reply to comment #11)
This happens due to how preferences are saved (resp. that when a preference is set to the default value it isn't saved and will be reset to the new default when you change from Firefox 1.5 to 2.0).

If you want to use the same profile for both versions, rather set "ui.key.contentAccess" to 4 for the desired effect.
(In reply to comment #8)
> * why Alt+Shift+<number> doesn't work anymore

I've filed bug 351310 to suggest a possible solution for this issue.

Note that numeric accesskeys have been broken already on certain keyboard layouts (e.g. fr-FR where they no _do_ work).

Also note that numeric accesskeys don't work well for Opera 9, either: Opera's modifier is Shift+Esc - numeric accesskeys are however still accessible by first hitting and releasing Shift+Esc and then hitting the number.
*** Bug 354290 has been marked as a duplicate of this bug. ***
Can't say I'm a big fan of the new change, pretty much all forum software
(vBulletin, IPB, phpBB, SMF, YaBB etc) uses alt+s as the shortcut for sending a
post and a lot of users do use this shortcut key.

This change will annoy quite a few people, suggesting people change stuff in
their theme won't help none techy users but probably force them to move to
another browser instead.

I'm certainly not looking forward to having to communicate the change to hundreds of users plus having to change the docs on the forums I run to edit this line "shortcuts: hit alt+s to submit/post or alt+p to preview".
(In reply to comment #15)
> I'm certainly not looking forward to having to communicate the change to
> hundreds of users plus having to change the docs on the forums I run to edit
> this line "shortcuts: hit alt+s to submit/post or alt+p to preview".

You do understand that this line has only been true for Trident (such as IE/Win) and Gecko browsers under Windows so far. Opera uses Shift+Esc instead, Konqueror Ctrl (and you'll have to release the key before hitting the accesskey) and most other non-Windows browsers use Ctrl instead of Alt. Now we just add a further alternative to that mix...
Yes, there are some reasons why we use Firefox and not Opera, not IE, not Konqueror ...

I think changing the documentation everywhere and tell the people how to hack about:config to get their old settings back is not a good way.

Of course there are technical problems with this, but there should be at least some kind of "compatibility mode" or setting which makes 2.0 acting like 1.5 and *quickly* enables all users to get back their old settings (see my idea for an option in "Advanced Javascript Settings").

The only reason why I've added the accesskeys to my application is that they are so easy to use in FF 1.0/1.5. I think other developers agree ?
(In reply to comment #12)
> (In reply to comment #11)
> This happens due to how preferences are saved (resp. that when a preference is
> set to the default value it isn't saved and will be reset to the new default
> when you change from Firefox 1.5 to 2.0).
> 
> If you want to use the same profile for both versions, rather set
> "ui.key.contentAccess" to 4 for the desired effect.
> 

I think it would be best to make content access keys override chrome access keys by default - every other Windows-based browser that I know of uses this functionality by default, and Firefox should continue to do so as well. A lot of non-techy users won't even think to search and see if they can find a solution to the issue - they'll just get annoyed and go back to using whatever browser they were using before trying Firefox.
(In reply to comment #18)
> I think it would be best to make content access keys override chrome access
> keys by default - every other Windows-based browser that I know of uses this
> functionality by default, and Firefox should continue to do so as well. A lot
> of non-techy users won't even think to search and see if they can find a
> solution to the issue - they'll just get annoyed and go back to using whatever
> browser they were using before trying Firefox.
> 

That's how it was before the change.  But it caused problems with things like entering Alt+nnnn character codes (any numbered access keys would take over while you were trying to type the character codes).
(In reply to comment #19)
> (In reply to comment #18)
> > I think it would be best to make content access keys override chrome access
> > keys by default - every other Windows-based browser that I know of uses this
> > functionality by default, and Firefox should continue to do so as well. A lot
> > of non-techy users won't even think to search and see if they can find a
> > solution to the issue - they'll just get annoyed and go back to using whatever
> > browser they were using before trying Firefox.
> > 
> 
> That's how it was before the change.  But it caused problems with things like
> entering Alt+nnnn character codes (any numbered access keys would take over
> while you were trying to type the character codes).
> 

Fixing that issue should be the responsibility of the person who chose to use numeric accesskeys...
Normally I type alt+character-code with the number block on the right side of the keyboard. But I type the Alt+number accesskeys with the normal numbers on the keyboard. So why not do the separation here ?
The normal numbers and those on the number block already have different keycodes (e.g. Alt+1 as accesskey is 49 and Alt+1 as character code on the number block is 97)

Another option would be to display a menu where the user can choose the right action if the alt+x combination is mapped twice. E.g. I have <a href="http://www.simple-groupware.de" title="myEdit">Edit</a> on a page: the user presses alt+e, a menu comes up with the options "Edit-menu" and "myEdit" and a checkbox with "remember my decision". The choice should only come up once per accesskey to avoid too much furstration for the users. Opera9 is already displaying such a menu which summarizes all accesskeys of a page when you press Shift+Esc. (But they forgot to make the items clickable ...)

In 2.0rc1, numeric keys are not even working with alt+shift+#.
ALL accesskey-definitions using numerical keys on websites are broken in FF 2.0 RC 1 because only their shifted equivalents are generated, i.e. accesskey="1" would have to be defined as accesskey="!" on a website for it to work at all.
The problems still remain in FF 2.0rc2.
I'd like to set this as blocking-firefox2, do you agree ?
As annoying as this bug is, I don't think it's severe enough to justify blocking-firefox2, since it's not that big of an impediment to usability.  Changes to this function can be described in the Release Notes maybe, and anything accessible by access keys can also be accessed by clicking on a link anyway (or tabbing over to it and hitting Enter).  Yes, these may be inconvenient for example for some people who have difficulty using a mouse, so it probably should be fixed sometime.
To be honest, who has ever read the release notes when installing Firefox ?

So you want to close 2 bugs, open n new bugs, break working usability in Wikipedia, all kinds of forum software, lots of other web applications, break all HTML documentation like selfHTML, have non working numeric accesskeys, force non-technical people to hack about:config and force people to upgrade to a less-functional version,
Good luck!
I agree, this change pretty much makes accesskeys useless on Windows (even for people who figure out how to use the new shortcuts, because Alt+Shift is so awkward on most keyboards) and should be reversed.
Flags: blocking-firefox2?
I also agree that this should be reversed. As web applications continue to become more sophisticated this is even more true.  Its about the webapps in the browser, not the browser.

I've also noticed that apps like writely (http://www.writely.com) can no longer grab key strokes like ctrl-S properly. Seems related to this perhaps, though maybe should have its own bug opened. 
(In reply to comment #28)
> I've also noticed that apps like writely (http://www.writely.com) can no longer
> grab key strokes like ctrl-S properly. Seems related to this perhaps, though
> maybe should have its own bug opened. 
 
Whoops! Wrong there. was using a mac and mistook the command/apple key for the ctrl key.  ctrl-s in writely works just fine in RC2... sorry for the noise


(In reply to comment #25)
> As annoying as this bug is, I don't think it's severe enough to justify
> blocking-firefox2, since it's not that big of an impediment to usability. 
> Changes to this function can be described in the Release Notes maybe, and
> anything accessible by access keys can also be accessed by clicking on a link
> anyway (or tabbing over to it and hitting Enter).  Yes, these may be
> inconvenient for example for some people who have difficulty using a mouse, so
> it probably should be fixed sometime.
> 

I really hope this gets fixed prior to Firefox 2.0 final release. Considering how many places accesskeys are used (forums, many other web applications), it would be best for the developers to revert to the standard functionality, especially since the current functionality breaks numeric accesskeys altogether. I don't want to have to explain to hundreds of forum users why ALT+S suddenly brings up the history menu instead of submitting the post...
(In reply to comment #25)
> As annoying as this bug is, I don't think it's severe enough to justify
> blocking-firefox2, since it's not that big of an impediment to usability. 

Right you are.
I'm sure we'll revisit this before Firefox 3, though, and will have a good set of usage data to see how much of a problem the change actually ends up being.

FWIW, I think more people expect Alt+F to activate the File menu than whatever some web page's access key might have that do. Just sayin'.
Flags: blocking-firefox2? → blocking-firefox2-
Keywords: uiwanted
Target Milestone: --- → Firefox 3 alpha1
In reply to comment #31)
> FWIW, I think more people expect Alt+F to activate the File menu than whatever
> some web page's access key might have that do. Just sayin'.
> 

Even more people expect Alt+S to submit their post on a forum than open the history menu in their browser. "S" is used much more frequently for accesskeys than "F" is.

(In reply to comment #31)
> I'm sure we'll revisit this before Firefox 3, though, and will have a good set
> of usage data to see how much of a problem the change actually ends up being.

Good idea, cause mass confusion Firefox 2 then confuse people all over again for Firefox 3.
(In reply to comment #31)
> (In reply to comment #25)
> > As annoying as this bug is, I don't think it's severe enough to justify
> > blocking-firefox2, since it's not that big of an impediment to usability. 
> 
> Right you are.
> I'm sure we'll revisit this before Firefox 3, though, and will have a good set
> of usage data to see how much of a problem the change actually ends up being.
> 
> FWIW, I think more people expect Alt+F to activate the File menu than whatever
> some web page's access key might have that do. Just sayin'.
> 

I think with the ammount of people complaining it's pretty obvious theres no real point to changing it. My mind a lot of other people's minds believe ALT S is form posting, I use it every day without fail. I beg of the people with the power to change it back to do so. 
(In reply to comment #34)
> I think with the ammount of people complaining it's pretty obvious theres no
> real point to changing it.

If you look at bug 128452 (which requested a change like this), you'll see that there aren't that many people complaining here so far...

Before you start adding more complaints, note that this isn't about whoever gets more votes for their side but about how to solve an accessibility problem with a 10-year tradition (although, as I said in comment #16, other browsers have already suggested different solutions to this problem); and if you read through bug 128452, you'll see that the chance for returning to the behavior we had until Firefox 1.5 is really minor.

(In reply to comment #33)
> Good idea, cause mass confusion Firefox 2 then confuse people all over again
> for Firefox 3.

Sarcasm aside, the idea is of course not to change this again for Firefox 3, but to fix the remaining issues with numeric access keys (which might happen in bug 351310).

Fixing any of the other issues listed in comment #8 would require a rewriting of large parts of the accesskey code which would first require a new design decision and then a developer capable of implementing it. The same goes for alternatives such as using something else than pure modifiers (i.e. Alt, Ctrl, Shift and/or Meta) for triggering accesskeys as is possible for Opera and has been suggested e.g. in bug 303192.
The point is, this breaks more things than it fixes. Most forum systems use ALT+S for submitting posts or sending PMs (including IPB, vB, SMF, phpBB, PunBB, UNB, MyBB and YaBB). I have yet to see a webpage that uses "F" as an accesskey, and haven't seen any that use numeric accesskeys either.

I am not looking forward to having to explain to thousands of forum users why Alt+S suddenly opens the history menu instead of submitting the post.
Severity: normal → blocker
Severity: blocker → normal
We have two positions. If any of them wins, the other one needs to have a quick method to change the accesskeys to their behavior, see comment #3 for a good method.
Forcing users to hack about:config will not be the way.
Severity: normal → major
thbley@gmail.com: stop messing with severity.

> I have yet to see a webpage that uses "F" as an accesskey

Mediawiki default skin. *Very* annoying.
Severity: major → normal
Version: 2.0 Branch → Trunk
Sigh... Yet another RC is out and this bug is still there. Why does this have to wait until FF3?
Alt+Shift is bugged too, sometimes no matter what I do I get the History menu dropping down.

Why can't you just revert back to 1.5 behavior?
(In reply to comment #37)
> the other one needs to have a quick
> method to change the accesskeys to their behavior

Comment #3 proposes an option to toggle between broken accesskeys and no accesskeys at all (and mistakenly puts everything under advanced JavaScript options where it wouldn't belong anyway).

The alternative would be to have an option under Advanced -> General -> Accessibility reading "Allow content accesskeys to unexpectedly break access to menus and toolbars". But please tell me: how many of those users not able to modify a hidden pref would check that box?

(In reply to comment #40)
> Alt+Shift is bugged too, sometimes no matter what I do I get the History menu
> dropping down.

Can you reproduce that behavior. If so: please file a bug!

> Why can't you just revert back to 1.5 behavior?

Because that behavior was even more broken (you've just got used to it) - and because it's now simply too late in the game for non-critical changes (read: major crashes and exploits).
Fixing a problem by creating an even larger one is not something I would consider a minor issue. There is still plenty of time to change the default functionality so that content accesskeys get priority over browser accesskeys.

The ironic thing is, this change also breaks functionality on this site. This site uses 17 different accesskeys - 5 of which will no longer work by default in Firefox 2.

If the problem that this fixes was such a major issue, why do IE and most other Windows-based browsers still use the standard ALT+Key format?
(In reply to comment #41)

> > Why can't you just revert back to 1.5 behavior?
> 
> Because that behavior was even more broken (you've just got used to it) - and
> because it's now simply too late in the game for non-critical changes (read:
> major crashes and exploits).
> 
I think fixing this issue is rather critical, as you said, people got used to this functionality the last few years using firefox. Why change something a basic interface thing that is used by many because it seems to even more broken. Fix the thing why it is broken, do not change the interface of using it. It is very annoying to have something change you already are using for the past 2-3 years. It would be the same for me if you decided to put the vertical scrollbar at the bottom of my screen, it could be technically better, but why should I as user care about a technical improvement, most important for me is that the interface which I am using is identical to the one I used to have, not because some developer decided it was technically better to decrease the functionalities, because that is what it does, accesskeys are harder to use (three button command instead of 2 buttong command) and concerning usability and probably even WAI this is not the way you handle you friendly and kind users ;).

Reminder: as of comment #31 nothing will happen in this bug for Firefox 2.0. If you want to contribute, please read bug 128452 first and then rather suggest an alternative to fix that bug than to just complain about a change (rather use the mozillaZine forums for venting).

(In reply to comment #42)
> There is still plenty of time to change the default
> functionality so that content accesskeys get priority over browser accesskeys.

There indeed is -- for Firefox 3.0. Note that the changes you summarize in that one sentence are not trivial to implement at all (should you think so, please provide a working patch to prove me wrong). OTOH as I said in comment #8, simply reverting the priorities is no practical solution either, because then Alt+S would always open the History and we'd get plenty of bugs saying Alt+<arbitrary letter> is broken in <arbitrary locale>.

> The ironic thing is, this change also breaks functionality on this site.

If any accesskey doesn't work on this page, it's rather due to the unrelated bug 129268.

(In reply to comment #43)
> Fix the thing why it is broken, do not change the interface of using it.

Care to suggest how to rather fix the issue reported in bug 128452?
> (In reply to comment #43)
> > Fix the thing why it is broken, do not change the interface of using it.
> 
> Care to suggest how to rather fix the issue reported in bug 128452?
> 

Look on which element the focus is. E.g. if the focus is on the browsing canvas (the webpage) the accesskey of the webpage should be preferred. If the focus is on the browser (everything else but the webpage) the accesskey of the browser should be preferred.

By choosing e.g. alt+s as accesskey for the history a big issue (imho) is created. Most large forums do use alt+s as accesskey for posting new messages. Also only History is using not the first letter of the word as accesskey, which is also inconsequent imho.
(In reply to comment #44)
> If any accesskey doesn't work on this page, it's rather due to the unrelated
> bug 129268.

ALT+SHIFT+key works, but the much-more-commonly-used ALT+key doesn't. By default. Even if the accesskey isn't used by the browser, you still have to hit ALT+SHIFT+key.

Browser accesskeys should NEVER override the intentions of the website's designer. Period.
*** Bug 357279 has been marked as a duplicate of this bug. ***
(In reply to comment #45)
> Look on which element the focus is. E.g. if the focus is on the browsing canvas
> (the webpage) the accesskey of the webpage should be preferred.

While an interesting suggestion, this would not only lead to quite an inconsistent experience for those users unaware of focus but again mostly expose bug 128452 since most of the time the focus is on the webpage (when the user is not currently entering a new address/search term).

> By choosing e.g. alt+s as accesskey for the history a big issue (imho) is
> created. Most large forums do use alt+s as accesskey for posting new messages.

You do see the design issue here. Web pages should not have any influence on the browser in this case. What if many other accesskeys would be widely used? Would this mean that browsers can't use any chrome accesskeys at all? And also note that the choice of preferred accesskey might vary from language to language...

(In reply to comment #46)
> ALT+SHIFT+key works

That's how it's designed to be. Having Alt function for both might again confuse users who accidentally typed Alt+S in a forum (supposing that Alt+S isn't already used as a browser accesskey as it in fact is) since submitting a form never was the user's intention (rather typing Alt+D to focus the address bar was).

> Browser accesskeys should NEVER override the intentions of the website's
> designer. Period.

And a website's designer should _never_ override browser accesskeys. So in order to allow both browser and websites to select the most appropriate accesskeys, you simply can't use the same modifier.

---------
Please continue further discussion at http://forums.mozillazine.org/viewtopic.php?t=446830 (or a newly opened thread).
If that's the case, why is BugZilla using "h" as an accesskey? Everyone knows that this launches the help menu in Windows applications. This overrides the browser accesskey in most cases.

My point was that you're overriding the "S" accesskey, which has been in use longer than Firefox has been around. I've been posting on messageboards for about 6 1/2 years now, and "S" was a standard even then. Why force users to change when it's quite obvious that they don't want to?

I should also note that this completely breaks the accesskeys on many UK government websites (see http://www.nhsidentity.nhs.uk/websites/#fourthreefive). Most of these are numeric. Numeric accesskeys don't work with ALT+SHIFT. Do you want to break these sites too?
(In reply to comment #49)
> If that's the case, why is BugZilla using "h" as an accesskey?

Because website should be able to use all accesskeys - as should browsers. That's why browser and website accesskeys _must_ use different accesskey modifiers. In other words: a browser in which certain functionality can be broken by a website is broken itself; and a browser which breaks certain website functionality is broken as well. Using a different accesskey modifier fixes both issues.

> Why force users to change when it's quite obvious that they don't want to?

Users never want to change. But the effort required by certain users to modify their habits finally allows to fix an issue for a different group of (currently not so vocal) users for which there was no work-around so far (you've at least got the option to change back to the former behavior).

> Numeric accesskeys don't work with ALT+SHIFT. Do you want to break
> these sites too?

Of course not. I'm very sorry about this having happened. Unfortunately this issue was detected too late in the release cycle (and there wasn't enough developer time left for fixing it).

I'm confident though that there will be a fix available for this any time soon in form of an extension though -- in fact, I'll have a look at it myself as soon as time permits.
*** Bug 357561 has been marked as a duplicate of this bug. ***
*** Bug 357589 has been marked as a duplicate of this bug. ***
(In reply to comment #49)
> My point was that you're overriding the "S" accesskey, which has been in use
> longer than Firefox has been around. I've been posting on messageboards for
> about 6 1/2 years now, and "S" was a standard even then. Why force users to
> change when it's quite obvious that they don't want to?

in italian version, ALT+S opens the menu "strumenti" and is not usable on forums anymore...

Will you change this for the final release 2.0 ?
I've found another solution which completely overrides the accesskeys of the chrome interface, but this needs a lot of changes in the code of the web applications ...
(In reply to comment #54)
> I've found another solution which completely overrides the accesskeys of the
> chrome interface

What about those users who rather want to access the menus or the address bar? Shouldn't a German user be able to hit Alt+S to focus the address bar just because most forums were only tested with English browsers? Would you really want to make their browser less usable rather than more (i.e. allow direct access to both menus/address bar _and_ website functionality at the same time as we do now)?
A German user indicates Alt+s with Save or "Speichern" (=save in German), for the History or "Historie" he would try Alt+h. Moreover he is used to Alt+s as "Speichern", so he/she makes an update of his browser and downgrades his knowledge ...

I'm focusing the address bar with F6 because its faster than hitting 2 keys. Normally you don't need the File menu, because all entries in this menu already have good shortcuts (Ctrl+s, Ctrl+p and Ctrl+t), the same for the edit menu. The view menu is only necessary for the time adjusting the profile. Increasing font sizes is done with "Ctrl+mouse wheel" by all users I've seen, source view and fullscreen already have good shortcuts. The bookmark menu is totally unusable if you have 100+ bookmarks in the highest level, I'm using Ctrl+b here. The Tools menu is only necessary for the first time and clearing caches can now also be done with Ctrl+Shift+Del which is also very good. The help menu is only good for checking if the updates went in correctly. But the accesskeys are used much more often every day than the items in the menu bar.
The microsoft guys found the menu bar so interesting that they're hiding it by default. This reflects more the user's way of using the browser.

I think it's really amazing that we're discussing for 2 months without any working solution. Now we have a final version on the ftp servers which is not even able to handle numeric accesskeys, although there is no technical restriction for this. Also this violates the HTML 4.01 specs since 0-9 are in the "Document Character Set".

I'm not really sure if users know that this is called accesskeys and that they have to look up "http://www.mozilla.org/unix/customizing.html". I haven't found a changelog stating this issue, all kinds of press releases only talk about the new features. Even the Opera guys have understood that this needs at least a good user interface to change this instead of forcing users to specify numeric numbers like 18 in "about:config". So all kinds of projects will have to spend time on handling bug tickets for this issue. If you're forcing users to use this version by installing it automatically as a security update, it's simply the wrong strategy (most addons and themes are not ready for 2.0).

Using accesskeys with Alt+Shift makes them totally useless and developers of all projects will need to write browser specific and version specific code to handle this correctly. I can't tell you how much pain it is to write code for IE.
There were really good alternatives on this thread but you ignored them all to enforce your own thinking how a browser should work. That's not the way open source works.
This is definitively the last bug ticket I opened here since I'm not interested in wasting my time.


Here is my code to get a around this issue:


From the DOM Level 2 specification:
Any event handler may choose to prevent further event propagation by calling the stopPropagation method of the Event interface. If any EventListener calls this method, all additional EventListeners on the current EventTarget will be triggered but bubbling will cease at that level. Only one call to stopPropagation is required to prevent further bubbling.

stopPropagation:
The stopPropagation method is used prevent further propagation of an event during event flow. If this method is called by any EventListener the event will cease propagating through the tree. The event will complete dispatch to *all* listeners on the current EventTarget before event flow stops. This method may be used during any stage of event flow.


<html>
<body>
<script type="text/javascript">
/*
workaround for bug 349716
see https://bugzilla.mozilla.org/show_bug.cgi?id=349716
*/
if (document.addEventListener && navigator.userAgent.indexOf("Firefox/2")!=-1) {
  document.addEventListener("keypress",accessKeys,false);
}
function accessKeys(e) {
  if (e.altKey && e.charCode == 115) { // 115 = s
	e.stopPropagation();
	save();
  }
}

function save() {
  // your save code
  alert('action: save');
}
</script>

<a href="javascript:save();" accesskey="s">Save</a>
</body>
</html>
Why cant you just add a feature in Tools:

"Disable FireFox access keys."
I really don't think Firefox 2.0 should go final in its current state:

There has been no prior mention of this functionality in the release notes (not that a lot of people actually read those - I don't), so it will be unexpected for a lot of people. People will have to spend time digging up information on how to change this (most likely looking on MozillaZine, which would then lead them to this bug), and it will be seen as a major annoyance by a lot of people.

Numeric accesskeys will be completely broken, thus breaking accessibility on many UK websites and making Firefox less than attractive to those people who rely on accesskeys to help them navigate these websites. Because there is no interface for this, changing this setting without using a mouse is a lot of work. How do you think it will look when people find that you knew numeric accesskeys would be broken by default yet chose to do nothing about it?

Web developers will simply find ways to work around this issue, forcing their accesskeys to override chrome accesskeys regardless of the browser settings, thereby making this change completely useless to begin with.

On the other hand, if you just change ui.key.contentAccess to have a default value of 4 (as I've been suggesting all along):

Everyone will be happy - if people want the new functionality, they can change the settings to get this functionality without the downside of web developers overriding it to make things easier on their users. Those who don't won't have to change anything. Web developers can spend their time improving their software instead of trying to find a workaround for this.

Numeric accesskeys will work - no issue of having people question why the browser was released with such a major bug in it.

This will also give you plenty of time to revisit this bug and the original issue to find a better solution without annoying millions of people and making people wonder why Firefox 2.0 is so much better than Firefox 1.5.

I'd really hate to see the current functionality stay the default - this bug has been a known issue for two months, and nobody has chosen to do anything about it, so why not make a temporary fix now and work on improving it for Firefox 3?
I agree.  Many other browsers dont have these FireFox access keys that are in the latest beta release.  I'd be happy if you included a feature so I can disable these "FireFox" access keys in Tools, this way the websites I visit I can still use the access keys without having to get the History > Back problem.
(In reply to comment #50)
> I'm confident though that there will be a fix available for this any time soon
> in form of an extension though

See attachment 243344 [details] of bug 357101 for such an extension.

(In reply to comment #56)
> A German user indicates [...]
> I'm focusing the address bar with F6 [...]

It is undisputed that Firefox can be used without chrome accesskeys and that there are everywhere users who only use content accesskeys. The question was rather whether we should optimize for those users at the cost of breaking accessibility for those users used to navigate the menus themselves - or whether we should allow both groups of users to access everything and have a pref for reverting to the former behavior.

Of course, making that decision between "broken" and "inconvenient" isn't too easy if you only experience the "inconvenient" bit...

> I think it's really amazing that we're discussing for 2 months without any
> working solution.

The [wontfix?] entry in the status whiteboard could have been an indication that this bug might not be used for changing anything (opposed to bug 357101 which will get fixed).

> I haven't found a changelog stating this issue,

I've asked for such a note several times (see bug 345817 and bug 354830) but those responsible for the release notes seem to consider this not to be a priority.

> Using accesskeys with Alt+Shift makes them totally useless

Is there a deeper reason for this than that they're no longer _that_ easy to press (what would be the alternatives if Alt was out of the question?) and that bug 357101 hasn't been fixed yet?

> and developers of all projects will need to write browser specific and
> version specific code to handle this correctly.

Actually, developers are at best supposed to adjust the documentation to say "Alt+Shift" for Firefox 2.0+ (as e.g. Wikipedia already has).

> That's not the way open source works.

As I see it, the way open source works is: If you're not happy with something, you can either provide a patch and hope that it gets accepted into the source by the powers-that-are or to compile-your-own. Feedback is mostly welcome (and even asked for in the newsgroups and the wiki) but won't always be considered.

> Here is my code to get a around this issue:

You are hopefully aware that it is this "work-around" makes Firefox less accessible since it doesn't let the user make the choice about whether and how to use content accesskeys. OTOH if many sites employ such code, we might soon have the same discussion again when a bug was filed to not pass certain keypress events into content in the first place (effectively disabling this code again).

(In reply to comment #57)
> Why cant you just add a feature in Tools:

Feel free to file a bug on that behalf and be told why that won't happen by somebody with authority in these matters. My guess is that the answer would be something like "this option wouldn't benefit most of our users and would only make the stream-lined Options dialog more cluttered".
I still say it would be in your best interest to set ui.key.contentAccess to have a default value of 4 - why is that so hard?

This simple change will make everyone happy and stop so many of us from constantly complaining about this issue.
If I set that option to 4, will it change this?  Isn't FireFox supposed to be FOR the users & their ideas?
I really am disappointed at the developers' response to this. I personally have been complaining about this for three weeks and nothing has been done - lots of excuses have been thrown out, and we've even been told that there wasn't enough time to fix it for final.

I am still going to use Firefox 2.0, but I certainly hope that developers are a lot more receptive to user complaints for Firefox 3 than they have been for Firefox 2 - this certainly makes me wonder how much say the users actually have in the functionality of their browser...
Regarding alt+s and alt+p not working, there seems to no working work-around for this bug. If I change ui.key.contentAccess to 4 instead of 5, I get only alt+s working, while alt+p still does some weird window centering thing or some such.

Even if you would not fix this, there should be a way to enable the normal functionality.

Pressing alt+shift+[ps] just doesn't cut it, as it's harder and for sure less ergonomical, putting the hand in very awkward position.



I think you guys have underestimated the amount of blowback you're going to get over the decision to wontfix this.

I for one am going back to 1.5 until either you guys fix this bug, or the millions of websites that you've broken get fixed.


*** Bug 357961 has been marked as a duplicate of this bug. ***
*** Bug 357972 has been marked as a duplicate of this bug. ***
Alias: altshift
*** Bug 358114 has been marked as a duplicate of this bug. ***
A better, more wide-ranging fix for the problem of access keys would be to allow the user to define their own access keys for, say, "home", "next", "previous", "search" "copyright info", "contents", etc.; and then to map these, for any given page, to the target pages specified in the "link" headers, e.g.:
 
	<link rel="home" href="http://www.example.com/index.htm">
	<link rel="search" href="http://www.example.com/search.htm">
-- 
Andy Mabbett
(In reply to comment #69)
> A better, more wide-ranging fix for the problem of access keys would be to
> allow the user to define their own access keys for, say, "home", "next",
> "previous", "search" "copyright info", "contents", etc.; and then to map these,
> for any given page, to the target pages specified in the "link" headers, e.g.:
> 
>         <link rel="home" href="http://www.example.com/index.htm">
>         <link rel="search" href="http://www.example.com/search.htm">
> -- 
> Andy Mabbett
> 

It does seem like a good idea, but it would potentially be a lot of work on the  web-designer's part as well.  It also probably wouldn't catch on unless other browsers (like IE especially) do the same thing as well.  (And I mention IE because it seems like a good portion of sites are designed and tested only on IE...)
*** Bug 359761 has been marked as a duplicate of this bug. ***
*** Bug 360067 has been marked as a duplicate of this bug. ***
See Details of Bug 360067: Alt-Shift doesn't work either with the given URL.
so, i see this marked as wontfix...just FYI, the UK government guidelines for all their sites lists a series of recommended numeric access keys. does this mean, then, that we need to lobby government to change their guidance because FF is the only current browser, to my knowledge, that doesn't support numeric accesskeys?
(In reply to comment #74)
> so, i see this marked as wontfix...just FYI, the UK government guidelines for
> all their sites lists a series of recommended numeric access keys. does this
> mean, then, that we need to lobby government to change their guidance because
> FF is the only current browser, to my knowledge, that doesn't support numeric
> accesskeys?
> 

Well, it doesn't look like it's officially WONTFIX yet.  But it still seems like there hasn't been a simple (in both the developer and user aspect) way to fix this without breaking some other aspect of usability...
We have had accesskey="0" to "9" since we could
IE users get to press enter, but it works
Numeric accesskeys are completely broken in FF2.0
Please give us back our alt-0 to alt-9 navigation
End of story as far as I am concerned.
(In reply to comment #76)
> Numeric accesskeys are completely broken in FF2.0

They happen to be quite fixed in Firefox 2.0.0.1 (as of bug 351310) which is due this Thursday.

And for those of you stuck with Firefox 2.0 under Windows for the time being, there's an extension available over at bug 357101 to fix the same issue.

Finally, if you really can't live with Alt+Shift+<key>, you've at least got the choice to revert to (most of) the former behavior through about:config or an extension to be written/updated for that purpose.
I think the accesskeys problem persists either way. I'll try to summarize possible alternatives here, and why each of them could be bad:

First, I'd like to note that MOST of the two-key combinations (Alt+Shift, Ctrl+Shift) are bad in sense that they may toggle keyboard layout change instead of accessing the required element (this happens for me now).

Alt - may conflict with browser Chrome, which isn't that good (think of Alt+F);
Ctrl - again, may conflict with Chrome (think of Ctrl+F);
Shift - well... Not so much of a modifier by itself;
AltGr - same as Shift;
Menu - already used for invoking context menu;
Win - already used to toggle "Start" menu on Windows;
Ctrl+Alt - absolutely bad on Windows, and maybe some other operating systems, as it's a shortcut for AltGr;

Ctrl+Shift, Alt+Shift - both may (or may not) toggle keyboard layout change both on Windows and Linux, and maybe other OS's too.

My suggestion would be to allow the user to choose content modifiers himself, through the Preferences interface (Web would be a good category for it, IMO). This could be a group of checkboxes, or a drop-down list, or a group of radio buttons. Another option is discussed in bug #303192. 

Also, I'm still not sure about how Fx could handle accesskeys that require Shift pressed. Maybe, it could simply ignore those, I don't know.

I think it's a kind of a flaw in HTML specification itself, or maybe just a wrong assumption between users. Anyways, I see enough logic behind "accesskeys should be toggled similarly everywhere", so, it makes "Alt" the logical  choice (and renders bug #340902 quite useless). But I also see why this isn't considered a good choice. And as for comment #7, I'd vote for Chrome winning. Again, this could be a preference, or resolved similarly to bug #129268.

Another idea could be to get rid of all Alt+* accesskeys from Chrome, except maybe Alt+F, but I think it's too radical. Especially, taking into account that not so many sites make use of accesskeys, and even a smaller fraction of them uses keys that result in collision with Chrome...

Anyway, I believe this problem with accesskeys should be considered again for Fx3. Maybe, we could come up with a better solution, that wouldn't conflict neither with Chrome, nor with the underlaying OS.
Another idea: how about using "Win" as a platform-specific accesskey on Linux and other UNIXes? How many distros use this key by default?
How about this: On Windows, if a web page defines access keys, Alt-X will invoke them (just like in IE). Add a small toggle to the status bar where you can switch this behavior.

Also I noticed that access keys don't work for combo boxes. Should I open a new bug for this or is that the same issue?
> Also I noticed that access keys don't work for combo boxes.

I'm guessing you mean <select> widgets (dropdowns on windows, popups on Mac).  The Web doesn't have combo boxes.

> Should I open a new bug for this or is that the same issue?

Sounds like a separate issue, since this bug is about a specific change to the modifiers required.  So please file a new bug (with a simple HTML testcase demonstrating the bug).
> > Also I noticed that access keys don't work for combo boxes.
> I'm guessing you mean <select> widgets (dropdowns on windows, popups on Mac). 
> The Web doesn't have combo boxes.

My bad. While trying to build a test case, I noticed that GWT doesn't generate the accesskey attribute for SELECT widgets on Firefox. On IE, it does. I'll open a bug against GWT.
(In reply to comment #82)
> How about this: On Windows, if a web page defines access keys, Alt-X will
> invoke them (just like in IE). Add a small toggle to the status bar where you
> can switch this behavior.

This is a no go. This behavior has been changed so that websites don't hijack access keys for keyboard only/accessibility users. The toggle would have to be keyboard accessible.


Hi,

instead of writing a fix, you're doing senseless discussions over almost a year now ... could you please close the ticket ? I'm still getting every comment per mail although my email is removed from the cc list.

Thanks,
Thomas
(In reply to comment #86)
> I'm still getting every comment per mail although my email is removed from the cc list.

As the bug's reporter, you get a special treatment here. ;-) (See the Email section in Bugzilla's preferences for why that's the case.)

OTOH since you're the reporter, your request shall be granted: WONTFIX.
Anybody not agreeing with this, feel free to try your luck in a new bug...
Status: NEW → RESOLVED
Closed: 17 years ago
Keywords: uiwanted
Resolution: --- → WONTFIX
Whiteboard: [wontfix?]
Whoever might be interested: I created a new Bug 390989 based on comment #11 here:  The content accesskey should be easily configurable so everyone can simply decide whether webpages might break UI.
You need to log in before you can comment on or make changes to this bug.