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.
cc:ing mkaply for OS/2 impact. Does OS/2 need this too?
Status: NEW → ASSIGNED
Keywords: mozilla0.9.2, nsbeta1, patch
Priority: -- → P2
Target Milestone: --- → mozilla0.9.2
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!
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?
Other platfroms have been hacked to fix this. Perhaps OS/2 should too. This patch doesn't help, does it?
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
Whiteboard: [fix-in-hand] → [need sr= a=]
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.
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...
Yeah, it should be: #if !defined(XP_WIN) && !defined(XP_UNIX)
Whiteboard: [need sr= a=] → [seeking reviews][d:1]
per e-mail with Ken, this isn't a rtm stopper, moving to mozilla0.9.3 for now...
Keywords: mozilla0.9.2, nsbeta1, patch
Whiteboard: [seeking reviews][d:1]
Target Milestone: mozilla0.9.2 → mozilla0.9.3
I won't get to this today-->mozilla0.9.4
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Trent, do you know what the status is of this patch and bug?
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.
Ok....Future for now......please let me know if I can be of any help.
Target Milestone: mozilla0.9.4 → Future
Changing summary to differentiate from bug 101082. I hope the new summary is accurate :)
Summary: Focus problem with plugins on Linux → Linux: keyboard events don't bubble out of a plug-in
Linux bug --->over to Serge
Assignee: peterlubczynski → serge
Status: ASSIGNED → NEW
Probably the same as the other plugin keynav bugs.
Assignee: srgchrpv → mats.palmgren
I think this is basically the same as bug 78414.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 78414
You need to log in before you can comment on or make changes to this bug.