-
2010-05-18
gamma
Using OSX and the current devel-version as of 2010-05-18 the following problem in the editor occurs:
* The keyboard responses to ALT+HotKey - e.g. ALT+B for bold … ALT+Number for heading
In general ALT+X is great, but on OSX ALT+Number and a lot more have special key functions like the curly brackets on ALT+8/9 or square brackets on ALT+5/6 to name only two.
In addition the Safari now doubles the original DW CTRL+ALT+HotKeys: CTRL+ALT+B produces on a highlighted "word": "**word****bold text**" (firefox seams good)
-
2010-06-22
andi
After having a look at
http://support.mozilla.com/en-us/kb/keyboard+shortcuts, it seems that we will not find any single modifier key that isn't used for some (more or less) important browser internal mechanism. So the solution should be a key combo, most likely ALT+CTRL (if that works on Mac?).
-
2010-06-22
andi
I disabled the hotkey javascript, until it is decided what keycombo to use.
-
2010-06-26
andi
The modifier is now CTRL-ALT which should be relatively safe from clashes on any system
-
2010-06-27
ach
CTRL+ALT is probably not a good idea either. This means at least that square brackets cannot be used in the edit textarea using a German keyboard ... Maybe we should instead search for different accesskeys for headlines?
-
2010-06-27
andi
Huh? On my keyboard square brackets are created by ALT-GR+8 and ALT-GR+9?
-
2010-06-27
andi
Okay it seems that under Windows, ALT-GR does fire an CTRL-ALT keyevent for whatever reason. This makes the use of ALT-CTRL as keycombo impossible.
Last idea: use CTRL-ALT on Mac and ALT on PC. I just implemented and pushed it. Needs testing.
-
2010-09-03
gb
Not working for me (Safari 5 or Firefox 3.6.8) on OS X 10.6.4.
-
2010-09-09
andi
Guy, CTRL-ALT+Hotkey doesn't work for you?
-
2010-09-10
gb
Right it does not. I've tried with Safari 5, Firefox 3 and Firefox 4(b4) on a revision of this morning, no luck.
-
2010-09-26
awolf
Ctrl+Alt+Hotkey doesn't work for me either, at least with FFx 3.6 under MacOS. Didn't test it under Linux, though.
Isn't Alt the key that's used under Windows for the access keys of menu bars etc.? At least that's what I remember from using Windows extensively five years ago...
-
2010-10-02
andi
Could you check if the is_macos switch in lib/scripts/hotkeys.js:41 is kicking in correctly:
if(is_macos){
t.modifier = 'ctrl+alt';
}else{
t.modifier = 'alt';
}
if it is, could you try other keycombos and report back what works for you?
-
2010-10-02
molefunk
The script shows up in my safari script console, but none of the accesskeys work. That goes for home page shorcut, as well as editing.
-
2010-10-02
molefunk
Okay, I'll try again...
if(is_macos){
alert( "Alive and kicking!" );
t.modifier = 'ctrl+alt';
}else{
t.modifier = 'alt';
}
Gives me a nice popup both on entering the page and on editing the page. No good news, though...
-
2010-10-02
gb
It works perfectly with alt only i.e. no test needed for macos.
--- a/lib/scripts/hotkeys.js
+++ b/lib/scripts/hotkeys.js
@@ -37,12 +37,7 @@ function Hotkeys() {
this.initialize = function() {
var t = this;
- //switch modifier key based on OS
FS#1958
- if(is_macos){
- t.modifier = 'ctrl+alt';
- }else{
- t.modifier = 'alt';
- }
+ t.modifier = 'alt';
/**
* Lookup all anchors with accesskey and register event - go to anchor
-
2010-10-02
gb
Works ok with Firefox 3.6.8, Firefox 4.0 beta4, Safari 5.0.2 and Chrome 6.0 on MacOS X 10.6.4
Works ok with Firefox 3.6.10 and Safari 5.0.1 on MacOS X 10.5.8
-
2010-10-02
andi
We can't use the ALT Key on MACs because it blocks the use of brackets (produced by ALT-Number).
-
2010-10-02
gb
Ctrl+key is far less used on a Mac.
-
2010-10-02
molefunk
Mediawiki uses Ctrl+Alt for previewing and saving, etc. so it would make sense to keep it like that.
-
2010-10-03
andi
Alright. Let me summarize the current problem (because it differs from the original description):
* we can't use ALT as the hotkey for Macs because the Mac keyboard layout needs the ALT key for various common special chars like brackets or pipe symbols
* CTRL-ALT seems to be the best choice for Macs as CTRL itself is rarely used on mac, combined with ALT it should be relatively collision free
* We have confirmed that we can reliable detect Mac OS in JavaScript
* However we have reports that the keycombo CTRL-ALT simply doesn't work currently. However we don't know why, yet.
Someone with a Mac and some JavaScript experience needs to dig through the code and check if the Keycodes are detected correctly or what else goes wrong here.
-
2010-10-03
ChrisS
Alright. Let me summarize why its happening.
* current code tries to be smart and when it recognises its working on MacOS, it translates a 'CTRL' key modifier to a 'CMD' (or apple) key modifier (metaKey on event object).
* key codes created when the 'CMD' key is held down are wierd - ie. they are not what you'd expect.
So CTRL+ALT for mac is being translated to CMD+ALT which results in wierd keycodes which don't match the registered keycode, so the hot key is never fired.
Solution is to forego the translation of 'CTRL' to 'CMD', which is probably what we are after by choosing a different set of modifiers for Mac's anyway.
-
2010-10-03
gb
-
2010-10-11
molefunk
Just wanted to specify that still there are shortcomings in the shortcuts for Mac OSX.
* I have most of the editing tools working, but lists are not working (bulleted and numbered).
* Preview and Save works, but not Edit or Homepage. Surely there may be others as well, that I'm not aware of...
* The tooltips are the same for Mac and Windows, although the keys are obviously different.
Unfortunately I haven't been able to find a working solution, but I hope others may!
-
2010-10-11
ChrisS
'E' (ctrl+alt+e) works fine for me. Safari 5.0.2, FF 3.6.3 & FF 3.6.10
I concur for 'H','-' & '.'.
-
2010-10-11
ChrisS
Adding 'alt' into the key combination may result in wierd values for event.keyCode, event.charCode and event.which. That is the case for 'h','-' & '.'.
ctrl+alt+'.' FF: 0, 46, 46; Safari: 46, 46, 46
ctrl+alt+'-' FF: 0, 31, 31; Safari: 31, 31, 31
ctrl+alt+'h' FF: 0,104,104; Safari: 8, 8, 8
My experiments suggest that these three hot keys don't work in Windows based browsers. In addition alt+e doesn't work in IE.
Problem seems to be with hotkeys.js.
(1) click() isn't a valid function for anchor elements (at least in Gecko based browsers).
(2) firebug indicates that when hotkeys.js attempts to call 'click()', the object its using is undefined.
I can fix 1 & 2. Given the current state, I believe its better doing this properly with jquery and letting jquery resolve any crossbrowser issues.
-
2010-10-12
adrianlang
So you vote for disabling the JS hotkeys again for Anteater?
-
2010-10-19
andi
okay I fixed the "click() isn't a valid function for anchor elements"-problem. that should make ALT-H work.
We'd probably need to find different hotkeys for lists to solve them reliably.
Still, the question remains: Should we disable JS hotkeys again, for Anteater?
-
2010-10-22
andi
Since we don't seem to find a working solution right now. I'll disable JS hotkeys again and we see if we can get them working in the next release.
-
2012-04-27
marc23
Stable on Firefox 3.6.8, above versions cause some problems starting 11.
Marc @
http://cadeaux-en-ligne.net
-
2012-07-19
MortenB
After updating from Dokuwiki 2012-01-25a to 2012-01-25b and Firefox 14.0.1 at once I'm experiencing trouble with the accesskeys. It used to work fine.
Ctrl-alt-s does nothing.
Ctrl-alt-1 outputs a '1'.
Ctrl-alt-b works as expected, inserts bold code.
Tried this on two installations with Firefox. Also, in Safari it works fine.
-
2012-07-28
andi
Morten, nothing changed between a and b in regards to access keys.
-
2012-07-28
andi
I'd like to reintroduce javascript based keys someday. One solution to avoid any problems with clashes could be to allow users to chose the modifier key themselves with another little option at the bottom of the editor. similar to the linewrap/size buttons.
-
2012-07-28
MortenB
I'm suggesting something might have changed in Firefox.
-
2012-08-19
MortenB
Seems like something DID change in Firefox. See
http://forums.mozillazine.org/viewtopic.php?f=38&t=2503397
At any rate it blew my setup, and probably others. Applying the fix in the link works, though.
It seems the standard configuration of Dokuwiki, Firefox and OSX blows access keys. Just so you know.
-
2012-08-19
ach
Why do you say it that combination "blows access keys"? If I read your link correctly, accesskeys still work as they should, the only thing that has changed is the key combination: "access keys have changed on the Mac from CTRL to CTRL+ALT". So, that means *all* accesskeys of *all* websites and web applications will have changed in Firefox on a Mac, not just DokuWiki's, right?
The only bad thing is that Firefox obviously hasn't communicated it properly. :(
I think on
https://www.dokuwiki.org/accesskeys we should not tell the users at all which accesskey combination to use, but rather link to a constantly updated reference like
http://en.wikipedia.org/wiki/Access_key#Access_in_different_browsers (there you will find the update on Mac Firefox 14 is correct).
-
2012-08-19
MortenB
No, see my former comment (19 July). Ctrl+alt combinations worked before, now they don't.
Why were I testing ctrl+alt, you may ask, if Firefox on Mac used ctrl before?
Because Dokuwiki back in 2010 overrided accesskeys on Mac, changing from ctrl to ctrl+alt. See
https://github.com/splitbrain/dokuwiki/commit/ce19c3413a33bcdabb5d71ec713555b540b12c84
-
2012-08-19
ach
Ah, okay, I wasn't aware of that.
Why exactly are we overwriting accesskeys at all? I know this is a complicated subject (seeing how long this thread is ;-) ), but I missed/forgot what the original reasoning behind the script was in general?
-
2013-08-01
bug
We're not overwriting access keys, we're trying to find a good combination that works also properly on OSX and on different browsers on OSX.
-
Related tasks: