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.
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.
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.
Ack, this should be plused, we need to be able to type in plugins
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?
need info: Why do you guys all think this is saari's bug?
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)...
Is the plugin window a different type of document or window when it is full screen like the PDF plugin?
Not sure if I follow the question but I believe it's a different type of window: http://lxr.mozilla.org/seamonkey/source/modules/plugin/nglsrc/nsPluginViewer.cpp
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 said.
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?
I think the mouse event is going directly to the window created by the browser for the plugin - see http://bugzilla.mozilla.org/show_bug.cgi?id=38484 for an example of how you can bring up a plugin context menu without dismissing the browser context menu.
Mouse events if I remember correctly are relayed to the parent window automatically by DefWindowProc.
nsbeta3+, P2 for M18, cc jrgm
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.
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.
vrfy - thanks!