Mark Mentovai Reporter
	Description • 18 years ago

After loading a Java applet via JEP, a window stops receiving kEventRawKeyDown and kEventRawKeyUp (kEventClassKeyboard) Carbon events, and as a result, no NS_KEY_DOWN or NS_KEY_UP Gecko events are ever generated.  I first reported this in bug 340006 comment 7.

I am experiencing this bug in a current trunk build with JEP version F.  I haven't yet checked other branches.

	Mark Mentovai Reporter
	Comment 1 • 18 years ago

I meant: bug 344006 comment 7.

	Steven Michaud [:smichaud] (Retired) Assignee
	Comment 2 • 18 years ago

Once a Java applet has been loaded in a given browser window (for a
Carbon-based browser), the JEP needs to intervene for the brower to
receive _any_ keyboard or mouse events for that window (aside from
mouse-moved events).  (Mark, I know you're aware of this.  But I
mention it because I suspect very few others know it.)

Before JEP 0.9.5+e I used SendEventToEventTargetWithOptions() to send
these events to _all_ Carbon handlers for a given object (i.e. "user
focus", "window", "application").  But the fix for bug 332579 broke
that (some events started being processed twice).  And at the same
time I discovered that, though Apple's Cocoa-Carbon interface (their
Carbon handlers for it) swallow all keyboard and mouse events for the
"user focus" and "window" targets, they _don't_ do this for events
sent to the "application" target.  So (for the most part), as of JEP
0.9.5+e I started sending these events to the "application" target,
using SendEventToEventTarget() (so that only the most recently
installed "application" target handler (a Carbon event handler)
receives them).

That worked fine, for as long as Firefox/SeaMonkey were getting all of
their keyboard and mouse events from the "application" target.  But
now it seems like you've gone back to getting most (all?) of them (at
least of the keyboard events) from the "window" target.

Looks like I need to fiddle once again with how the JEP gets around
Apple's event blockade.

	Mark Mentovai Reporter
	Comment 3 • 18 years ago

Confirming - raw keyboard events, which this bug deals with, are on window targets.  Our TSM handlers, used for NS_KEY_PRESS events among other things, are still implemented using Apple Events (after my failed and unimportant experiment to convert them to CE handlers on window targets too) - that's why text input still works and why this bug wasn't caught in the past two months.  Mouse events still are on the application target.  They'll probably remain that way, unless someone can point to incentives to change them before Firefox 3 (which will use the Cocoa implementation.)

The above applies to Carbon browsers in the 1.8[1] and trunk worlds.  In 1.8.0 and earlier, we did all of this on the sucky WaitNextEvent, "beyond" (but mostly equivalent to) the application target.

	Uri Bernstein (Google)
	Comment 4 • 18 years ago

One noticeable effect of this (I think) is that after loading a Java applet, "dead keys" stop working. E.g., with the "U.S. Extended" keyboard, pressing option-e, then e, should produce an e with an acute accent. This stops working in windows were a Java applet was loaded.

	Mark Mentovai Reporter
	Comment 5 • 18 years ago

Yup, that sounds like a direct effect.  In fact, I experience that problem on the 1.8.0 branch.

	Steven Michaud [:smichaud] (Retired) Assignee
	Comment 6 • 18 years ago

I've just released version 0.9.5+g of the Java Embedding Plugin, which
(I think) fixes this problem:

http://javaplugin.sourceforge.net/

It doesn't fix the "dead key" problem, which turns out (I think) to be
unrelated.

	Mark Mentovai Reporter
	Comment 7 • 18 years ago

JEP 0.9.5+g has been checked in, and it fixes this problem.

	Jason Bassford
	Comment 8 • 18 years ago

Fixed by bug 346156.

	Mike Schroepfer
	Comment 9 • 18 years ago

Marking with fixed1.8.1 keyword