With keyboardDefaults on, k and m keys interfere with text boxes

[openlayers]

When using the KeyboardDefaults control, if a user enters a k or m in a text box on the page, the map will zoom in/out. This is undesirable.

[jachym]

confirm,

patch added, however, due to #864 could not test on IE

[jachym]

Fix "k" and "m" keys for zooming in and out on Firefox

[openlayers]

OSM dev is asking for this bug to be solved, so users can navigate and zoom the maps with keyboard controls. Higher priority.

[crschmidt]

If someone wants to see this bug solved, then they should offer a patch. The one here hasn't applied for weeks, and was never really a great solution anyway.

The real source behind OSM's problem is unrelated to the k/m keys, and is instead tied to the fact that OpenLayers keyboard events are global, and not related to interaction with the map. A solution to this would require oing more event registration on the map and document to determine when to turn key handling on/off. A partial solution to this doesn't solve OSM's requests.

[crschmidt]

Not touched since 2.7, moving forward.

[gregers]

Check document.activeElement to avoid events from form elements

[gregers]

In my opinion, this is not a problem for just the 'k' and 'm' keys, but all keyboard events from form elements. Here is an extract of a message I posted to the dev-list June 10th (no response):

This is particularly nasty when a user is typing text in an input field, and use arrows to choose from a auto-suggestion.

I looked into the problem yesterday, and it turns out that Safari, as the last major browser, added support to document.activeElement in Safari 4.0 released two days ago. This was a proprietary property in IE6, but has become the defacto standard in other browsers. I've successfully tested this in IE6-8, FF3, Opera 9.6, Chrome 2.0.172 and Safari 4.0. Luckily IE6 already has support, and users of other browsers update on a more regular basis. So this should be available on a large majority of users very soon. The best backwards compatibility option I've found is to add focus and blur events on all form elements (naaaasty!), and set document.activeElement in the handler. This should of course only be done if (!document.activeElement). But I suggest we ignore these users, as this will not be released before OpenLayers 2.9 in a few months, and hopefully most Safari users have upgraded by that time.

---

The patch I submitted has a switch to disable KeyboardDefaults for browsers that doesn't support document.activeElement:

new OpenLayers.Control.KeyboardDefaults({disableForBrowsersWithoutActiveElement:true})

[cdauth]

What I don’t like about the patch is that you also disable the keyboard control when the active element is a button. I would suggest to only disable it for select, textarea and input elements when the type of the input elements is not button, clear, submit or checkbox (because for them you don’t use the arrow keys).

I could also find out the active element using evt.target. I don’t know if the browser support for that is any better in older browsers, if so, I suggest to use it as an alternative.

[cdauth]

I of course meant “reset” instead of “clear”.

[gregers]

The reason I included all form related elements was because they are the DOM elements that can have focus. It sounds reasonable to ignore buttons and the other you mention, as long as the controller doesn't capture TAB, RETURN, SPACE or any other key that is used for the elements or form navigation.

Originally, I was going to add the activeElement test to Keyboard.handleKeyEvent, so it's global for all that use keyboard handling. This might be something useful for other controllers as well. I tried to start a discussion on the mailing list, but no response: --- This should probably be extracted to a Util method (Util.isFormElementActive).

Does this seem like the Correct[TM] solution? Should this be done in KeybardDefaults or at a higher level? ---

But I'm not so sure if it's a good idea to do the change you suggest if it's in Util. Since we then don't know what it will be used for, and others might need it to ignore buttons as well. Maybe send an array of element names as an (optional?) argument?

Regarding "evt.target", I don't think it's possible. But if you want to spend time on a nice-to-have feature for outdated browser. Go ahead ;)

[cdauth]

You cannot make a function that generally works in all cases. Links can also have the focus, and they are also clickable using the Return key. Some people might use their keyboard to navigate on a whole page, so no matter what the active element is, they might use the arrow keys to navigate through the text on a page.

I think it is the better solution to leave it in the KeyboardDefaults class and don’t block buttons because we don’t use Return or Space. The better solution would be to activate the Control on mouseover on the map and disable it on mouseout, so we would have the same behaviour as Flash or Java for example and it would still work with multiple OpenLayers maps on one page. But I don’t know if the OpenLayers library should enable and disable the KeyboardDefaults or if the user adding it to the map should do that.

Why do you think “evt.target” is not possible? At least it works in a current Firefox. Someone should find out if the browser support is any better than with document.activeElement.

[cdauth]

I uploaded a new version of your patch that only disables the Control for text fields, select boxes and radio buttons and tries to use evt.target if document.activeElement fails.

[gregers]

cdauth: Sorry I didn't respond earlier. Was going through my old patch list when upgrading to 2.9.1 when I found this issue. Unfortunate this issue wasn't brought up during the release process. Your patch looks good. I'll give it a try.

[cdauth]

Patch that disables KeyboardDefaults if the focus is on a text input field, a select box or a radio button.

[cdauth]

I believe that my previous patch did not work (event.target vs event.srcElement), so I have uploaded a new version.

[ossipoff]

Different approach to solving the issue. Option on the keyboard handler allows for a different element than document to be observed.

[ossipoff]

I just uploaded my solution to the problem. Instead of keyboard events being catched globally on the entire document I changed the KeyBoard handler so it can be set to listen to a specific DOM element. In this case the map div. This fix requires the map div to have focus. In firefox this requires the tabindex attribute to be set on the div, and a click handler on the map object to set the focus when the map is clicked.