[Fix for #26016] In the docs js: support keyboard events for non-english keyboard layouts

[azerupi]

Like explained in #26016, typing ? had no effect with non-english keyboard layouts in the docs.

This patch seems to resolve this issue, tested with AZERTY keyboard in Google Chrome and Firefox. I haven't tested it with more exotic keyboard layouts or with other browsers though.

This code is based on the information found on: http://javascript.info/tutorial/keyboard-events

More specifically:

The only event which reliably provides the character is keypress.

And

// event.type must be keypress
function getChar(event) {
  if (event.which == null) {
    return String.fromCharCode(event.keyCode) // IE
  } else if (event.which!=0 && event.charCode!=0) {
    return String.fromCharCode(event.which)   // the rest
  } else {
    return null // special key
  }
}

? and S work, escape however does not (on an Azerty keyboard).

It would be good if some people could test it with other browsers and keyboard layouts: http://www.mathieudavid.org/test/rustdoc/std/index.html

Edit:

• swedish layout works on Firefox and Chromium
• french (azerty) mac layout works on Safari

[rust-highfive]

r? @alexcrichton

(rust_highfive has picked a reviewer for you, use r? to override)

[alexcrichton]

Doesn't jQuery have some accessor which does all this for us?

[steveklabnik]

... and wasn't jquery removed recently?

[steveklabnik]

which

[Gankro]

I'm personally cool with not using jquery as much as possible.

(jquery was removed from the book, not rustdoc)

[Gankro]

A deep part of my soul wants these to be cached in a variable, but then I remember this is javascript and it doesn't matter at all.

[alexcrichton]

... and wasn't jquery removed recently?

From rustbook, not rustdoc.

I'm personally cool with not using jquery as much as possible.

I'm worried about the JS becoming a pile of impenetrable lists of platform-specific details for all browsers and weird combinations. I'd much rather have something else take care of all this so we don't have to keep updating little bits like this.

[steveklabnik]

I'm worried about the JS becoming a pile of impenetrable lists of platform-specific details for all browsers and weird combinations

Same, very much so.

[azerupi]

If jQuery has a method I haven't found it, and I didn't add jQuery, it was already there :)

I am totally pro using jQuery, because they do a lot better job at implementing browser support and abstractions. If there is a jQuery way for this I'm all in, but I didn't find any unfortunately.

I could drop the helper function and replace it with just

String.fromCharCode( e.which )

But I have no idea how it behaves in IE and I can't test it.

[azerupi]

@Gankro removing jQuery is in my opinion not really a win. Because it offers so much convenience methods to shorten and simplify the code. It's a lot easier to maintain than vanilla js. On top of that you get good browser compatibility removing / reducing the need to hack your way through it ;)

Also jQuery is used on a lot of websites loaded from the official CDN, if we used that CDN jQuery would most likely already be cached in the users browsers and thus practically bring it's load time to zero.

[Gankro]

jquery is well-known to generally have significant overhead over "plain" DOM manipulations. Rustdoc being snappy is important to me. Especially as we make its render more dynamic in the future.

[Gankro]

That said, there's a reason I don't push hard for removing it ;)

[azerupi]

I am not totally convinced about the pure js vs jQuery performance. Sure jQuery has a bit of overhead because it has support for most browsers etc. But it is designed by a bunch of people who are a lot more skilled than myself and probably most contributors here, they probably know how to get that last bit of performance out of it.

Well written vanilla js can be faster than jQuery but it has to be well written ;)
And, here I speak for myself, I am probably not skilled enough to always know when something is well or poorly written.

One thing that comes to mind though is that it's a lot easier to use other css selectors instead of id's with jQuery because of the convenience methods, and this can drastically slow down the dom manipulations.

I could be wrong, but I think we still have a pretty big marge before we begin to have performance issues in the rustdoc :)

[alexcrichton]

Hm ok, if there's nothing in jquery to already do this then it's probably fine. Can you squash the commits together as well?

[azerupi]

Done :)

[alexcrichton]

@bors: r+ 49b73e4

[bors]

⌛️ Testing commit 49b73e4 with merge 9d67b9f...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt

[Gankro]

We should endeavour to back-port client-side rustdoc fixes as much as possible.

[brson]

Not accepted.