DokuWiki

IMPORTANT!

This is the old issue tracking system for DokuWiki. Issues can not be added here anymore. Pleaser refer to https://github.com/splitbrain/dokuwiki/issues for the new system.

IMPORTANT!
Tasklist

FS#1958 - Special Keys on OSX broken by DW hotkeys

Attached to Project: DokuWiki
Opened by Gerry Weißbach (gamma) - Tuesday, 18 May 2010, 13:14 GMT
Last edited by Andreas Gohr (andi) - Friday, 22 October 2010, 09:30 GMT
Task Type Bug Report
Category CSS, XHTML, JS, Browsers
Status Requires testing   Reopened
Assigned To Christopher Smith (ChrisS)
Guy Brand (bug)
Guy Brand (gb)
Michael Klier (chi)
Operating System All
Severity High
Priority High
Reported Version devel (not released)
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 2
Private No

Details

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)
This task depends upon

Comment by Andreas Gohr (andi) - Tuesday, 22 June 2010, 16:38 GMT
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?).
Comment by Andreas Gohr (andi) - Tuesday, 22 June 2010, 17:00 GMT
I disabled the hotkey javascript, until it is decided what keycombo to use.
Comment by Andreas Gohr (andi) - Saturday, 26 June 2010, 11:57 GMT
The modifier is now CTRL-ALT which should be relatively safe from clashes on any system
Comment by Anika Henke (ach) - Sunday, 27 June 2010, 17:09 GMT
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?
Comment by Andreas Gohr (andi) - Sunday, 27 June 2010, 17:34 GMT
Huh? On my keyboard square brackets are created by ALT-GR+8 and ALT-GR+9?
Comment by Andreas Gohr (andi) - Sunday, 27 June 2010, 18:55 GMT
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.
Comment by Guy Brand (gb) - Friday, 03 September 2010, 17:57 GMT
Not working for me (Safari 5 or Firefox 3.6.8) on OS X 10.6.4.
Comment by Andreas Gohr (andi) - Thursday, 09 September 2010, 11:46 GMT
Guy, CTRL-ALT+Hotkey doesn't work for you?
Comment by Guy Brand (gb) - Friday, 10 September 2010, 07:52 GMT
Right it does not. I've tried with Safari 5, Firefox 3 and Firefox 4(b4) on a revision of this morning, no luck.
Comment by Andreas Wolf (awolf) - Sunday, 26 September 2010, 11:34 GMT
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...
Comment by Andreas Gohr (andi) - Saturday, 02 October 2010, 10:46 GMT
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?
Comment by Eivind Morland (molefunk) - Saturday, 02 October 2010, 11:31 GMT
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.
Comment by Eivind Morland (molefunk) - Saturday, 02 October 2010, 11:52 GMT
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...
Comment by Guy Brand (gb) - Saturday, 02 October 2010, 12:17 GMT
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
Comment by Guy Brand (gb) - Saturday, 02 October 2010, 12:38 GMT
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
Comment by Andreas Gohr (andi) - Saturday, 02 October 2010, 12:40 GMT
We can't use the ALT Key on MACs because it blocks the use of brackets (produced by ALT-Number).
Comment by Guy Brand (gb) - Saturday, 02 October 2010, 13:14 GMT
Ctrl+key is far less used on a Mac.
Comment by Eivind Morland (molefunk) - Saturday, 02 October 2010, 13:51 GMT
Mediawiki uses Ctrl+Alt for previewing and saving, etc. so it would make sense to keep it like that.
Comment by Andreas Gohr (andi) - Sunday, 03 October 2010, 10:08 GMT
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.
Comment by Christopher Smith (ChrisS) - Sunday, 03 October 2010, 11:36 GMT
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.
Comment by Guy Brand (gb) - Sunday, 03 October 2010, 11:42 GMT Comment by Eivind Morland (molefunk) - Monday, 11 October 2010, 12:12 GMT
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!
Comment by Christopher Smith (ChrisS) - Monday, 11 October 2010, 13:03 GMT
'E' (ctrl+alt+e) works fine for me. Safari 5.0.2, FF 3.6.3 & FF 3.6.10

I concur for 'H','-' & '.'.
Comment by Christopher Smith (ChrisS) - Monday, 11 October 2010, 15:17 GMT
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.
Comment by Adrian Lang (adrianlang) - Tuesday, 12 October 2010, 07:34 GMT
So you vote for disabling the JS hotkeys again for Anteater?
Comment by Andreas Gohr (andi) - Tuesday, 19 October 2010, 17:50 GMT
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?

Comment by Andreas Gohr (andi) - Friday, 22 October 2010, 09:26 GMT
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.
Comment by marc (marc23) - Friday, 27 April 2012, 10:10 GMT
Stable on Firefox 3.6.8, above versions cause some problems starting 11.

Marc @ http://cadeaux-en-ligne.net
Comment by Morten Nielsen (MortenB) - Thursday, 19 July 2012, 19:42 GMT
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.
Comment by Andreas Gohr (andi) - Saturday, 28 July 2012, 09:15 GMT
Morten, nothing changed between a and b in regards to access keys.
Comment by Andreas Gohr (andi) - Saturday, 28 July 2012, 09:18 GMT
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.
Comment by Morten Nielsen (MortenB) - Saturday, 28 July 2012, 13:21 GMT
I'm suggesting something might have changed in Firefox.
Comment by Morten Nielsen (MortenB) - Sunday, 19 August 2012, 09:37 GMT
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.
Comment by Anika Henke (ach) - Sunday, 19 August 2012, 10:37 GMT
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).
Comment by Morten Nielsen (MortenB) - Sunday, 19 August 2012, 11:50 GMT
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
Comment by Morten Nielsen (MortenB) - Sunday, 19 August 2012, 11:52 GMT
Comment by Anika Henke (ach) - Sunday, 19 August 2012, 12:37 GMT
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?
Comment by Guy Brand (bug) - Thursday, 01 August 2013, 09:37 GMT
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.

Loading...