Actually, the keyboard does work immediately after opening the preview.But as
soon as the embedded Netscape plugin window looses focus (because, e.g. I click
on toolbar's >> or << button in acroread), it can't be restored back by clicking
on the window.

I think it used to work because the plugin viewer 
was based on the old javaembed.  The QXEmbed 
protocol (www.freedesktop.org) now says that 
the embedding apps should set the input focus 
to an invisible proxy window.  This is fine with 
QXEmbed aware apps.  But this kills apps 
that (1) are non aware of this, and (2) use 
they own embedding protocol to display 
the actual viewer.  That includes acroread,  
djvu, plugger, and may be more. 
 
I see no simple fix... 
- Leon Bottou 
 
 

I just retrofitted the knspluginembed class from kde-3.0.5 
and got the usual keyboard behavior in the djvu plugin. 
Recipe: checkout knspluginembed,  
            change define in nspluginloader.h. 
 
This is a short term fix. 
 
The problem is that this is not a valid long term solution. 
 
The essential difference is that knspluginembed  
leaves the X11 focus on the toplevel window while  
qxembed sets it on an invisible proxy window. 
See www.freedesktop.org/standards/xembed.html. 
As a consequence the embedded nspluginviewer  
receives keystrokes when (and only when) the pointer  
is located in the plugin area. 
 
QXEmbed provides a more refined embedding by defining 
a number of protocols for managing the keyboard focus. 
In particular it defines a message XEMBED_REQUEST_FOCUS 
that QXEmbed aware embedded applications must use to request focus. 
 
The problem is that nspluginviewer is not a QXEmbed aware  
embedded application.  The windows it offers for embedding 
are not Qt widgets but Xt widgets.  This is so because 
the nsplugin protocol heavily relies on Xt event dispatching. 
 
Conclusion: as soon as a QXEmbed class exists on the embedder side, 
it redefines the X11 focus to enforce its own focus management. 
When you click on a lineedit widget, the lineedit request the focus 
and shows it by flashing the cursor.  Your keystrokes are then 
redirected to that widget until someone else requests the focus. 
The problem is that embedded applications that do not know 
the XEmbed protocol will never be able to request the focus 
in the first place. 
 
This happens regardless of whether the QXEmbed is used 
for embedding the non-qxembed application.  Even if we use 
KNSPluginEmbed for embedding nspluginviewer, keyboard 
events will stop as soon as a QXEmbed becomes active 
in the same toplevel window.  The most scary thing is that 
the QXEmbed way of doing things might be the default 
in some future version of Qt. 
 
Solutions might come from two directions: 
- Make Xt/Motif aware of the XEmbed protocol 
- Make QXEmbed do smart things when it notices 
  that its client does not know the XEmbed protocol. 
  For instance it might monitor mouse clicks 
  and request the focus on behalf of its unaware client. 
  A little bit like the point-to-click window managers. 
 
- Leon Bottou 
 
 
 
 

> Recipe: checkout knspluginembed,  
> change define in nspluginloader.h.  
 
Thanks! 
  
> As a consequence the embedded nspluginviewer  
> receives keystrokes when (and only when) the pointer  
> is located in the plugin area.  
  
Strange, it behaves a bit differently here: the embedded plugin *never* gets 
keystrokes, except for the time before first mouse click or focus change. When I 
open the viewer, keystrokes are sent to the plugin only after I change focus to another 
widget or even click with the mouse onto plugin area. After then, no keystrokes ever 
made it to the plugin, regardless of mouse pointer position. 

This is the behavior *after* retrofitting knspluginembed from kde-3.0. 
What you describe is the behavior in kde-3.1 with qxembed. 
 
Also note that I just did experiments in my computer 
I did not change anything in the repository. 
 
 -L. 

See http://lists.kde.org/?l=kde-devel&m=104584743531077&w=2  -Leon 

Excellent work Leon