We currently send all keys to plugins on Windows. This causes us to miss important system keys like the ALT key. This bug is about fixing ALT keys in plugins on Windows. Steps to repro: 1. Load testcase (sorry it's internal), click in text field 2. Hit ALT (or F10). This should take you to the menus. * Using ALT+Letter should open that menu. Actual Retuls: ALT does nothing.

So here's a patch with my first attempt. ALT keys seems to work now. The patch causes the parent widget to the plugin to take focus in the case that a system key event is recieved in the plugin window message pump. It then dispatches the event to nsWindow rather than the plugin. One question I have is what should happen when ALT is hit twice? With this patch, the plugin looses focus. Not sure if we'd even be able to reset focus back to the correct spot inside the plugin. In Opera, it doesn't appear that focus gets lost at all. I'd be nice if I didn't have to set focus to my parent widget in order to get arrow keys to work in the menus.

will this patch fix bug 78414 too ?

no, this only fixes ALT keys. Other shortcuts like CTRL+L won't work with this patch unless you first hit ALT to give the menus focus.

It would be nice if there was a way menus could automatically be modal when needed and return focus to the previous widget when done so focus state doesn't have to change on the plugin.

*** Bug 78414 has been marked as a duplicate of this bug. ***

talking with Aaron, we need a key to give focus to the document's window when the plugin has focus. He suggested in bug 78414 to use SHITFT+ESC but that seems to be sent to plugin windows as regular keys. From the plugins triage meeting, we were thinking of using [ALT] + [~] to give focus to the document because it sends special WM_SYSCHAR events. Once focus is on the document, other shortcut keys like CTRL+L will work.

Why would Alt+~ be any different from Shift+esc? Anyway, Alt+~ would be okay, except that it probably won't work on some international kbds. Also, do you mean Alt+` (the unshifted version)?

Yesh, I mean the unshifted one but if it's not on intl keyboards, we should probably pick something else. We picked an ALT key because I see in Spy it sends a special WM_SYSCHAR message rather than just just a WM_CHAR.

is this a win32-only solution? since bug 78414 (all platform) was dup'd in favor of this one, does this one provide a solution for unix and macintosh?

yes, this addresses windows and mac and linux will be addressed next.

Umm, this is a two year old bug, but I'm still having this problem: When a PDF is loaded in *any* tab in FireFox, using alt-tab to get back to FireFox after being in another window causes a return to FireFox with no keyboard commands (typing, alt-anything, etc) to work at all. This is with a PDF in a tab, but not the current tab. Reproducible every time, Win2K, Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0. -Robin

Question: Isn't this a dupe of #78414 ?

(In reply to comment #12) > Question: Isn't this a dupe of #78414 ? that was tried in 12/02 and failed :P

Resolving as wont fix, plugin support deprecated in Firefox 85.