Mature the list of predefined white listed keystrokes

The ones you've listed will work for me as I use safari but they're not sufficient for Firefox, IE, Opera, etc.

I think it's very dangerous to presume anything about keystrokes and I'm pretty sure that on IE for example, you can't actually prevent or intercept certain keystrokes such as alt+f.

Why not just allow unhandled keystrokes to go through to the browser irrespective of what they are? What's the downside?

I understand that they are not sufficient for browsers other then Safari, thus the ticket. I am not sure if there is a downside, or if it possible, but boucher has said that they decided upon using a white list. I do not know the inner workings of the key event handler in obj-j, but it may not be possible to check if an event is actually used. Again, I'm not a fan of whitelisting every keystroke we can think of, but I'm saying that there should be more then there is.

This came out of me checking out 280slides, and trying the change windows. I hit command-and nothing happened. They were not using the command for anything, they had just not though of passing it to the browser.

I'd like to see a solution that takes into account key equivalents. For example, if there is a menu item that has its key equivalent set to cmd+N, then eat it obviously, if not, don't.

I think this needs to be changed to "whitelist" everything by default and let the app developer "register" for the keys he's interested in, or at least make that an option. We'll never be able to predict exactly which key combinations are important for each browser and each user.

For example, in Safari I like to hit command-option-C to bring up the web inspector. This probably isn't common among web users, but I do it all the time and it's maddening to not be able to do it, even though the Cappuccino app most likely doesn't need the command-option-C shortcut for anything. Sure you could whitelist that particular one, but there's dozens of others that other people might want.

That's the idea behind examining key equivalents. If the developer gives a menu item the command+N key equiv, clearly he wants to receive it. He shouldn't then additionally have to call REGISTER_ON_WHITELIST("N", CPCommandKeyMask);

Yeah, I think we're using the term "whitelist" differently. I took it to mean "add key combos you don't want Cappuccino to eat to the whitelist" and I think you're saying "add key combos you want Cappuccino to eat to the whitelist".

Whitelist implies we only let certain ones through, but from which perspective, the browser or Cappuccino? We could be letting them through from the browser to Cappuccino, or letting them through from Cappuccino to the browser.

Either way, I think we agree that by default all key combos should be let through to the browser, and only ones that are registered explicitly by the app developer, or detected as being a key equivalent in a menu, should be "eaten" by Cappuccino.

What about simple keypresses (a, b, c...)?

Simple key presses have to be "eaten" by cappuccino, if not text will never work. You shouldnt have to register for the alphabet in a view that expects keystrokes. It's not a big deal to eat them since they generally don't do anything anyways.

I've attached the proposed change. Here's the example usage, taken from 280 Slides:

    // Set up the keys that we want to prevent defaults for

    var characterKeys = ['s', 'o', 'n', 'b', 'i', 'u', 'a', 'e'];
    [[CPDOMWindowBridge sharedDOMWindowBridge] preventCharacterKeysFromPropagating: characterKeys];

    var keyCodes = [37, 38, 39, 40];
    [[CPDOMWindowBridge sharedDOMWindowBridge] preventKeyCodesFromPropagating: keyCodes];

Should have noted previously that you can prevent both character keys, and key codes. So, if I want to use command/ctrl + b in my app, I can register for 'b'. If I want to use command/ctrl + left arrow, I can register for the left arrow key code (37).

Shouldn't you register for combinations of keys? (i.e. with meta, ctrl, etc)

These only apply to command/ctrl. We capture everything else. it's not worth the effort (at least not right now) to try to do anything more complex.