Comment 643 for bug 263435

(In reply to Mark Clements from comment #627)
> My understanding of the problem (and I'm sure someone will correct me if I'm
> wrong) is that currently Firefox loads the plugin in a separate process and
> therefore has *no control* over how it handles keyboard events.
>
> In other words, when a plugin has the focus, the chain of events is as
> follows:
>
> KEYPRESS -> OS -> PLUGIN
>
> and not
>
> KEYPRESS -> OS -> FIREFOX -> PLUGIN
>
> Therefore to fix this, the way plugins work needs to be re-engineered so
> that Firefox sits in the chain. From my reading, this is the hard bit that
> is stopping this bug being fixed. Once that has been resolved, it will be
> trivial for Firefox to filter which keys get passed to the plugin, and we
> can have a nice bit of bike-shedding to decide on the details.
>
> As far as I can see (and again, I may be wrong) the Advanced Key Handling
> document is an attempt to get plugin vendors to respect certain key
> combinations as 'browser reserved' and therefore to ignore them, passing
> them back to Firefox, which would result in the following chain:
>
> KEYPRESS -> OS -> PLUGIN -> FIREFOX
>
> However, I agree with previous comments that this is a non-starter.

I doubt that the plugin container is an issue. It always worked like this. Far before the plugin container.
The simple workaround they did in (preventing some keyboard shortcuts from being stolen by the plugins) chrome was recommended here several times. It also would have worked swell all these years, until a more elegant solution is possible. (If ever)
Also I didn't see any flash/java stuff that had a crazy enough developer to use shortcuts that the browsers use for the necessary events. (tab switching/closing, jump to urlbar, etc...)