Last modified: 2012-03-09 13:09:51 UTC
All Firefox versions use alt-shift as access key, but the init-function in mw.util only sets this for Firefox 2. This seems to be a simple copy and paste mistake, since in wikibits.js there is a "if ( is_ff2 )" too, but with the comment "note that FF3+ is included here!". The wrong access key isn't shown since it is still handled by the function in wikibits.js.
Urghh... is there a reason that there are two versions of this function and only one is used??
r91652 on trunk should fix this (doing > '1' rather than >= '2' so it won't break on future Firefox 10 through 19 :) However the fact that this code doesn't get run is very worrying.
(In reply to comment #0) > mw.util only sets this for Firefox 2. This seems to be a simple copy and paste > mistake, since in wikibits.js there is a "if ( is_ff2 )" too, but with the > comment "note that FF3+ is included here!". > > The wrong access key isn't shown since it is still handled by the function in > wikibits.js. The legacy wikibits.js code is as follows: http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/skins/common/wikibits.js?revision=86108&view=markup#l183 > > } else if ( is_ff2 ) { > tooltipAccessKeyPrefix = 'alt-shift-'; > } > If "is_ff2" means "ff2 or higher" then I missed that. I see the comment in the definition of window.is_ff2 now though, brion fixed that in r91652 (marking this bug as fixed). (In reply to comment #1) > Urghh... is there a reason that there are two versions of this function and > only one is used?? Yes, the reason is backwards compatibility and quarantine of the legacy library. The legacy script should not be modified neither should it be referenced/used by core. There are rewritten, modernized or otherwise succeeded versions in the mediawiki object library. if the legacy variable is used then that's a bug!
The legacy script is the only one that actually gets run, as can be trivially confirmed by loading it in your browser and checking.
(In reply to comment #4) > The legacy script is the only one that actually gets run, as can be trivially > confirmed by loading it in your browser and checking. retitling bug. Maybe I should assign resolution to krinkle?
wikibits.js is always loaded -- it's required so that code in it can be used by various things. The *parts of wikibits.js that have been reimplemented in mediawiki.util.js* should be *removed from* wikibits.js, and the equivalent function / var should be replaced with shims to the new version, and the new version *should actually be used*.
(In reply to comment #4) > The legacy script is the only one that actually gets run, as can be trivially > confirmed by loading it in your browser and checking. For some reason the calls to the legacy script were never removed from the on load hook. Fixed in r91660. The fact that legacy wikibits.js is loaded is not a bug and happens in all browsers all the time (not related to Firefox in any way). So rephrasing bug summary. (In reply to comment #6) > wikibits.js is always loaded -- it's required so that code in it can be used by > various things. Exactly. It's been deprecated and should no longer be used, but it's still used by extensions, gadgets and local site scripts and user scripts. For backwards compatibility the legacy functions need to stay as-is untill they are removed in a future version of MediaWiki. See also: http://www.mediawiki.org/wiki/Thread:Talk:ResourceLoader/JavaScript_Deprecations/Deprecation_plan I'm all open to revisit this plan, but whatever we do it should be documented and be acted on consistently. Since it is already in effect on the progress for the last year Im a bit hesitant to change that. Thanks, Krinkle
I'm seeing the same problem on Chromium 12.0.742.112 (90304) Ubuntu 11.04, where although the tooltip says I should use "alt-f", the fact is that I need to use "alt-shift-f" if I want to focus on the search box on MW.org.
I also use Chrome and read an blog article recently (http://googlesystem.blogspot.com/2012/02/keyboard-accelerators-in-google.html) in which is claimed, that you can override Chrome's default behavior for alt+f and so on. We could also do this with the search shortcut, so users wouldn't have to distinguish between e.g. IE and Chrome, what shortcut to use!
MediaWiki doesn't have any influence on which key combination will trigger an accesskey. We merely try to guess what it is and show it to the user in the tooltip. The bug is currently named: "mw.util.tooltipAccessKeyPrefix should be alt-shift for Firefox 3+ and Chromium 12" * In Chrome 15, 16 and 17 (Mac) the accesskeys are triggered by 'ctrl-option-' * In Firefox 8 and 9 (Mac) the accesskeys are triggered by 'ctrl-' Currently both of these are also correctly detected by mw.util.tooltipAccessKeyPrefix. Feel free to re-open with more actionable information: * Which browser / version / OS should report a different accesskey key that is currently wrongly detected ?
In Chrome 17 on Windows 7, the tooltip says: [alt+f], but it should be [alt+shift+f], as alt+f opens Chrome's menu. However, in my own opinion it would still be better to change the key combination for the accesskey on Chrome into [alt+f] instead of [alt+shift+f], which is definitely possible as I explained in comment 9. This would make it much easier for the user to remember the shortcut, because he then doesn't need to remember the shortcut for different browsers.
(In reply to comment #11) > However, in my own opinion it would still be better to change the key > combination for the accesskey on Chrome into [alt+f] instead of [alt+shift+f], > which is definitely possible as I explained in comment 9. This would make it > much easier for the user to remember the shortcut, because he then doesn't need > to remember the shortcut for different browsers. I disagree. For one, it's not possible to change the accesskey in the browser (it's possible to listen for keypresses and emulate/fake a trigger of the accesskey, but that's not the same and might come with other bugs). Aside from that, I think it's more important that users have the same accesskey triggers within a browser across different websites, then to have them be same within a website across different browsers.
After reading the wikipedia article about accesskey, I agree with you, that it is somehow a browser specific thing and we shouldn't "emulate/fake" any keystrokes without any important reasons. By the way, I just figgured out, that Firefox also uses [alt+shift+f], but in contrast to Chrome it displays the shortcut correctly in the tooltip. Therefore, the issue of changing the tooltip in Chrome to [alt+shift+f] remains.
(In reply to comment #13) > the issue of changing the tooltip in Chrome to [alt+shift+f] > remains. Yep, going to fix that right away. I tried Chrome 16/17 in a Windows VM just now, looks like the 'official' accesskey trigger is alt and not alt-shift (for history, talk, new section etc. the alt- works, except for alt-f since that triggers the Chrome "wrench menu", and apparently alt-shift-f does not). I'm not sure whether this is a documented ability in Chrome or a bug, but since pressing an additional shift key also works for all other accesskeys in Chrome, promoting 'alt-shift-' as prefix for Chrome on Windows makes sense.
(In reply to comment #14) > Yep, going to fix that right away. > > I tried Chrome 16/17 in a Windows VM just now, looks like the 'official' > accesskey trigger is alt and not alt-shift (for history, talk, new section etc. > the alt- works, except for alt-f since that triggers the Chrome "wrench menu", > and apparently alt-shift-f does not). I'm not sure whether this is a documented > ability in Chrome or a bug, but since pressing an additional shift key also > works for all other accesskeys in Chrome, promoting 'alt-shift-' as prefix for > Chrome on Windows makes sense. Yeah, i also think this will make sense, but if you're keen on using/adopting [alt+f] it is definitely possible to override Chrome's default action (opening the "wrench menu") somehow (comment #9). Unfortunately I'm not that experienced in it, so I cannot help you with that.
When I acess wikipedia using Mozilla/5.0 (X11; U; Linux x86_64; pt-br) AppleWebKit/531.2+ (KHTML, like Gecko) Version/5.0 Safari/531.2+ Debian/squeeze (2.30.6-1) Epiphany/2.30.6, MediaWiki suggests the use of "ctrl-shift-" but it should suggest "alt-shift-".
(In reply to comment #16) > When I acess wikipedia using Mozilla/5.0 (X11; U; Linux x86_64; pt-br) > AppleWebKit/531.2+ (KHTML, like Gecko) Version/5.0 Safari/531.2+ Debian/squeeze > (2.30.6-1) Epiphany/2.30.6, MediaWiki suggests the use of "ctrl-shift-" but it > should suggest "alt-shift-". Please open a separate bug for this.
* Firefox fix: r91652 * Chrome fix: r113214
(In reply to comment #17) > Please open a separate bug for this. Done: Bug 35080.
