keystroke events are not passed to plugin




18 years ago
17 years ago


(Reporter: sean echevarria, Assigned: saari (gone))


Windows NT

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [nsbeta3+], URL)



18 years ago
After loading a pdf file, focus switches to the location bar.
Page up/down are not sent to the acrobat plugin.
It is impossible to give the plugin focus.
User must use mouse to navigate pdf content.

Comment 1

18 years ago
adding keywords
Keywords: 4xp, acrobat, nsbeta3

Comment 2

18 years ago
Also, it works ok when the file first loads as long as you don't click anywhere
or switch applications.  Once you switch to another window, then switch back to
the window with the pdf content, it's impossible to feed the plugin keystrokes.

Comment 3

18 years ago
Also, when it is 'working' key repeats don't work correctly.  Hold the
left-arrow key down.  The pdf content will scroll one page and then the caret in
the location bar receives the rest of the repeated key down events.
Reassigning to Trudelle because this is believed to be an XPToolkit bug by av,
waterson, pierre, attinasi, ianh.
Assignee: av → trudelle

Comment 5

18 years ago
-> saari
Assignee: trudelle → saari

Comment 6

17 years ago
Ack, this should be plused, we need to be able to type in plugins

Comment 7

17 years ago
Hey, I'm not even seeing mouse events in nsEventStateManager for the plugin! 
Someone care to explain to me why you think this is XPToolkit?

Comment 8

17 years ago
need info: Why do you guys all think this is saari's bug?
Whiteboard: [need info]

Comment 9

17 years ago
av should comment on this. IIRC, the issue was that you could set focus on the
plugin, but focus memory doesn't work (or some such)...

Comment 10

17 years ago
Is the plugin window a different type of document or window when it is full
screen like the PDF plugin? 

Comment 11

17 years ago
Not sure if I follow the question but I believe it's a different type of 

Comment 12

17 years ago
It is different in a full page case, it is not in object frame as when embedded. 
And the problem here is most likely with not setting focus correctly like warren 

Comment 13

17 years ago
So the root of a focus sequence is clicking in the document, in this case the
plugin viewer window, and nsEventStateManager::PostHandleEvent setting focus on
the mousedown event... as I said, I don't even see the mouse event in
nsEventStateManager now.

Where is the mouse event going, directly to the window to the plugin? Does the
window have a PresShell, document, nsEventStateManager or any of the normal
things that govern event flow?

Comment 14

17 years ago
I think the mouse event is going directly to the window created by the browser
for the plugin - see for an
example of how you can bring up a plugin context menu without dismissing the
browser context menu.

Comment 15

17 years ago
Mouse events if I remember correctly are relayed to the parent window 
automatically by DefWindowProc.

Comment 16

17 years ago
nsbeta3+, P2 for M18, cc jrgm
Priority: P3 → P2
Whiteboard: [need info] → [nsbeta3+]
Target Milestone: --- → M18

Comment 17

17 years ago
Neat, the plugin doesn't load at all on MacOS Mozilla. I teach Mozilla about the
mime type by hand and it still doesn't recognize the mime type.

Anyway, on windows... I can make things "work" by making HandlePluginEvent set
focus to its widget for *every* event. This is a huge hack, but gives me hope
that I can find something a little more graceful. Also, this still isn't proper
integration with the XP event systems, it is just wacking the native widget over
the head to force it to get events first.

Comment 18

17 years ago
Fixed it so you can now click on the plugin and use the keyboard for navigation. 

It still isn't properly integrated with focus memory, that is a much bigger job, 

and not necessary for 6 IMO.

Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 19

17 years ago
vrfy - thanks!
You need to log in before you can comment on or make changes to this bug.