In-page search broken on mac (turn off shortcuts?)

[coke]

So that we don't lose this issue:

command-F on chrome on the mac on the live site focuses on the site search box, overriding the builtin client functionality.

[coke]

For those stuck here with me, you can manually go to Menu -> Edit -> Find or use command-G for search next (both of these open the in-page search)

[coke]

@finanalyst - where's the code that registers the keypress handler for this?

[finanalyst]

@coke In Website/plugins/page-styling/page-styling.js At line 80, the structure pageOptionsState is defined for the default state, line 82 defines the 'search' option. Then at 139, listeners are attached for the pageOptions options.

The default options cannot yet be changed. The idea was to make this configurable in the same way as search options are separately configurable. This is done by creating a modal page with buttons/radio to change the config state. You can see how this is done by looking at the *.js code in Website/plugins/options-search/

When I first implemented the keyboard short-cuts for the top page, the documentation indicated that Mac OS mapped a key onto Alt. So, the only meta keys needed were Alt and Ctrl. This does not seem to be the case. So I think the solution will be to add another field (or perhaps two) to the pageOptionsState for the Mac meta keys, and then to check for Mac and those keys when the listeners are attached.

To work-around having a configuration pop-up, we could have defaults set for Mac and for PC in pageOptionsState, and for the correct set of options to be used depending on the OS.

Except, I don't know how to determine the OS of a user accessing a web page. It should not matter. Or maybe the key event generated by a keyboard key contains the necessary information.

[dontlaugh]

To be honest, I don't think we should take over any key combos at all. I'd be in favor of getting rid of all of them. I'm not convinced the convenience of providing a custom keyboard shortcut, even a configurable one, is worth the trouble.

Downsides:

• browsers have built in keyboard combinations and users expect them to work
• Taking over or overloading common shortcuts is clearly a lot of work
• Assistive technologies like keyboard macros may depend on the native browser controls

Lets get rid of shortcuts or if you are really attached to them, lets just flip the defaults to get things working again for native browser controls. Do this before implementing auto-configuration, because that's going to be hard and error prone, imo.

[finanalyst]

@dontlaugh the request for keyboard shortcuts came from the community after I started working on the documentation site. I dont believe the old website had keyboard shortcuts.

I'm happy to remove them. But before I do, perhaps we should find out from those who wanted them if there is still a need.

Also: the keyboard shortcuts for the main window are different from the keyboard shortcuts for the Search options, which only work from search window, and which can also be changed using the search popup.

[dontlaugh]

Understood. I do recall seeing the initial requests. What did Winston Churchill say about keyboard shortcuts? "The browser defaults are the worst, except for all the others"?

[dontlaugh]

No love for my Winston Churchill joke? Tough crowd.

[coke]

I'm fine with removing them. I don't think they're adding enough value where they're working to compensate for the fact that they are overriding the browser.

[finanalyst]

@coke can we close this issue now?