84159 - Linux: keyboard events don't bubble out of a plug-in

Status: RESOLVED DUPLICATE of bug 78414

(Core Graveyard :: Plug-ins, defect, P2)

Description

[Peter Lubczynski]

Active state e-mailed me about the following problem:

> > > Ken Simpson wrote:
> > >
> > > > Hi Peter and Chris,
> > > >
> > > > After my success with the plugin resizing problem (and thanks to you
> > > > guys!), I've been tasked with tackling another plugin problem which is
> > > > almost as serious. This problem prevents us from using Mozilla's
> > > > wonderful keymapping system to map keypresses within Komodo's
> > > > Scintilla widgets to commands in the Mozilla framework.
> > > >
> > > > In GTK, if you assign a keypress handler to a plugin widget, keypress
> > > > events are not bubbled up out of the plugin widget up to the Mozilla
> > > > window for default handling. i.e., if I return 0 from my keypress_event
> > > > signal handler, the Mozilla window never gets that keypress event.
> > > >
> > > > I've traced around a bit and have deduced that the problem has to do 
with
> > > > the focus... When the focus is on a plugin, keypress events are stamped
> > > > with the plugin's window -- not Mozilla's main window. When events pass
> > > > through handle_key_press_event() in nsGtkEventHandler.cpp, they are thus
> > > > routed to the plugin window's event listeners and not the top level
> > > > window't event listeners.
> > > >
> > > > The problem with this mechanism is that when we wrap a plugin inside an
> > > > XBL widget, XBL <handler>s are registered with the main Mozilla window 
and
> > > > _not_ the plugin window (why would they, after all). The plugin window
> > > > gets all the events and tosses them because no one has tuned in to 
listen.
> > > >
> > > > Is any of this making sense? Is there a way around the problem?
> > > >
> > > > Thanks very much in advance.

Comment 1

[Peter Lubczynski]

Attachment: patch by ActiveState to fix focus

Comment 2

[Peter Lubczynski]

cc:ing mkaply for OS/2 impact. Does OS/2 need this too?

Comment 3

[kens]

My patch was a red herring.
nsPluginInstanceOwner::DispatchFocusToPlugin() is never called when
the plugin gets the focus, so the #ifndef is irrelevant.

I'll continue to investigate.
Ugh!

Comment 4

[Mike Kaply [:mkaply]]

Just for the record, OS/2 has much uglier focus issues I think than any other 
platform.

Right now if the flash plugin has an entry field and you click on it, we don't 
give it focus so you can't actually type in any entryfield in flash.

Does any other platform have this problem or just us?

Comment 5

[Peter Lubczynski]

Other platfroms have been hacked to fix this. Perhaps OS/2 should too. This 
patch doesn't help, does it?

Comment 6

[Peter Lubczynski]

The Mac has this problem in bug 81362 but strange it seem to work in debug
builds for me. Hard to debug. 

Could my changes to nsObjectFrame.cpp be the problem:
revision 1.215
date: 2001/05/16 03:46:55;  author: peterlubczynski%netscape.com;  state: Exp; 
lines: +21 -6
Fix for lost focus for plugins on mac bug 78846 sr=attinasi r=dcone

Comment 7

[Peter Lubczynski]

r=peterl

Comment 8

[Chris Waterson]

I think that patch will break some compilers. Use

  #if !defined(XP_WIN) || !defined(XP_UNIX)

instead. But, that said, should this just be...

  #if defined(XP_MAC)

Also, fix the comment to reflect what the #ifdef is doing.

Comment 9

[timeless]

shouldn't it be
  #if !defined(XP_WIN) && !defined(XP_UNIX)
?
otherwise if i'm on XP_WIN it'll be #if !(true) || !(false)
and if i'm on XP_MAC it'll be #if !(false) || !(false)

all of which should evaluate to true...

Comment 10

[kens]

Yeah, it should be:

#if !defined(XP_WIN) && !defined(XP_UNIX)

Comment 11

[Peter Lubczynski]

per e-mail with Ken, this isn't a rtm stopper, moving to mozilla0.9.3 for now...

Comment 12

[Peter Lubczynski]

I won't get to this today-->mozilla0.9.4

Comment 13

[Peter Lubczynski]

Trent, do you know what the status is of this patch and bug?

Comment 14

[Trent Mick]

Peter,
You should hold on this patch, at least from our point of view. As Ken 
mentioned the patched code is not being run on Linux for us so I can't verify 
that it fixes anything. That being said there *are* focus issues on Linux, I 
just don't understand them at all yet.

Comment 15

[Peter Lubczynski]

Ok....Future for now......please let me know if I can be of any help.

Comment 16

[Jesse Ruderman]

Changing summary to differentiate from bug 101082.  I hope the new summary is 
accurate :)

Comment 17

[Peter Lubczynski]

Linux bug --->over to Serge

Comment 18

[Aaron Leventhal]

Probably the same as the other plugin keynav bugs.

Comment 19

[Josh Aas]

I think this is basically the same as bug 78414.