Dead keys not handled after loading Java in a window

RESOLVED FIXED

Status

Core Graveyard
Java: OJI
RESOLVED FIXED
12 years ago
7 years ago

People

(Reporter: Mark Mentovai, Assigned: smichaud)

Tracking

1.8 Branch
PowerPC
Mac OS X

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
Spun off from bug 346156 comment 4.  This bug is present in JEP 0.9.5+g.

Dead key keystrokes are not handled properly in any window after Java has loaded.  This was reported in bug 344153 comment 4.  I debugged this problem and found that we weren't receiving the expected kUpdateActiveInputArea Apple event during input method input for a dead key.  HandleAETSM is refusing redispatch because of the check at Handlers.m:2250, whose comments indicate it was introduced to fix bug 313807.  The input method (as in defaultInputMethod) is 0 in this case, although both GetTextServiceLanguage and GetDefaultInputMethod succeeded.  But I don't see why HandleAETSM needs to make this check anyway.

Comment 1

12 years ago
The severity should be raised to major, as this bug requires to restart Firefox, therefore losing the current open tabs, the data one were typing in forms and so on.

Comment 2

12 years ago
*** Bug 309769 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 3

12 years ago
I will look into this soon.
(Assignee)

Comment 4

12 years ago
Finally I've had time to get to this.

Mark, I tested your proposed fix (dropping the defaultInputMethod
check at Handlers.m:2250), and (as far as I can tell) it works and has
no bad side effects.

This check has been in the JEP for a long time, and (as I remember it)
was needed to prevent crashes when switching back and forth between
input contexts in Java applets and ones in the browser.  But that was
when I was using the dummyTextView hack, which I haven't been using
for several versions.

Thanks, Mark!  You've saved me a lot of work tracking this down.

I'll include this fix in the next JEP "nightly" -- which I currently
plan to release in the next month or so.
(Assignee)

Comment 5

12 years ago
Side note:

> HandleAETSM is refusing redispatch because of the check at
> Handlers.m:2250, whose comments indicate it was introduced to fix
> bug 313807.

The fix for bug 313807 was actually to loosen this check (by making an
exception for kUnicodeNotFromInputMethod events).
(Reporter)

Comment 6

12 years ago
Welcome back, Steven.

Comment 7

12 years ago
*** Bug 351998 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 8

12 years ago
Created attachment 239366 [details] [diff] [review]
Patch to JEP 0.9.5+g to fix this bug

Here's what it would take to fix this bug.  (This is relevant to the
discussion currently going on at bug 353160 about doing a JEP
0.9.5+g+2 special release.)

I discovered that I _could_ still get crashes if I just dropped the
test that you (Mark) suggested dropping.  The ultimate cause of the
problem seems to be that sometimes Mozilla.org Carbon-based browsers
_don't_ set the TSM doc to the browser's window's TSM doc when that
window is activated.  So my original check only caught the problem
accidentally (in passing).
(Assignee)

Comment 9

12 years ago
I've just done a special release of the Java Embedding Plugin
(0.9.5+g+2) that fixes this bug (along with bug 353160).

"Special" in the sense that I wanted to do it very quickly, and didn't
want to go through the trouble of doing a "regular" release.  So it's
not available at the Java Embedding Plugin SourceForge site.  Instead,
you can download a copy from

http://people.mozilla.com/~beltzner/JavaEmbeddingPlugin0.9.5+g+2.zip

If you want to test JEP 0.9.5+g+2 and your version of
Firefox/Seamonkey already contains a bundled (older) version of the
Java Embedding Plugin, probably your best bet is to do the following:

1) Remove the existing JavaEmbeddingPlugin.bundle and MRJPlugin.plugin
   from your browser's Contents/MacOS/plugins/ directory.
2) Replace them with the JavaEmbeddingPlugin.bundle and
   MRJPlugin.plugin from the JEP 0.9.5+g+2 distro.

It's important to replace _both_ of them.  (The Readme has more
detailed instructions.)

The two fixes that JEP 0.9.5+g+2 contains (for bug 347041 and bug
353160) only have any effect on Carbon-based browsers (since those
bugs only effect Carbon-based browsers).  You can use JEP 0.9.5+g+2
with Camino, and it'll work ... but it won't make any difference.

With luck both fixes will be included in Firefox 2.0.
*** Bug 354925 has been marked as a duplicate of this bug. ***

Comment 11

12 years ago
*** Bug 352251 has been marked as a duplicate of this bug. ***
FIXED by the checkin for bug 353160 (JEP 0.9.5+g+2).
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED

Updated

7 years ago
Component: Java: OJI → Java: OJI
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.