ZoomOut by Meta key should be disabled.

[jekhor]

Pressing Meta (Win) key in Firefox 12/Debian Linux unstable makes the map zoomed out. This behaviour should be disabled, because the Meta key can be used for global keyboard shortcuts.

Code:

src/map/handler/Map.Keyboard.js

// list of e.keyCode values for particular actions
keyCodes: {
left: [37],
right: [39],
down: [40],
up: [38],
zoomIn: [187, 61, 107],
zoomOut: [189, 109, 0]
},

The Meta key has keycode 0 in FF/Linux.

[mourner]

Thanks, will be fixed.

[ericmmartinez]

The 0 key code was meant to provide support for FF on Mac (specifically FF 14.1 on OS X 10.6.8). I don't have a Linux desktop to test with. I have a fix in mind for this that will (hopefully) be more cross-browser friendly but the code may become slightly less clean as it involves capturing keydown and keypress events and handling things somewhat differently.

Patch to follow.

[mourner]

@ericmmartinez Do you mean that -/_ do not fire 189/109 keycodes in FF/Mac like in all other browsers? That's quite weird...

[ericmmartinez]

The submitted pull request now looks for "+" and "-" keys themselves, rather than trying to pre-map key codes to these characters in some cross-browser way. This should be more future proof if/when browsers change key codes in different releases / on different platforms / etc...

Unfortunately the arrow keys still rely on keyCodes.

[mourner]

@ericmmartinez thanks! But about the the question above? Is it really necessary to rely on two ways of detecting key strokes, or is only done in case of future changes of keycodes and theoretical cross-browser benefits? I couldn't find any info about FF/Mac having problems with keyCodes compared to other modern browsers/OSes.

[ericmmartinez]

It is more because Firefox likes to use 109 while other browsers use 189 as the keyCode for the minus (-) character (107 vs 187 for the plus character too). The W3 is mum as to defining keyCodes (so far as I know) and so (using Firefox as an example) keyCodes might vary between browsers. I thought it safer to switch to looking at the characters rather than the keys. A user presses a key but the user intent is reflected by the character. This change required splitting the handling to be partly in onKeyPress and partly in onKeyDown. The reasoning for this is browser quirks explained in the pull request.

[mourner]

I see your point regarding chartacters vs keycodes, but coming back to original question... You said "The 0 key code was meant to provide support for FF on Mac". So why the 0 key code if 109 or 189 work in all cases? And are there any browser/OS combinations that currently fail with the existing keycode-based approach (theory aside)?

[ericmmartinez]

I think 109/189 and 107/187 should work for everything that I can test with. Whether or not it will "work in all cases" is not known to me since each browser may choose to do things their own way.

Just to clarify a bit more...
107 is the keyDown key code for the plus key (shift+equals) on Firefox. Technically we should be able to remove 61 as well. 61 is the keyDown key code for the equals key (no shift). I originally included 61 in the list of zoomIn key codes because I was unsure if it would confuse people that they have to hit shift+equals in order to zoom in when they can just hit minus (no keyboard modifiers) in order to zoom out.

[mattesCZ]

Hi, the minus sign doesn't work now in firefox. I think adding keyCode 173 to zoomOut should help. Thanks.

[mourner]

@mattesCZ weird, thanks for the report! Will be fixed.