This patch is reasonable, but I'd like to see more interest in this before restoring it upstream, since I think the utility is marginal.

It's presumably easy to write an extension to accomplish the same thing, and from the Chrome ticket (https://bugs.chromium.org/p/chromium/issues/detail?id=31177) it sounds like you can set webkit.webprefs.tabs_to_links=false in some secret settings files to get the OSX behavior, although this will be browser-wide.

This would lock us out of using "q" for other things, and I could imagine we might want to -- maybe some keyboards don't have escape keys, and we'd want to alias q to escape? (Maybe weird mobile workflows?)

I think I'd expect this to throw a JS exception for logged-out users on non-public installs, who won't have a search box. I think the old code avoided this, although possibly by accident.

This also isn't translatable (although the old code wasn't either).

I actually consider the mac behavior to be bad, because it makes navigating via keyboard harder/impossible - I wouldn't enable it even if it is an option.

@epriestley: Do you still don't want this feature upstreamed?

It seems like a few users love this feature and a few users hate it, but the vast majority of users don't use it / care about it.

I also considered just restoring the / behavior for browsers other than Firefox, but elsewhere someone who uses Firefox wanted it back and I think we do no browser detection anywhere now (but maybe I'm just forgetting). I don't think there's a way to feature-detect this behavior.

I looked at Firefox/Mozilla's sites for evidence that they violate this behavior themselves, but couldn't find any. The Firefox default start page actually does focus search when you type / and I was sure I had a slam dunk there, but it just does that for any keystroke.

I'd also forgotten about T2527, but that was additional related mess related to this.

In PHP, I think we now generally deal with cases like this through extensions. Although I'm very hesitant to encourage users to write JS extensions, maybe that's generally a cleaner pathway forward here. There's no real technical reason this couldn't be provided by a server-side extension that emits Javascript, and then we wouldn't have to deal with the preference to turn it off or special-casing escape or a preference to special-case escape.

(That's a "no", right?)

I also tested some other keyboard layouts but none of the ones I checked required Alt to type a "/". For example, in Hebrew the key is just the key labeled "Q" on my US keyboard, with no modifiers.

(My project-reject from earlier was stuck.)