Comment 679 for bug 263435

> This patch, instead of killing all events going to the plugin, only kills
> the ones that will generate movement on the page (UP, DOWN, LEFT, RIGHT,
> SPACE...). I don't know about Mac, but on Windows, Java applets (or, at
> least, the ones I've tested) doesn't properly return the event feedback to
> the browser.

That doesn't answer my question. Does the patch kill the events *before* they get to the plugin, or *after*? We must certainly send plugins the arrow keys and space.

> > Are control-t/w/r localized? I suspect they are, and so we can't just
> > hardcode the English letters, but really need the application frontend to
> > tell the plugin which keystrokes are "special".
>
> Yes, there should be a way for enabling/disabling this functionality,

The Firefox frontend should be in charge of this: perhaps the best option is to have an API that the Firefox frontend can call "set browser shortcut keys" and then the Firefox frontend can collect the keys that matter from the <command> elements in the Firefox chrome.

> > Also, for plugins that install subwindows (Acrobat), does this keystroke hook still work? Or is
> > this primarily for Flash?
>
> Yes, it should. In fact, even if it appears to be embedded, Flash is just a
> bunch of windows which share the Device Context with the browser.

Flash is typically a single subwindow. Acrobat is a whole hierarchy of subwindows, and we only hook keystrokes for the toplevel window. That's why I was asking about it.