Closed Bug 181177 Opened 19 years ago Closed 4 months ago

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

Categories

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

x86
Windows XP
defect

Tracking

()

RESOLVED WONTFIX

People

(Reporter: peterlubczynski-bugs, Unassigned)

References

(Blocks 1 open bug, )

Details

Attachments

(1 file)

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.
Attached patch patch v.1Splinter Review
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. ***
Blocks: 93149
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.
Target Milestone: --- → mozilla1.3beta
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
QA Contact: shrir → plugins
Priority: -- → P3
Target Milestone: mozilla1.3beta → ---
Duplicate of this bug: 1315562
Assignee: peterl-bugs → nobody
Resolving as wont fix, plugin support deprecated in Firefox 85.
Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.