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




16 years ago
a year ago


(Reporter: peterlubczynski-bugs, Unassigned)


(Blocks: 1 bug)

Windows XP
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




(1 attachment)



16 years ago
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

16 years ago
Created attachment 106949 [details] [diff] [review]
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

16 years ago
will this patch fix bug 78414 too ?

Comment 3

16 years ago
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

16 years ago
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

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


16 years ago
Blocks: 93149

Comment 6

16 years ago
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

Comment 7

16 years ago
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

16 years ago
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?

Comment 10

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

Comment 11

14 years ago
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.



13 years ago
Blocks: 78414
Question: Isn't this a dupe of #78414 ? 

Comment 13

10 years ago
(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


6 years ago
Priority: -- → P3
Target Milestone: mozilla1.3beta → ---


2 years ago
Duplicate of this bug: 1315562


2 years ago
Assignee: peterl-bugs → nobody
You need to log in before you can comment on or make changes to this bug.