181177 - [windows] ALT keys don't work if plugin has focus

Status: RESOLVED WONTFIX

(Core Graveyard :: Plug-ins, defect, P3)

Description

[Peter Lubczynski]

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.

Comment 1

[Peter Lubczynski]

Attachment: patch v.1

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.

Comment 2

[Jo Hermans]

will this patch fix bug 78414 too ?

Comment 3

[Peter Lubczynski]

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.

Comment 4

[Peter Lubczynski]

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.

Comment 5

[rubydoo123]

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

Comment 6

[Peter Lubczynski]

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.

Comment 7

[Aaron Leventhal]

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)?

Comment 8

[Peter Lubczynski]

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.

Comment 9

[sairuh (rarely reading bugmail)]

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?

Comment 10

[rubydoo123]

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

Comment 11

[Robin Lee Powell]

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

Comment 12

[Tobias (:Tobbi) Markus]

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

Comment 13

[Marc Bejarano]

(In reply to comment #12)
> Question: Isn't this a dupe of #78414 ?

that was tried in 12/02 and failed :P

Comment 15

[BMO Automation]

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