Pressing Shift cancels OpenLinkMode on Linux

Hello,

My usual workflow is the following:

1. Press `f` to enter OpenLinkMode;
2. Locate the key of the link I want to open (let it be `E` for example);
3. Decide if I want to open it in the current or in a new tab;
4. If in the current tab, hit `E`;
5. If in the new tab, hit `Shift+E`.

On Windows it works fine for me. However, on Linux step 5 is broken: as soon as I press `Shift`, OpenLinkMode is cancelled.

This happens because on Windows the `keyIdentifier` of keydown event equals to `"Shift"`, while on Linux it equals to `"U+00A0"` (for LShift) or `"U+00A1"` (for RShift).

I created a [bug for Webkit](http), because I believe your code is correct: key identifiers should be textual according to [W3C spec](http://www.w3.org/TR/2006/WD-DOM-Level-3-Events-20060413/keyset.html#KeySet-Set-h2) (at least in a way I understand this document :smile:).

But I don't feel like waiting for this bug to be resolved, it is very annoying!
That's why I propose this pull request as a simple workaround.

In a long-term, I think you should consider making your code `event.keyIdentifier`-agnostic, because I can see this is not the first patch for it. Unfortunately, I don't have time to help with that right now.

So anyway, please have a look and let me know if it makes sense and/or if you want additional details.

Platform: Kubuntu 14.10, Google Chrome 39.0.2171.71, Webkit 537.36
This has the same effect as `return ""`, but requires us to do some extra work to get there; just return here. I notice the linux webkit behaviour is also wonky for alt and ctrl (and possibly also on Mac?), so this whole conditional might be better as

```
return "" if (event.keyCode in [keyCodes.shiftKey, keyCodes.altKey, keyCodes.ctrlKey])
```